Hi, fellow future and current Data Leaders; Ben here 👋
Before diving into today’s newsletter, I want to take a moment to thank this issue’s sponsor, BMC. Many data teams still spend too much time babysitting pipelines and stitching together scripts. Control-M helps automate that work, coordinating data workflows, triggering ML jobs, and syncing across cloud platforms, so teams can focus on analysis instead of maintenance.
Check out their latest case study to see how it can simplify complex workflows.
Now let’s jump into the article!
I’ve been think a lot about the fact that for many companies where the data team work ends, the business value only starts to begin. Even with a simple dashboard or model. You deliver the data product, then what?
Value is supposed to appear right?
After all that’s what the speaker said at a conference “data teams need to provide value” or some other cliche line.
Of course data teams need to provide value. But how a team provides value is often left vague.
That’s where many leaders get stuck. They want their team to be “strategic” or “business-driven,” but they haven’t clearly defined what role their data team actually plays.
A team tasked with building out a data warehouse will provide value in a very different way than a team embedded with marketing to improve campaign ROI.
Over the years, I’ve seen multiple types of data teams. It can be tempting to think about data teams based on roles. That’s the analytics team, the data engineering team, the data infra team, etc. But I think it’s more important to think about the function you want your data team to have.
What are the goals, what is the business function it provides.
Sometimes data teams are strategic partners who connect business problems to data solutions. Others might be enabling other teams by being the platform builders who develop and maintain the data infrastructure and warehouse.
And in some organizations, the data team is just 1-2 people who have to do all of the above.
To figure out how your team provides value, you first need to understand the role it plays for the business.
Four Ways Data Teams Provide Value
A framework I enjoy when considering team types comes from Team Topologies: Organizing Business and Technology Teams for Fast Flow. While the book is about technology teams broadly, its patterns apply neatly to data teams too.
I’ve listed a few examples below.
Platform Teams
Platform teams are often a central infrastructure team that builds layers that everyone else can build on top of. For example a data engineering team that builds ingestion pipelines and manages the warehouse. Their value comes from enabling all other teams to access clean, reliable data. And if you’re in a large enough organization the data engineering team might be building on another platform team, the data infrastructure team.
It is important to note that a company only benefits from having a large investment in platform teams when there are enough analysts and end-users actually building tools and data products that the business uses.
Complicated Subsystem Teams
Sometimes companies need specialists. That’s where these teams come in. Think of a data science research team focused on building recommendation systems or a supply chain optimization model. Their value comes from delivering deep expertise that directly improves the business by either improving operating efficiencies or increasing revenue.
Stream-Aligned Teams
These are domain-embedded teams that work directly alongside a specific business function, like Marketing, Operations, or Product, to deliver data products that drive day-to-day decisions. For example, a marketing analytics team embedded within the growth organization that builds dashboards, models, and experiments to directly influence campaign spend and customer acquisition.
Their value comes from proximity, being close enough to the business to understand context, move quickly, and measure impact. They turn data into decisions without layers of translation between business and data teams.
Enabling Teams
This would be some form of Data Enablement Team within a larger analytics organization. They don’t own production pipelines or dashboards, instead, they help other teams become more capable with data. At least, how it’s described in the book is a heavy focus on pure enablement. Now this is the one I might disagree with a bit in terms of where I see the value. I’d view this team as one that can connect business problems with data solutions. They can span the entire stack.
Defining Your Data Team’s Role and Vision
These categories don’t capture every possible type of data team, but they offer a useful starting point. They help data and business leaders clarify how different teams create value and what role each should play within the organization.
Once you’ve identified where your team fits, the next step is to define what success looks like for that role, both for the business and within the data organization.
Ask questions like:
What outcomes is this team accountable for?
How does it interact with other teams?
What capabilities or resources does it need to deliver impact?
How will we measure progress beyond technical metrics?
From there, you can start shaping a clear vision and the pillars your data organization will stand on. This should focus less on the motions or daily activities and more the outcomes you want your team to drive.
Making This Framework Actionable
Understanding your team type is only step one. Once you know it, you can start making decisions on where you can drive value.
Set Expectations With Leadership
I’ve seen many data teams get trapped as catch-alls. Automation, AI, data engineer, analytics, enabling, platform, etc.
In some cases, well, when you’re a team of one you’ll have to do it all. But there is only so much any team can get done and the more you try to increase that scope, the more likely you’ll start putting out bad work.
Or, on the flip side, you’ll succeed and then be stuck maintaining work that doesn’t drive much impact but two people say they really need.
So as you’re setting expectations, here are some tips:
Don’t promise “strategic insights” if you’re really resourced as a platform team
Frame success in terms of the value your team type is best positioned to provide
Prioritize the Right Work
Setting expectations makes it easier to prioritize the right work, because some work that comes your way will clearly not be best suited for your team. If your team is built up with DevOps and platform engineers, you won’t be as effective building front-end dashboards.
For example:
Platform teams should focus on reliability and scalability, not ad-hoc requests
Stream-aligned teams should bias toward speed and responsiveness
This is of course assuming your company is large enough to break down your data teams into these specialities.
Communicate Value in Business Terms
As someone who has worked on a platform team, it can be difficult to communicate your value. Often your work enables other teams to deliver value directly to the business. But you rarely get the credit unless you clearly tie it to what those teams are doing.
Here are some examples of how each type of data team might communicate their value:
Enabling team: “We helped the sales org standardize KPIs, reducing weekly reporting time by 20 hours”
Platform team: “We improved data freshness from 24 hours to near real-time, allowing the operations team to respond to issues”
Complicated subsystem team: “Our demand forecast reduced stockouts by 15%, saving $5M.”
Stream-aligned team: “Our campaign ROI dashboard helped reallocate budget, increasing efficiency by 12%.”
Closing Thought
In some organizations a data team is two people who spend half their time on analytics and the other half on IT workflows. While larger and more data-critical organizations have teams broken down into specific types.
Regardless, if you’re not careful all these teams can start to lose their purpose. In some cases they become catch-alls and in others they become so divorced from the business that they don’t even drive value any more.
That’s why it’s important to start with a general why. Why does your team exist and what is it that you do for the business.
As always, thanks for reading.
Upcoming Data Events
Seattle Happy Hour At The Rhein Haus With BMC(I’ll Be There!)
Articles Worth Reading
There are thousands of new articles posted daily all over the web! I have spent a lot of time sifting through some of these articles as well as TechCrunch and companies tech blog and wanted to share some of my favorites!
The Knowledge Architect’s Playbook: The Pedantic Medallion
Let’s be honest with each other. Is our expertise a bridge, or is it a wall?
In our industries, we are paid for what we know. But we build value only when that knowledge is shared and understood. Too often, we build walls. We hide behind jargon, complex diagrams, and esoteric tools, not to create clarity, but to signal our own intelligence. We speak from a level we believe proves our worth, forgetting that the goal of communication is not to broadcast our own brilliance, but to build a shared reality with others.
The “D” In Data Stands For Discipline
A seasoned data leader once told me something that stuck: the d in data stands for discipline.
Now to be clear, pretty much every field requires discipline.
But we often focus on the exciting parts of data work in articles.
Not the tedious, repetitive, mundane, just doing the right thing type work.
End Of Day 196
Thanks for checking out our community. We put out 4-5 Newsletters a month discussing data, tech, and start-ups.
If you enjoyed it, consider liking, sharing and helping this newsletter grow.
Hey Ben,
I have been perusing your articles for some time now. This is my first time commenting.
Being perceived (there is a big difference between perception and reality at work but different story) as delivering value is more important than ever as companies look for ways to cut costs, automate, outsource, and streamline. You need to be perceived as driving value pronto and regularly.
But this article, like many of yours, is filled with noise and not much substance.
It's not enough to ask stakeholders "What are you trying to accomplish?" It's much like therapy session where you have to ask stakeholders probing questions what they really want? Sometimes they don't know what they want or what is possible. Sometimes it's a superficial reason (e.g. the data team exists because the powers-to-be mimic what others are doing).
In that case you have to ask or find out for yourself how to deliver value.
It would be helpful if there is a framework or a list of questions we can take to stakeholders. A bunch of abstract topics on "Team Topologies" don't help much.
Data management benefits the enterprise in much the same way as the sun puts hay in the barn.