Storytellers and System Builders🔗

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?

Thousands of data people of all kinds use the Hex product every day, which gives us a unique vantage point into who exactly is doing data work, what “data work” means to them, and what they call themselves.

As I’ve set out to build our own 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, and I’ve discovered that it all boils down to just one question.

Systems vs. Storytelling

The big secret is that all these titles are just slight variations of the same two themes, and there’s one simple question to pick a path: do you love systems, or storytelling? Or, in the famous words of Marie Kondo, which path sparks joy?

📊 Storytellers

You can have all the data in the world, 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:

• Do you feel satisfaction driving change by having the best argument, knowing the decisions you’re framing help to bring clarity and focus to an organization/business/product?
• Do you love helping other people make the right decisions using data?
• Do you feel proud navigating narrative chaos to create clarity for others?
• Have the best moments in your data career come from using data to change someone’s mind, modifying a team’s roadmap, or shifting an org’s strategy?

If you’re nodding and shouting ‘yes!’, you’d be a great Analyst or Data Scientist — a storyteller who finds decisions to be made, frames them for the right decision maker, and drives change based on that decision being made.

🛠 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:

• Do you feel proud navigating and abstracting away technical complexity to build something that empowers others?
• Do you feel satisfaction wrangling order from chaos?
• Do you love helping other people answer their quantitative questions?
• Have the best moments in your data career come from taking raw and unintelligible data sets and turning them into something that more removed stakeholders can consume?

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.

Ask yourself:

• Are the people on my team spending a majority of their time on Systems or Storytelling today?
• What would each person on the team like to do more of, in an ideal world?
• Are the major bottlenecks to data team impact on the systems side (not having right data available) or storytelling (not driving analysis and decision-making)?

✍️ 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.

• Is a role focused on creating scaled data systems, or digging into problems and bringing perspective to decision making?
• Are your JDs written in a way that implies both Systems and Storytelling responsibilities? This could alienate both archetypes.

🐝 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.

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 valuable and rare Storytellers and System Builders.

Try it out on your own team! I’d really love to hear about how it goes.

Originally published at https://hex.tech.