If you have spent any time in the data space in the last 10 years, you’ll know that data job titles have gotten hilariously complicated and confusing. There are Data Analysts, Data Scientists, Analytics Engineers, Data Engineers, Business Analysts, Business Intelligence Analysts, Product Analysts, Product Data Scientists, Data Product Managers (?), ML Engineers, Data Enthusiasts, People Who Just Really Love Counting, and dozens of other titles floating around.
This proliferation of Data nouns – and their confusing mapping to a core set of tasks – has been a through line of my own career. When I started as an Analyst, I spent most of my time trying to produce basic counts to help make decisions ("how many WAUs?" could take weeks to figure out). I often worked with Data Engineers who built complex pipelines with “real code” to take data from source to the warehouse, but that was about the extent of my involvement in building data systems.
At some point in the mid-2010s, “Data Scientist” started to enter into the zeitgeist. As best I could tell, it meant they either knew more statistics than me, or just did the exact same work but used Python instead of SQL. I’m pretty sure they got paid more than me, though.
And then a few years ago, our pal Claire and the good folks at dbt brought another role into the mix: Analytics Engineer. This felt new, exciting, and different from Analyst roles – like a more approachable Data Engineer. But I was confused, as the technical skillset appeared to overlap with traditional Analysts quite a bit. You just do SQL, plus some Git and Jinja? Isn’t that what I do all day?
Part of this confusion is the consequence of new tooling and capabilities. Historically, the lines between these roles were mostly drawn based on how “technical” you were— how well you could code. But in the modern data world, there are Python people putting together charts and analyses, and SQL people building complex data pipelines— the languages they use or how familiar they are with the command line no longer tells us much about what they actually spend their days building doing.
And (for once!) it turns out I wasn’t alone in my confusion. Today, I talk to folks all the time who are interested in data work and think they might be a “data person”, but just don’t know how to chart a path through the thicket of data and ML titulature. It’s unnecessarily complicated, and that makes it really hard for individuals to build careers and for leaders to grow data teams.
But why Analytics Engineers?
Working at Hex has given me a unique vantage point on this. Every day, thousands of data people use our product, which gives us some insight into who is doing data work, what “data work” means to them, and what they call themselves. And as I’ve set out to build our own internal Data team, I’ve spent hours reflecting and pattern-matching to better understand what kinds of people are best suited for each type of role.
Systems vs. Storytelling
What I have found is that there are really only two data roles: System Builders and Storytellers. All of the other titles, from Data Scientist to Analytics Engineer, are really just variations of these same two themes, and there’s one simple question to pick a path: do you love building systems, or telling stories? Or, in the famous words of Marie Kondo, what sparks joy?
You can hoard terabytes of data, but there’s no point if you aren’t using it to make decisions. This is where Storytellers come in. Their fundamental mission is to use data to understand the world, and share that insight to influence others. Analysts, Data Scientists, and most other people using data every day fall into the “Storytelling” bucket.
Here are some questions to figure out if you should choose a career on the Storytelling path:
If you’re nodding and shouting 'yes!’, you’d be a great Analyst or Data Scientist - someone who finds decisions to be made, frames them for the right decision maker, and drives change based on the outcome.
🛠 System Builders
Storytellers might build the pretty charts and write the good words, but there wouldn’t be any data behind them if not for the System Builders. Their fundamental mission is to make integrated, reliable data sets available to others. Analytics Engineers, Data Engineers, and Data Product Managers fall into the “Systems” bucket.
Here are some questions to figure out if you’re a System Builder at heart:
If so, you’d be a great Analytics Engineer or Data Engineer - someone who builds systems and processes around data to enable operational excellence and decision making.
Building a data team
If you’re a data and analytics leader, you can apply this same framing to clarify your roles both internally and externally.
🙇 Assess your current team
I often see Systems folks being asked to spend time on one-off data pulls or other non-scalable work, and Storytellers not having a clear role in the decision-making process.
✍️ Realign your job descriptions
Evaluate what your actual needs are, and adjust your JDs to focus on the applicable function and title. Make them clearer, in both title and detail, about what it is you’re looking for.
🐝 Structure your team in a way that fosters cross-pollination and collaboration
I don’t recommend splitting your Storytellers and System Builders into two separate organizations — there’s incredible value from having tight feedback loops between the two roles.
At Hex, both Storytellers (Analysts) and System Builders (Analytics Engineers) report into BizOps. This way, Systems folks are getting the rapid feedback that will help them build more effectively, and the Storytellers are getting the data they need. They also work directly alongside our Revenue Operations folks, who both contribute to and leverage the Systems that our Analytics Engineers build.1
Data teams of the future
It’s almost too obvious to write, but when people do things that make them happy, they’re more productive. If we start mapping career growth with this “System Builder vs. Storyteller” paradigm instead of arguing about the minutae of hip new titles, we will see efficiency gains and happier people across the board.
Adopting this mindset at Hex has made our hiring cycles more effective, because candidates have more clarity around what they’re applying for. Everyone in the org, not just the data team, knows what these mythical Data People do and how to engage with them. There is tighter alignment between what each member of the team does and the tasks that bring them joy.
And that joy translates into greater productivity from these brilliant and rare Storytellers and System Builders.
Try it out on your own team! I’d really love to hear about how it goes: email@example.com.
In our experience at Secoda working with many data teams, we've seen most data teams do not have the tools they need to succeed. For growing organizations, the data function is usually an afterthought. The first data hire is brought on before raising a Series A and is expected to manage the workload that comes afterward with little to no support.
One reality that many companies face when adopting cloud technology: designing data infrastructure for business in a cloud computing environment is just different. Legacy stacks can indeed suffice for many companies. But as business requirements grow and use cases increase, both in number and complexity, the models and assumptions that worked well enough in the data center become problematic.