OS layer not application layer - how data teams actually drive value

👋🏽 Hi folks, I’m Abhi. Long-time lurker, first-time poster, and your host for this week’s Roundup. I cherish and have gotten a lot from this community over the years, so I’m so grateful to be able to share some thoughts with y’all today. I have lots of said thoughts (and a word count cap today), so expect to see me back soon. But for now, let’s get into it.

Hang around the watercoolers of the “data community” long enough and eventually the conversation will turn back to one of The Classics: how do I measure the value (and ROI) of my team? I get this question a lot – so often, that I have a standard response. For most teams, that response basically amounts to: you don’t. Today, I want to dig a little deeper into this response and explore what that means for how data teams should work.

A good place to start is with why the question of ROI is so hard to answer. The question is difficult because the question is wrong.

ROI questions make sense in the context of hard deliverables, but the true value of data teams isn’t in their deliverables, it’s in something more abstract: it’s in helping their companies get value out of their data.

But that begs the question: what does it mean to get value out of data? What value is there in data to be extracted in the first place?

For most companies, most of the value of data is simply in answering 4 questions:

1. What is happening in our business?

2. Why is it happening?

3. What’s going to happen next?

4. What should we do about it?

That’s it.

Companies get value out of data when they are asking those questions over and over and over again and when they are constantly organizing themselves and their work around the answers. Doing so is what it means to be a “data-driven” company.

Data teams exist to make this possible. Their mandate is to make these questions easy enough to answer that companies ask them more often; and the answers clear enough that companies act in response.

If your company looks like this, your data team is probably creating real value. If your company does not look like this, your data team is probably failing.

Importantly, if you’re in the former camp, the question of your team’s ROI likely does not loom large in your mind or the minds of your business partners. That’s because good data work, exactly like good design work, is invisible.

The best data teams understand this.

The best data teams don’t see the output of their work as anything tangible (even something so ethereal as “good decisions”) – they see their output as creating the conditions for other teams to do their best work.

In techno-speak, the best data teams don’t seem themselves as contributing to the application layer; instead, they know that they’re contributing to the operating system layer.

Playing the value measurement game then is something of a category error – it’s trying to measure contributions to the operating system as if they were applications.

The best data teams build on this insight and focus their work on improving the key components and processes of the company’s operating system. And the very best way to do that is by targeting the two most important such processes – what I call The Big Two – Business Reviews and Planning.

The Big Two are all that matter.

Business Reviews are how a company monitors, introspects and recalibrates. Planning Cycles are how a company decides how to invest its resources in and for the future. Taken together, these two processes shape most of how the company works and what it produces. As such, they are incredibly high-leverage.

If these processes run well, the company is probably doing well. If these processes run poorly, the company is probably failing.

The best data teams make sure that these processes run well and see doing so as their mandate, their very highest priority, and how they measure their own success.

After all, The Big Two are fundamentally all about The 4 Questions.

But how should data teams go about this work? What does great look like when it comes to these processes? And what is the path to getting to great? All important questions, but big enough that they deserve their very own Roundup (hopefully soon). Stay tuned, and till next time.

From around the web

Introducing Entity-Centric Modeling

Anything from Maxime is self-recommending, but a post on modeling is especially so.

The “State of Dimensional Modeling” is another one of those Classics the data community loves to revisit [weekly] – but not without good reason. Has Kimball-style modeling become less relevant in light of the evolution of database engines over the past decade or is Kimball Lindy? Or is the truth somewhere in between? And how should the rise of LLMs change how we think about these questions?

These questions keep coming up because they’re relevant and important – but also because we (or at least I) have yet to see answers that are contextualized, comprehensive, and confident.

Instead, the answers we get seem to themselves be partial solutions – that work in some context but not in others, don’t sweat the details to the level required to become a standard, aren’t explicit about tradeoffs, and, worse, don’t fully understand or engage with the history and prior art that they reject or build upon.

Personally, I also fret that the answers prioritize technical considerations over ergonomics. Rahul is right: Data UX should be a thing – and I’d like to see the modeling discourse centered more on research on how real people (and not just data nerds) actually use and reason about data.

I’m actually (if irrationally) optimistic that we’ll all reconverge on grand answers we’re happy with soon. In the meantime, Maxime’s contribution to the discourse is worth a look.