Your data team is fully utilized. Tickets are flowing, meetings are back-to-back, the sprint is full. And yet the roadmap is not moving, the business is still complaining about data quality, and nothing has measurably changed in six months. The problem is almost never the people. It is where their time is actually going versus where you think it is going.
What leadership sees versus what is actually happening
When you look at your data team from the outside, you see activity. Jira is full. Everyone is in standups. The Head of Data tells you the team is at capacity.
What you do not see is the composition of that capacity. How much of it is planned work, the initiatives on the roadmap that are supposed to move the business forward? And how much of it is unplanned work, the incidents, the ad-hoc requests, the support tickets, the emergency fixes that arrive without warning and consume the day?
In most data teams I have worked with, the split looks something like this: leadership believes 60–70% of capacity is going to planned roadmap work. The reality, once you measure it, is closer to 40%, or less.
The rest is invisible to the outside. It is reactive, unplanned, and it kills velocity without leaving a trace in any report.
The three forces consuming your team's capacity
Every hour a data team spends falls into one of a few categories. The ones that quietly drain the roadmap are these:
Incidents. A pipeline breaks. A dashboard shows the wrong numbers. A stakeholder escalates a data quality issue at 9pm. The team drops everything to fix it. The cost is not just the hours logged, it is the full context switch. Every incident pulls an engineer out of deep work, and the cognitive cost of recovering focus is 2–3 times what the incident log shows.
Ad-hoc requests. "Can you pull the numbers for this meeting?" "We need a quick analysis before Thursday." These requests feel small individually. Across a week, they consume hours that were never planned for. When ad-hoc requests are consistently high for a specific product or team, it is a signal: the data product is not fit for purpose and the business has started routing around it.
Support. Users who cannot interpret the data. Stakeholders who need the same explanation for the third time. Business teams who cannot access what they need without help. All of this lands on the data team.
None of these appear in the sprint plan. None of them are visible to leadership unless someone is explicitly measuring them. They compound quietly until the roadmap has effectively stopped.
Why adding headcount does not solve it
The instinctive response to a team that cannot keep up is to hire. More engineers, more analysts, more capacity.
But if the problem is reactive overload, not a shortage of raw capacity, adding people makes it worse. More people means more handoffs, more coordination, more surface area for incidents. The reactive work grows to fill the expanded team.
I have seen organizations double their data team size over two years with no measurable improvement in delivery velocity, because the new hires were immediately absorbed by the same support and incident load that was already consuming the original team.
The answer is not more people. The answer is a different allocation model.
What a healthy allocation looks like
A data team operating well is not one that is maximally busy. It is one where the split between planned and unplanned work is visible, intentional, and managed.
The goal is to protect three distinct functions simultaneously:
Maintenance, keeping existing products healthy and reliable. This is not optional. But it should be proactive, not reactive: scheduled reviews, monitoring, pipeline health checks. A team doing good maintenance work is one whose incident rate is falling over time, not holding steady.
Rollout, making sure new products actually get adopted after they are built. This is the most skipped step in most data teams. A product gets deployed and the team moves on. Six months later, the business is still using the spreadsheet because nobody supervised the transition. Every weak rollout is future reactive load.
Innovation, building new capabilities. This is the work that is supposed to generate the roadmap progress you are not seeing. It needs protected time. Not a slot at the bottom of the sprint after everything else is done, but a genuine allocation that does not get cannibalized by incidents.
The problem in most teams is that these three functions are never separated. Innovation time is raided the moment an incident arrives. The rollout step gets skipped because the team is already behind. And maintenance is reactive rather than planned, which means more incidents, which means less innovation time. It becomes a cycle.
How to break the cycle
The first step is measurement, not reorganization. Before you change anything, you need to know what the split actually is. Ask your team to categorize their time for two weeks, not in a burdensome way, but by simple buckets: planned work, incidents, support, ad-hoc, blocked. Two weeks of honest data will show you where the capacity is going.
What you find almost always surprises the leadership team. Not because the data team was hiding it, but because it was never visible before.
Once the split is visible, the conversation changes. Instead of "why is the roadmap not moving," the question becomes: "what do we need to remove from the reactive pile to give innovation the space it needs?" That is a solvable problem. The other question is not.
The second step is protection. Innovation time needs to be defended, not hoped for. That means a support rotation where one person handles all reactive requests during defined windows, so the rest of the team can stay in deep work. It means incidents have a response protocol that contains the damage rather than pulling everyone in. It means rollout is treated as a first-class deliverable, not an afterthought.
None of this is complex. But it requires acknowledging that the problem is structural, not a matter of effort or talent.
The question worth asking this week
Without measuring, ask your Head of Data one question: in the last sprint, what percentage of actual hours went to work that was on the plan at the start of the sprint?
If they cannot answer confidently, or if the number is below 50%, you have found your problem. The team is not underperforming. The system has no structure to protect performance.
That is worth a conversation. Book 30 minutes here, no slides, no pitch deck, just a direct look at where the capacity is going and what would need to change.