Three Levels of Data Team Maturity: A Practical Rubric

I have worked in data consulting for most of my career, and this has afforded me the opportunity to sit across the table from dozens of data teams across SaaS and DTC companies, each with a different tool stack, headcount, and org structure.

A data team, for the purposes of this piece, is the function inside a company responsible for turning raw information, product usage, sales activity, marketing spend, and so on, into decisions the rest of the business can actually act on. What stays constant across nearly every engagement, regardless of how that function is staffed or tooled, is that its underlying operating model falls into one of three levels. Most teams have never been asked to name which one they’re actually in.

Here’s the rubric.

The Ad Hoc Data Team

Operating mode: The team functions as a request queue. Work is initiated by whoever asks first, not by business priority, and every request is treated as new even when it’s a near-duplicate of something answered weeks earlier.

Signals:

• Data quality issues surface after a stakeholder finds them, not before
• Sprint reporting describes completed tasks, not the business outcome those tasks served
• Ownership is assigned to tickets, not to functions. No one can name who is accountable for a given metric or domain end to end
• The same question gets answered multiple times, by multiple people, with slightly different numbers each time, because there is no shared definition to point to

Diagnostic question: Ask three different stakeholders who they’d go to for the same type of request. If the answers are inconsistent, or “whoever’s free that day,” there is no real ownership behind the work, no matter what the org chart says.

Risk: This is typically not a skills gap but a structural one. A data function that was added to the org chart reactively, rather than designed with clear scope from the start, tends to stay organised around incoming requests instead of business outcomes indefinitely, regardless of how senior the hires brought in to fix it are. Hiring more experienced people into an ad hoc structure usually just produces more experienced firefighters.

The Governed Data Team

Operating mode: The team has introduced governance. Recurring requests are absorbed into shared definitions rather than answered independently each time, and two types of work now run in parallel: standardisation of existing metrics, and net-new analysis.

Signals:

• A stakeholder asking “do we have an existing definition for this?” gets a clear, fast answer
• Individual contributors hold ownership over defined functions or domains, not just assigned tickets
• A semantic or metric layer exists, and it is the first place people check before building something new
• Self-service adoption is real but uneven. Some stakeholders can pull their own numbers; others still route everything through the team

Diagnostic question: Pull any three stakeholder requests from the last month. Can you trace each one to where it now lives in a governed metric layer?

Risk: This level is the easiest to mistake for the finish line. A metric layer and a dashboard suite are visible signs of progress, which makes it tempting to treat governance as the end state rather than a checkpoint. Industry research on self-service analytics backs this up directly: organisations that expand data access faster than they expand governance tend to end up with parallel, conflicting versions of the same report, sometimes called shadow analytics, where teams spend more time debating whose number is correct than acting on any of them. Governance without a plan to keep extending it degrades on a fairly predictable timeline. The team, at this level, is still fundamentally responding to demand. It has just gotten efficient at responding.

The Strategic Data Team

Operating mode: The team operates ahead of stakeholder demand. Data work is initiated based on business risk and opportunity that the team identified on its own, not incoming requests.

Signals:

• Data issues are flagged and resolved before a stakeholder raises them
• Self-service adoption is high enough that the team’s core function has shifted to governance, edge cases, and protecting definition integrity, rather than one-off analysis. This lines up with what executives report more broadly: nearly half cite self-service data access as a direct driver of employee productivity, which only holds up when the underlying definitions are trustworthy enough to self-serve from
• Any individual contributor on the team, at any level of seniority, can state the business objective their current work serves, without checking with a manager first
• The team can point to at least one instance in the last quarter where it changed a business decision before being asked to weigh in

Diagnostic question: Ask your most junior analyst why their current project matters to the business. Can they answer without checking with you first?

Risk: Teams at this level are well positioned to develop secondary capabilities, including internal advisory work, mentorship, or external thought leadership. That capacity is a byproduct of reaching this level. It should not be mistaken for the definition of it, and leaders who chase the visible byproducts, like publishing content or running internal training, before the underlying operating model earns them, tend to produce the appearance of a strategic team without the substance.

What to Do Next

The instinct, after reading a framework like this, is to aim straight for the top. That instinct should be resisted. The more useful first step is establishing, with evidence rather than assumption, which level the team is currently operating at. Work through the three diagnostic questions above with a specific, recent example for each.

The goal underneath all three levels is the same: to be run as a product, not a service desk. This isn’t a new idea either. It’s the same logic behind the data as a product principle inside data mesh architecture, where domain teams treat their data the way a company treats a product it sells, with a defined set of users, an accountable owner, and a roadmap that improves it on purpose rather than by accumulation of one-off fixes. A service desk exists to close whatever ticket arrives next. A product exists to serve someone well, on purpose, over time.

Whatever level the diagnostics put a team at, the next concrete step is the same: identify one function that currently exists only as a stream of tickets, and assign it a named, accountable owner, the way a product has a product owner. That single structural change moves a team’s maturity level more reliably than any tooling migration, and it’s also the clearest signal a leader can put in front of a company deciding who should be trusted to run this function for them.