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. (View Highlight)
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. (View Highlight)
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. (View Highlight)
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. (View Highlight)
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 ingestionpipelines 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. (View Highlight)
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. (View Highlight)
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. (View Highlight)
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. (View Highlight)
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. (View Highlight)
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. (View Highlight)
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 (View Highlight)
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 (View Highlight)
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. (View Highlight)
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%.” (View Highlight)
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. (View Highlight)