Blog There is no such thing as a “non-technical” data analyst

There is no such thing as a “non-technical” data analyst

Emilie Schario

Oct 29, 2020

Opinion

A couple of weeks ago, I was participating in a Slack discussion about open source tools in Locally Optimistic when someone said that teaching their team members the command line was "too hard."

They weren't talking about teaching their CFO the command line; it was too much of a hurdle for their data analysts.

I've heard this sentiment many times before, and I couldn't disagree more. I want to take the time to outline why I think it's time for our profession to start treating analysts as the incredibly smart, capable, and technical humans that they are.

For a long time, I've heard a series of complaints that technical subjects like Git and the command line are "too hard" for non-engineers to learn. My take? The command line isn't too hard. It's just that your team member doesn't know how to use an intimidating tool!

When I worked at GitLab, I watched the company grow by 1,000 people (and onboard more than that) over the course of more than two years. On Day 5 of your onboarding, you set up your SSH keys and added yourself to our team page by adding yourself to a YAML file.

For a non-engineer, this can be a daunting task, but if you have a hard time, someone is there to help. The People Experience team hosts onboarding office hours, your onboarding buddy (usually a member of your team) or manager is available, or the #merge_request_buddies channel in Slack is full of willing volunteers who regularly spend time helping team members troubleshoot broken pipelines on Merge Requests or rebase week-old merge requests as a fallback.

These tools were standard at GitLab because it was made a part of the basic literacy of working there. The culture at GitLab made it easy to learn these tools, independent of your role in the organization. I watched every single one of our executives and senior leaders create and review Merge Requests of varying complexity---from typos to policy changes to Ruby snippets. All they needed was a little help from someone who took the time to explain the process.

Data engineers, your analyst colleagues are just as smart as you. And if you take the time to teach them how to do something, they'll be grateful. It's time that we stop acting like it's too much work to invest in our people, in our colleagues, and in our peers. It's time that we teach folks the basic navigation, what a repository is, and why Git is an incredible tool. It's time we stop acting like these baseline technical skills are too hard.

There is no such thing as a "non-technical" data analyst. Your colleagues spend their days translating business logic into code. That code might be Python, LookML, SQL, or a wildly complex Excel formula (Yes, you can write code in Excel). Building a marketing attribution model, forecasting, and calculating Monthly Recurring Revenue is all quite technical. Your analysts very likely have a far better grasp on the inner workings of the business. That's technical knowledge too!

Take the time to learn how analysts on your team work today, you will be surprised at just how technical they are.

And yes, I get it. Whenever someone gets a failed pipeline on a merge request, 99% of the time it is easier for me to tell them what the problem is, as opposed to helping them figure out how to get that answer for themselves.

But let's call this what it is: laziness.

I get it. I'm lazy too! A lot of people may take the easy way out and just solve the problem for their coworker. But this time is an investment. If I can spend 15 minutes now teaching a colleague how to troubleshoot why a data test failed, decipher it, and solve the problem, they'll be capable of helping themselves in the future.

In fact, take this story from dbt community manager, Claire. She once got herself into a weird Git state, and it turned out that the best way to fix it was to rebase. Claire managed to fix the problem herself, but she still didn't know why a rebase fixed the problem or how it worked. So, she asked someone from the engineering team to help her out:

"A wonderful engineer came over to my desk and sat with me. He said, "Let's say I have a tower of lego bricks. When you branch off, you duplicate that tower and start building on top of it --- the original tower is your base. Now, if someone else has made changes to the tower while you were working, your new lego bricks might not fit on top anymore. This creates conflicts when you try to 'push' your bricks from your copy of the tower to the main tower. So, you can 'rebase' --- you lift up your bricks temporarily, swap the old base with the new version of the tower, and then put the lego bricks back on top. If they don't fit, git will tell you and try to help you fit them on.



"This really stuck with me --- he took a thing that I didn't understand and made it so clear that I've now gone on and used that same analogy when teaching folks at our company. Investing the time in teaching your colleagues gets paid forward."

A couple of weeks ago, I was sitting in a call with some Sales Enablement folks when a team member asked what "squashing commits" on a Merge Request meant. After someone made a crack about it being related to some vegetables (can you blame them?), someone put forward the idea that it was about condensing commits. Umm, yes exactly! I explained to her that, in plain English, squashing commits takes the multiple commits on a branch and combines them into one as you merge. (For a more technical overview, there's a great Stack Overflow explanation.)

You just have to change your wording a bit. I, like colleagues of mine, have developed a language for explaining these subjects.

Version Control? Well, that's like "track changes" in a document.

Git? A system to manage that version control.

The command line? Instead of navigating with a mouse, the command line lets you do it with words.

Git is not "too hard". Your analysts are not "non-technical".

The idea that the command line and version controlled workflows are "too hard" is gate keeping that we should actively work to combat. Spend some time helping your analysts level up instead of claiming things are too hard, and you'll see a world of a difference.

In my time at GitLab, I realized that you can teach every team member Git, as long as you take the time to teach them. These teaching moments are more valuable than you think, and your colleagues will remember your efforts for a long time.

Last modified on: Feb 27, 2024