What a complex program with senior delivery management reports and what it is producing have come apart. The status board shows green. The risk register has been worked through. Steering committees are populated and well-attended. Eighteen months of investment has produced reporting maturity, yet the outcomes the program was funded to deliver remain stubbornly out of reach. Something is absorbing the work. The usual response is to add more people who can see it absorbing.
In Brief
- The costliest trade a transformation makes is the one it doesn't notice: adding a senior delivery layer that converts product decisions into administrative ones.
- Communication paths multiply with group size and motivation declines as it grows — every coordination layer carries a measurable cost (Brooks, 1995; Latane et al., 1979).
- It's the structural seniority of the layer — not the calibre of the person in it — that relocates decisions and slows them.
- Throughput is recovered by changing where decisions sit, not by adding people to ask for status on them.
The reflex is understandable, and in most cases it is well-evidenced. A program that is missing its outcomes appears to need more management attention. The case for additional delivery seniority writes itself. Yet the pattern that surfaces across complex programs is the reverse of what the reflex predicts. Throughput does not recover, and in many cases it falls further. The diagnosis required is structural, not personal, which is precisely what makes it expensive.
Adding senior delivery management adds a coordination layer, not delivery capacity
Adding a senior delivery layer to a complex program rarely adds delivery capacity. It adds a coordination layer that sits between the work and the decisions the work needs. Product decisions about what to build, what to descope, and what to release depend on direct contact with the customer, the technology, and the trade-offs that surface during build. When a delivery management layer is interposed, those decisions migrate upward into a register that is procedural rather than substantive. They turn into forecast updates and approval items. The decision still happens; it simply no longer happens where the information lives.
This shift is the most expensive trade a complex program tends to make, because the cost is not visible on the program plan. It does not appear as a line item. It appears as latency between question and answer, as backlog items waiting on a fortnightly forum, and as design choices framed for approval rather than tested against use. By the time the cost is measurable, the program has already absorbed it.
Communication paths grow quadratically, so adding people slows the work down
The mathematics of coordination has been understood since the 1970s. Brooks (1995) observed that each person added to a software effort introduces new communication paths, n(n-1)/2 of them for a group of n. A team of five carries 10 communication paths; a team of ten carries 45; a team of twenty carries 190. Communication load grows quadratically while productive capacity grows arithmetically, which means that beyond a small group size each additional person consumes more coordination than they contribute. Brooks was writing about software. The dynamic generalises wherever the work is genuinely cognitive and the interdependencies between people are tight, and complex transformation programs sit squarely in that category.
Group size also carries a motivational dimension that is often missed. Latane, Williams and Harkins (1979) demonstrated experimentally what Ringelmann had observed in rope-pulling studies six decades earlier. As group size increases, the effort each individual contributes declines, even when coordination losses are controlled for. They named the phenomenon social loafing, and the literature since has confirmed it across cognitive and creative tasks alike. The implication for a complex program is uncomfortable but precise. Adding people also tends to reduce the per-person contribution. Both effects compound, and they compound fastest when the work is non-routine and the accountability is diffuse, which describes most transformation programs.
Senior delivery management shifts decisions upward
Naming these dynamics is not an argument that the people in senior delivery roles are the wrong people. They are usually exactly the right people, doing what their accountabilities require. The problem is structural. A senior delivery role, by virtue of its position, attracts decisions to itself, which is what such a role is designed to do. When that role is added to a program with its decision architecture already in place, the new role does not slot into a gap. It changes the topology. Decisions that were previously made close to the work are now made one layer up. The shift is rarely conscious, and it is almost always defended on the basis that the program needs stronger governance.
What complex programs need instead is the opposite of what the reflex prescribes. Decision rights have to be held by the people doing the work. The number of forums has to come down. Feedback loops between question and answer need to shorten. The senior accountabilities that already exist should focus on the few decisions only they can make, the trade-offs that genuinely require their position, and they should actively delegate the rest. This is uncomfortable for senior leaders who have been told their job is to be across everything, but it is what the structure of complex work demands.
Cycle time falls by an order of magnitude when decision architecture is rebuilt
An organisation we worked with restructured along these lines and observed an order-of-magnitude reduction in cycle time within a single uplift. The shift that magnitude represents is more interesting than the magnitude itself. The same people, in the same organisation, with the same investment, were producing outcomes materially faster because the decision architecture had been rebuilt around where the information actually was. No new technology was introduced. No additional headcount was approved. The cost of the change was almost entirely the cost of being willing to let go of the layer that had been added in good faith.
The executive who recognises this pattern early is in a stronger position than the executive who recognises it after the second restructure. The recognition is not that the program is being poorly managed. It is that the cost of management has crossed the line at which management starts to consume the thing it was meant to enable. Throughput in a complex program is not recovered by adding people who can ask for status on it. It is recovered by changing where decisions sit, so that status becomes a by-product of the work rather than a request placed against it.
Risk in a complex program does not live where the oversight is. It lives where the decisions are. Until those two are the same place, no amount of additional management will close the gap.
What this means for senior leaders
First, adding a senior delivery management layer to an existing complex program is a structural change to the decision architecture, not a personnel change, and the decision relocation it causes should be forecast before the role is approved.
Second, when a program is missing outcomes, the audit that matters is where product decisions are actually being made; if they have migrated upward into approval registers, the constraint sits in decision architecture, and more oversight will compound it.
Third, senior accountabilities should be held to the few decisions only they can make, and the rest delegated explicitly, because the instruction to be across everything is the instruction that draws decisions away from the work.
Fourth, the cost of a coordination layer should be measured in latency between question and answer rather than in headcount, because latency is the symptom that surfaces while there is still time to act on it.
Fifth, cycle time is the cleanest leading indicator of decision architecture quality, and an order-of-magnitude reduction is achievable without new technology or new headcount when the layer between work and decision is removed.
References
- Brooks, F. P. (1995). The mythical man-month: Essays on software engineering (Anniversary ed.). Addison-Wesley.
- Latane, B., Williams, K., & Harkins, S. (1979). Many hands make light the work: The causes and consequences of social loafing. Journal of Personality and Social Psychology, 37(6), 822-832. https://doi.org/10.1037/0022-3514.37.6.822
