Ask a leadership team how the portfolio is doing and the answer is usually the same. Everyone is busy. The resource utilization report shows the engineering teams at 90% or above, every specialist has a full plate, and nobody is sitting idle. By the measure most organizations watch most closely, this is a well-run operation. It is also the first half of the Capacity Paradox.
Then look at the delivery dates. Projects are late, not occasionally but routinely, and the slippage grows from one quarter to the next. Clients escalate. The teams are exhausted and cannot see why their effort is not turning into results.
The two pictures are not in conflict. The first is causing the second.
What is the Capacity Paradox?
In a system where projects share people, driving those people toward full utilization makes the organization slower, not faster. That is the Capacity Paradox. It is a property of systems under load, not a failure of effort. Nobody involved needs to be lazy, careless or badly managed for it to happen. Variable work plus too little spare capacity is enough.
The paradox is that past a point, the number everyone pushes up, utilization, stops buying more of what the organization actually wants, throughput, on-time delivery and value arriving sooner, and starts costing it.
Resource utilization is a reasonable thing to measure. It tells you whether you are paying for capacity you are not using, and in a single team doing predictable work it is a fair guide. Where it breaks is when it becomes the target for people shared across many projects with variable work. Past a point, every extra percent of utilization buys a longer queue, and the queue is where delivery time goes.
Why does high utilization slow everything down?
When work arrives unevenly and tasks vary in size, keeping a person fully booked means keeping work waiting in front of them. Without a backlog, they would finish a task and sit idle until the next one arrived, and their utilization would drop. So a shared resource held near full utilization is, in practice, one with a queue, and one with no spare time to clear it when something unexpected lands. That queue is where every project touching that person spends its time.
The queue does not grow in step with the load. It grows much faster. Take the standard textbook case: a single shared resource, with work arriving at random and task times varying widely (queueing theory calls it the M/M/1 queue). There, the average time work waits is utilization divided by one minus utilization, measured in multiples of the time the work itself takes:
| Utilization of the shared resource | Average wait, in multiples of the work time |
|---|---|
| 50% | 1 |
| 80% | 4 |
| 90% | 9 |
| 95% | 19 |
At 50%, work waits about as long as it takes to do. At 90%, it waits 9 times as long. The step from 90% to 95% looks like a rounding error on a capacity report, and it roughly doubles the wait. Our piece on resource utilization works through this curve in more detail.
That is not a management philosophy. It is how queues behave.
Why nobody sees it coming
What makes the paradox dangerous is the shape of that curve. It steepens so sharply near the top that in practice it behaves like a tipping point. The penalty does not seem to arrive gradually. It seems to arrive all at once.
A loaded portfolio keeps absorbing work and shows no distress, because the cost is building up in queues that no status report displays. Each project's plan shows its own work, not the weeks it will spend waiting for a shared specialist. Then one more project lands on the same people, and a cluster of projects goes late at once. It looks like a sudden failure. It is the predictable result of a load that was too high all along.
In a Flow Economics controlled portfolio simulation, a shared specialist group was driven to full load while the portfolio as a whole delivered at barely a third of its productive potential. By every conventional report, the group was fully utilized. Busy and productive had come completely apart.
Where does the time actually go?
Follow a single piece of work instead of a single person and the paradox becomes visible. Take a recently delivered design, analysis or review, and mark every stretch of its life as either touch time, when someone was actively working on it, or wait time, when it sat in a queue. Touch time divided by total elapsed time is its flow efficiency.
When organizations measure it honestly, it is often well under a quarter. A task that needed 6 hours of a specialist's attention and took 3 weeks to come back spent almost all of its life waiting. Making those 6 hours faster changes almost nothing. The opportunity is in the 3 weeks, and those 3 weeks are often driven largely by how heavily the specialist is loaded and the queue that load creates.
The distinction between resource efficiency and flow efficiency is set out in Niklas Modig and Pär Åhlström's This is Lean (2012), and Mike Hannan's work has done a great deal to carry flow efficiency into the management of project portfolios. The Capacity Paradox: why busy teams and waiting work go together takes the measurement further.
The usual response makes it worse
When delivery slips, the instinct is to look for the blockage. Leaders scrutinize the late projects, add governance, push the busiest people harder, consider hiring, and buy a better scheduling tool.
Each of those responses is reasonable, and most of them add load to the people who are already the queue. More status reporting is more work for the same specialists. More pressure produces more switching between tasks, and every switch costs the time it takes to put one problem down and rebuild the context of another. Pressure does not remove the queue. It feeds it.
Does this mean paying people to sit idle?
No. Underloading does not mean idleness. A team planned well below full load is still working hard. The remaining capacity is the room that lets it absorb the variation a live portfolio keeps throwing at it, the urgent review, the returned design, the risk that lands on a Tuesday, without that variation turning into a queue that delays everything behind it.
The one place that should not be underloaded is the constraint, the resource in shortest supply, because an hour lost there is an hour lost to the whole portfolio. The way to keep it productive is not to pile more work on it. It is to keep it fed with work that is ready, and to start new projects only as fast as it can take them. Finding it is the first job. Everywhere else, spare capacity is not waste. It is what lets work move.
The two costs are not shown in the same place, which is why organizations choose the expensive one. The cost of reserve capacity is small and sits on a spreadsheet as salary. The cost of running without it is the value of every project delayed by the queues that full loading creates, spread across business cases nobody revisits.
It starts when work is let in
The easiest way to make every team look fully utilized is to start more work. That is exactly the behavior that drives the shared resources up the curve. So the paradox is not only a consequence of how work is run. It begins at the moment work is approved, often on a business case that never asks what the new project will do to the projects already competing for the same people. The price of yes looks at that decision.
The practical lever is to cap the work in progress and release new work only as the constraint frees up. Fewer items in the system means shorter queues and faster finishes on exactly the same capacity. That is the discipline of starting less to finish more.
The better question
The question most organizations ask is whether everyone is busy. They already know the answer, and it does not govern delivery.
The better question is how long work waits for your scarcest people, and what those people should not be working on. Answer that and the utilization report gets worse while delivery gets better. The busiest organization and the fastest organization are rarely the same one. Past a point, they cannot be.
---
Flow Economics is the discipline of understanding how value actually moves through an organization when its resources are constrained, and of making decisions that maximize what the whole system delivers rather than what each part looks like on its own. The Flow Economics framework is a good place to see the full picture.
Leave a Reply