The Analytics Engineering Roundup

Share this post

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

roundup.getdbt.com

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

Abhi Sivasailam
Apr 16, 2023
23
4
Share
Share this post

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

roundup.getdbt.com

šŸ‘‹šŸ½ 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.

23
4
Share
Share this post

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

roundup.getdbt.com
4 Comments
Taylor A Murphy
Apr 17

Love this post Abhi. You've done a great job of making some concrete points around things that feel so ephemeral. I'll echo David - tell me more about metric trees :-D

Expand full comment
Reply
Ahmed Saeed
Apr 26

Thanks Abhi - much like you, I read more than I post but been changing gears slightly recently!

Building and leading D&A team for a bit now, and working directly with the c-suite with direct reporting lines into a c-exec for many of my past roles, I can vouch for one thing - and that is, D&A teams must demonstrate their value just like sales or marketing or any other functional unit would, and think of "Business first, Data second" throughout the course of both architecting design principles and stakeholder management.

Some ways to get foothold the right way:

- Create a Data Strategy rooted in the Business Strategy

- Get endorsement from atleast 85% of your key decision makers - re-orientate and re-align if you don't reach this number

- Think like a CFO, act like a CPO/Product Head, build like a CTO/Tech Head and Always be selling/marketing like a CMO/Marketer and CRO/Sales Leader

- Act, measure, improve, share and socialize - do the last bit more openly and don't be afraid if not all heads in the room are nodding (take healthy dissent positively and apply to improve)

The above is obviously an oversimplified brief view - I am thinking of writing in more detail about these topics as been in many a slack communities of late and seeing this trend where this is becoming a topic de jour~

Feel free to follow along if you/your readers are interested: https://www.linkedin.com/in/muhammedahmedsaeed/

Best,

Ahmed.

Expand full comment
Reply
2 more comments…
Top
New
Community

No posts

Ready for more?

Ā© 2023 dbt Labs Inc.
Privacy āˆ™ Terms āˆ™ Collection notice
Start WritingGet the app
SubstackĀ is the home for great writing