Business knowledge helps you craft more substantive hypotheses and better diagnose data issues

Quantitative analysis and engineering chops are tablestakes for data scientists. But domain knowledge is the true differentiator. We don’t talk about this enough.

dbt Labs CEO Tristan Handy’s newsletter got me thinking about this today. In today’s issue, Handy identifies 3 personas or roles in the analytics development lifecycle:

The Engineer: The engineer creates reusable data assets: pipelines, models, metrics, etc. The engineer is primarily focused on creating data assets that will be used by others to create business value.

The Analyst: The analyst performs in-depth analysis that drives decision making. The analyst does not make decisions, their role is quantitative investigation and presenting of analysis and/or recommendations to the decision maker.

The Decision Maker: The decision maker is responsible for taking quantitative outputs and translating them into action for the business. This is inclusive of everyone from a campaign manager optimizing segmentation to a CEO directing the resources of an entire company.

“The most effective data practitioners,” Handy writes, “wear all three hats.”

I strongly agree.

We over-index on the first two roles when developing data scientists. Business decision making? Well, that’s somebody else’s job: a product manager or an exec views an analysis and makes the call.

But domain knowledge in a company’s field is a difference maker for data scientists.

It enables them to:

  1. Craft better, more creative hypothesis helping them find better insights, faster. When you have an idea how the buisness works, you can make more complex assumptions and develop hypotheses further out from the baseline. Bigger leaps, adequately tested, help you move faster and find unique information.
  2. Better identifty when there’s an underlying problem or blindspot in their data, preventing spurious conclusions. Seemingly random data may make sense when you know the underlying behaviors generating it.
  3. Effectively communicate their work – and why it matters – to the rest of the organization. If you can’t express your work in a language native to the business it might as well not exist. Data scientists will drive better results and be valued more the closer they can deliver their insights to business logic.

The last point is super important. Being good at explaining the benefits of your work earns you a seat at the table in various departments, which in turn grants you an opportunity to learn more about the buisness. You’re increasing the surface area of your team with the rest of the business.

The worst thing you can do is be overly protective of your data scientists. Over-index on the analysis work, locking them into rooms with zero distractions so they can swim in the data. You need to do this (and we want to do this!) but you can’t do this all the time. It’s a third of the job, not 90%. Too much distraction-free analysis work leads to a navel-gazing team that spirals into irrelevance.

Unlike the other two hats, domain expertise is mostly going to be something your team has to develop after you hire them. Which is why optimizing for both curosity and a demonstrated ability to learn new domains is crucial during your interview process.

Domain expertise is not a ‘nice to have’ for data scientists. It’s the difference maker that separates the capable from the great. If you’re a data scientist, push for more exposure to the organization (if you don’t have it already). If you’re a data science leader, always be creating opportunities for your team members to build relationships with collegues in other departments. This time spent not doing analysis or engineering will deliver incredible dividends.