Who are analysts, technically?

Two posts in the analytics community have been bouncing around in my head for the past few weeks. They hit on something important.

First was Benn Stancil’s “Analytics is at a crossroads”

In this post, Benn does a fantastic job articulating something I’ve long felt but have been unable to put into words. I couldn’t stop nodding along for the entirety of the piece. His main point: the world of analytics is putting up walls to what otherwise could be some really great analysts. We perhaps focus too much on technical skills; at the expense of finding great “puzzle solvers” who can write and communicate effectively. That quick summary doesn’t do it justice. Take a few minutes and read it.

Second was Tristan Handy’s “The magic of the analyst fictional”

Tristan builds on Benn’s piece with the insight that it’s easier to teach people technical skills than it is to teach them the softer parts of analysis. We know how to teach SQL, Python, R, and statistics. What we don’t know is how to teach the soft skills - the curiosity and tenacity to break down a problem, invent a solution, and persuade others.

My experience.

These pieces resonated quite deeply because, well, I’m just not very technical. I don’t know R. God forbid anyone saw the ugly, basic python scripts I’ve written (they worked, but yeesh!). I know SQL, but like Benn, I learned it on the job. And (probably unlike Benn and Tristan) I’m at my best in a spreadsheet. Finally, when it comes to moving down the stack - into dbt, airflow, spinning up databases, or building and transforming data warehouses, I’m quite out of my element.

What I really love is analysis itself: exposing insights that can unlock a new chapter of growth and advocating for change in an organization. The technical nature of what I do is less core to my enjoyment and identity. With that, I suppose I just want to raise my hand and reiterate that you can be effective and go far as an analyst without being deeply technical.

In the spirit of pushing the conversation forward, I thought I’d offer up a few thoughts.

Let’s get clear on the competencies for each role.

We certainly are asking too much of analysts. As Benn puts it “Analysts have to spin up databases, manage Docker, get Python environments running, develop testing frameworks, and maintain a fragile Rube Goldberg machine of mismatched internal tools and third-party applications.”

This is the job of many and I’m not sure I’d just call them all analysts. There are obviously roles within analytics teams that call for technical requirements and engineering skills. And I do agree with the idea that we need more purple people - folks who sit at the intersection of business context and the technical. But we need to be careful we don’t confuse ourselves along the way, or ask too much of any one role. I’d love to see us get really clear about the competencies required to do each of the roles across analytics well - from data engineer, analytics engineer, data scientist, data analyst to business analyst. Each of those roles overlap in many ways, but they also require distinct skill sets that we’d be best equipped articulating, debating, and aligning on (perhaps this exists and I’ve just not found it).

Building great data organizations is like any team sport. When a general manager constructs a basketball team, they sign new team members after carefully considering their strengths and weaknesses and how they fit alongside the rest of the team. The best managers construct a roster that’s balanced and works well together - with some who excel at 3 point shooting, others at rebounding, defense, passing, etc. Analytics leaders need to think similarly when building a team made up of folks that spike on various competencies - technical abilities, puzzle solving, process construction, communication, persuasion, etc. The first step then is getting super clear on the exact competencies that make a great team.

When in doubt, err on the side of soft skills.

As Tristan points out, “I have, and more broadly dbt Labs has, trained a lot of people to be competent—or even great!—with a certain set of technical skills required to be an analytics engineer… But we don’t—and I don’t!—truly know how to train someone to be a great data analyst. Honestly I haven’t seen anyone do a good job of this.”

This very much matches my experience. I never required SQL experience when hiring analysts at Intercom and still wouldn’t if I were building another team of analysts. I did however require that every analyst prioritize learning SQL in their first two weeks on the job. And, guess what, every single person did so. Ultimately though, the great analysts stood out not on their technical abilities but on their soft skills. And when it didn’t work out it almost never had to do with their SQL or any other technical skills but rather some soft skill shortcoming.

In fact, I’ve found that most of the purple people (again, folks with both great business context and technical abilities) I’ve worked with have excelled first on the soft skills and learnt the technical (that certainly doesn’t mean it can’t go the other way). This pattern is one of the reasons I’m such a big advocate for folks in finance and ops roles to learn SQL. Chris, who designed and built the system that solved ARR reporting at Intercom, is one such example. He started in sales ops, then moved into FP&A, and learned all of his technical abilities on the job. Today he could probably get a job as an analytics engineer.

The importance of soft skills as a foundation makes Benn’s point more critical. The world of analysis needs to be more accessible to folks who spike on innate curiosity, problem solving, business context, and storytelling - with the assumption that the technical can be learned. First and foremost, because those soft skills are required to build an excellent team of analysts. Secondly, because those folks, in my experience, are the pipeline for the next great purple people.

Let’s find more ways to celebrate great analysis.

Finally, a briefer and lighter point. In the spirit of elevating and making the art of analysis more accessible, I wish we would celebrate and showcase real analysis publicly. Inherent to this would be less of a focus on the technologies and tooling that made it possible, and more on the insight and process of getting there. This tweet thread is an example of exactly what a great analyst can accomplish and is one that highlights the soft skills necessary to do the job. More of this please! Let’s give folks more to emulate.

Standing squarely against this idea are the simple facts that 1) we’re all super busy and 2) oftentimes great analysis can’t be shared publicly (one of my biggest gripes with the job). If any folks are actively thinking about how to best enable public sharing of analysis, I’d love to somehow help or be involved.

All this to say - I’m also quite excited, despite my somewhat lack of understanding (particularly of data mesh), by all of the tools and technologies we’re creating to make data accessible and easier to use. The technical side of our field is no doubt necessary and revolutionary. At the same time, I’m grateful to Benn for reminding us what it’s all in service of. As he puts it:

“Down one path, analytics engineering becomes the barrier between engineering and analytics. Rather than needing to be an impossible combination of statistician, developer, and business expert, analysts can simply be great critical thinkers ... With the help and support of analytics engineers, analysts can learn the technical skills they need (just as I did at Yammer), and focus on being the curious puzzle solvers they are.”

That’s the future I’m excited to help to build. It’s why I’m working on and building something for folks like me, whose tool of choice is a spreadsheet.