Don’t Tell Your Data Team’s ROI Story

Photo courtesy of NASA Archives

I’m fortunate to be involved in a few awesome data-focused communities. Like clockwork, every few months a Data leader will pop up asking for advice on how to calculate the return-on-investment for their team. The question is usually in the context of a budget decision, where they need to justify expanding headcount or purchasing a new tool.

The name has been changed to protect the innocent
The name has been changed to protect the innocent

While there’s a subtle irony in the team responsible for quantification struggling to quantify their work, calculating a true “ROI” can be challenging because of the way data teams typically operate.

In some cases, the data team has a top-or-bottom-line impact that can be directly measured. For example, if the company sells data as their product, the Data team has a clearer, more obvious connection to value creation.

But for most teams, their impact is created indirectly: they are partners, acting in support of functions like Marketing, Operations, or Engineering to affect company performance.

In organizations like these, efforts for the Data team to come up with a standalone ROI will be underwhelming and unconvincing. Calculating a crisp “return” on an analysis project or model is difficult, and it’s even harder for infrastructure investments: how do you quantify the impact of a better schema, or a more reliable pipeline? An improvement in data quality can be objectively beneficial, but also quickly taken for granted.

The truth is that if you’re trying to quantify your impact by yourself, you have already lost. Instead, the best way to tell the ROI story is for other people to tell it.

If your Data team is truly providing value, the leaders of other functions should be lining up to sing your song. Limitations or reductions in Data team headcount should elicit howls from functional stakeholders; the VP Marketing and Head of Ops should be the ones fighting for more Data resources.

If your partners aren’t willing to go to bat for you like this, then it’s time to take a step back to rethink how you’re operating. Are other teams actually benefiting from your work, or are you detached from business outcomes? Is your team in the trenches with other functions, or only providing input from afar?

There are 3 key areas to examine:


Too many data teams operate in a centralized, siloed manner. “Ivory Tower” teams may be doing brilliant, insightful work, but they’re too far from the business to make a tangible impact.

I once worked with the “Advanced Analytics Group” at a major CPG company. They all sat together, in one area of one floor of one building, far from the teams they were supposed to be supporting. While they were all intelligent, earnest people, their work was academic at best, and they struggled to justify their existence. This “Center of Excellence” model rarely works, especially as a team grows.

There are other ways to organize a data team. Pardis Noorzad has an amazing overview here, and I agree that the "Product Data Science" model is a strong option for most teams. Justin Gage's "Data as a Service" model also provides a useful lens - is your Data team just providing data, or useful input to decisions? If not, stakeholder partners are unlikely to stand up and support your team’s ROI story.

From Justin Gage's 'Data as a Product vs. Data as a Service'
From Justin Gage's 'Data as a Product vs. Data as a Service'

Re-organization away from a centralized Data team model can be painful, and may feel like a loss of control or prestige. But it’s critical to keep an open mind — and set ego aside — if you want your stakeholders to feel the impact of your team, and advocate on your behalf.


Next, integrate your planning process. If your organization uses a system like OKRs, explicitly tie the Data objectives to support the goals of your stakeholders. This makes it clear exactly how your team is impacting functional outcomes.

All together now
All together now

Infrastructure-level objectives — like implementing a new data warehouse — can live separately, but should still have explicit callouts for how those investments are supporting the higher-level objectives.

Data Leaders should also push for their teams to be involved with other teams’ granular planning cycles. If the Marketing team has a weekly planning meeting or daily stand-ups, the Data analysts supporting that team should be in the room (or Zoom, or whatever).

If your team has its own planning cycles and sprints, involve stakeholders in an explicit prioritization exercise. This will give them more insight into Data activities, and when it comes time to speak to ROI they will already have thought through the upside and tradeoffs around your team’s time.

As a side benefit, by aligning priorities with the business, Data teams avoid the dreaded “find novel insights” mandate. If an Analyst is deeply embedded with the Marketing team, partnering on their hardest problems, it’s harder for the CFO to distract them with a one-off wild goose chase.


Even if they are well-integrated into the rest of the organization, the Data team’s work will underwhelm if it’s not actually useful for others. Today’s tools are a mixed bag here.

BI platforms are great for enabling self-serve and building dashboards. But they also have relatively low ceilings, and aren’t a medium where data scientists can do their most interesting work.

On the other hand, Code notebooks are amazing for deeper exploration and model iteration, but are single-player, hard to share, and inaccessible for less-technical folks. Even if a Data Scientist has developed something interesting, there’s no easy way to productize it or make it useful for the rest of the organization.

So Data teams often wind up screenshotting charts, exporting CSVs, and sharing through slide decks, spreadsheets, and Slack. While these tools meet stakeholders where they are, they’re severed from source data and have short half-lives; when a PM wants to update an assumption, they need to ping the analyst, who re-runs, re-exports, and re-sends.

We can do better
We can do better

This gap in sharing and collaboration not only wastes Data teams’ time, but acts as a drag on their impact. Delivering a forecast model to the Finance team as a live, interactive data app is way more useful than a once-weekly static PDF; the CFO themself will understand the ROI every time they open it to run a new scenario.

I’m excited to see a new crop of tools emerge (disclaimer: I’m working on one) to help data teams more easily share their work, and create clearer, more tangible impact with the rest of the organization.

It’s an exciting time in the Data world. Thousands of new people are entering the space as Data Scientists and Analysts. It’s easier than ever to source, transform, and store data. And the ML explosion is unlocking possibilities for insight and inference.

But gaining the budget and support needed to take advantage of all of this is an uphill battle without advocacy from functional stakeholders. By re-evaluating team organization, planning, and tooling, Data teams can ensure their impact is obvious and clear.

Done right, it means the next time a Data leader is asked to justify ROI, they won’t have to. They can sit back, and let others tell the story for them.

This is something we think about a lot at Hex, where we’re creating a platform to build and share interactive data products, and help Data teams be more impactful. If this is interesting, drop us a line at, or sign up for the Beta waitlist below.
Sign up for the beta