I have sat in enough delivery reviews to recognise the moment before someone says it. A managed team is behind schedule, the sprint board is full, and the leader across the table is already reaching for the obvious fix. More people. A bigger pod. Another req opened against next quarter’s budget.
Almost every time, that is the wrong diagnosis. When I actually sit with the team’s board, the problem is rarely a shortage of hands. It is that too many things are moving at once, and everyone on the team is a partial owner of five priorities instead of a full owner of one. Nobody is idle. Everyone is behind. Those two facts coexist far more often than leadership expects, and they point to a completely different fix than headcount.
This matters more for managed teams specifically than for in-house teams, because a managed team’s entire value proposition is throughput per dollar. If a client keeps adding parallel priorities without ever removing one, the pod’s velocity degrades in a way that looks like a staffing problem from the outside and a prioritisation problem from the inside. Getting that diagnosis right is the difference between a budget conversation and an operating model conversation.
Why Adding Headcount to a Scattered Team Rarely Works
The instinct to add people comes from a reasonable place. If output is low relative to the size of the ask, more capacity should close the gap. But capacity is not the constraint in most delivery slowdowns I am asked to review. Coordination is. A six or eight person pod juggling nine active workstreams is not short on engineers. It is short on finished work, because every engineer is context switching between commitments that were all promised as urgent.
Adding a ninth person to that pod does not remove any of the nine workstreams. It gives you one more person to scatter across them. Within a sprint or two, the new hire is absorbed into the same pattern, and the team’s velocity per person actually drops, because onboarding time and coordination overhead now compete with the existing nine priorities for the same finite attention. I have watched this happen enough times that I no longer treat “we need more people” as a starting assumption. I treat it as a symptom worth investigating before it becomes a budget line.
The Six Person Team That Outperformed a Larger One
A few years back I worked with a managed team of six engineers supporting a client’s core platform. Leadership on the client side believed the team was under-resourced, largely because delivery had slowed and the backlog kept growing. Before agreeing to expand the pod, we mapped every active workstream the six engineers were nominally responsible for. There were nine, spanning three different product areas, each with its own stakeholder pushing for priority.
We did not add a single person. Instead, we cut the active workstreams from nine to three, deferring the rest to a visible, dated queue rather than letting them run in parallel unfinished. Within a month, the same six engineers shipped more completed work than they had in the previous quarter. Same headcount. Same skill level. The only variable that changed was how many things they were allowed to be responsible for at once.
The numbers on a dedicated delivery pod look very different compared to what slow hiring actually costs over the same period.
Under-Resourced and Over-Committed Look Identical From the Outside
This is the part that trips up otherwise sharp operators. From a dashboard, a team that is genuinely short-staffed and a team that is genuinely over-committed produce the same visible symptom: work is not getting done on time. The dashboards do not distinguish between the two causes, and the emotional read from stakeholders is the same in both cases, frustration with the pace of delivery. But the fixes are opposites. Under-resourced needs more capacity. Over-committed needs fewer commitments. Applying the wrong fix does not just fail to help, it can actively make the real problem worse by adding coordination load to an already fragmented team.
The way to tell the two apart is simple, though it requires discipline to actually do it. List every active workstream the team is nominally responsible for right now, not the roadmap, the active ones. Then ask how many people are genuinely, fully dedicated to each one without competing claims on their time. If the answer is that most people appear on three or four lists simultaneously, you are looking at an over-commitment problem, regardless of how thin the team feels day to day.
What This Means for How You Brief a Managed Team Partner
If you are the client side of a managed team relationship, the operating discipline is largely yours to set. A managed team partner will generally execute against whatever priority list you hand them, including a list that quietly asks six people to make meaningful progress on nine fronts. The healthiest engagements I have seen are the ones where the client is willing to say no to a new priority until an existing one is finished, rather than adding it to the pile and asking the pod to “just fit it in.”
That discipline is uncomfortable in the short term, because it means telling an internal stakeholder that their request will wait. It is far less costly than the alternative, which is telling every stakeholder that their request is in progress while none of them actually finish. A managed team that is allowed to focus will consistently outperform a larger team that is not, and the cost difference between the two paths shows up directly in your delivery timeline, not just your headcount budget.
The teams I trust most are not the biggest ones. They are the ones whose leadership had the discipline to protect focus even when every stakeholder wanted their priority moved to the top of the list. That discipline, more than any additional hire, is what actually predicts whether a managed team ships on time.
Most teams that move to the pod model ask the same question afterward, why didn’t we do this a year ago.

