The Efficiency Paradox: Why Busy Teams and Waiting Work Go Together

You have felt this as a customer. A form you submitted took three weeks to come back, and when it finally did, you could tell the actual work had taken someone about ten minutes. A mortgage application, a passport renewal, a warranty claim: weeks of elapsed time, minutes of real effort. Somewhere in a building your request sat in queue after queue, waiting for attention, while the people who would eventually process it were busy with everyone else's requests, which were also waiting.

That gap between how long something takes and how long it is actually worked on is the single most under-measured quantity in portfolio delivery. Every dashboard in the organisation tracks how busy the people are. Almost none tracks how much of a project's life is spent being worked on rather than waiting. And those two numbers do not just differ. They pull in opposite directions.

Two kinds of efficiency

There are two ways to look at any system that turns effort into outcomes, and they answer different questions.

Resource efficiency asks: how fully are we using the people? It watches the worker. If a specialist is booked solid, resource efficiency is high, and the organisation feels well run. This is the number timesheets, allocation reports and utilisation dashboards are built to produce.

Flow efficiency asks a different question: of all the time this piece of work has been alive, how much of it was actually being worked on? It watches the work item, not the worker. You take the touch time, the hours someone spent actively moving the work forward, and divide it by the total elapsed time from start to delivery. The rest of that elapsed time, usually the vast majority, is the work sitting in a queue waiting for someone to get to it.

The same portfolio scores completely differently on the two measures. A team can be ninety-five percent resource-efficient while the work flowing through it is five percent flow-efficient. Everyone is busy; nothing is moving.

The number is lower than anyone expects

When organisations actually reconstruct the timeline of a delivered piece of work, marking every stretch as either touched or waiting, the flow efficiency they find is routinely in the range of five to fifteen percent. In portfolios heavy with handoffs and shared specialists, single digits are common. A project that lived for six months often contains three or four weeks of genuine work. The other five months are waiting: waiting for a decision, waiting for a review, waiting for the one person who can do the next step, waiting behind three other projects for the same constrained resource.

Leaders find this hard to believe, because nothing they look at shows it. Every instrument on the dashboard is a resource-efficiency instrument. Utilisation is high, allocation is full, people are visibly working hard, and the story those numbers tell is of a lean, productive operation. The waiting is invisible because it happens to the work, not to the workers, and no one is watching the work.

Why busy people and waiting work go together

Here is the part that turns this from an observation into a paradox. High resource efficiency does not merely coexist with low flow efficiency. It causes it.

To keep every person fully booked, you need a queue of work waiting in front of each of them. If there were no backlog, the moment someone finished a task they would sit idle until the next one arrived, and utilisation would drop. So a fully utilised system is, by definition, a system in which work is always waiting for people. The backlog that guarantees no one is ever idle is the same backlog that guarantees every work item spends most of its life in a queue. You cannot maximise the busyness of the resources and the speed of the work at the same time. Pushing one down pushes the other up.

This is the same mechanism behind the utilisation trap, seen from the other side. That piece follows the resource and shows how loading it towards a hundred percent makes its queue explode. This one follows the work item and shows what that exploding queue feels like from inside the project: a deliverable that is ready to move but cannot, because the resource it needs is busy being efficient for someone else.

Low flow efficiency manufactures its own workload

The most expensive part of the paradox is that long waiting does not just delay work. It creates more work, which then justifies keeping everyone even busier.

When a piece of work sits for weeks between touches, the context around it goes stale. The person who picks it up again has to re-familiarise themselves with where they left off. Requirements drift while the work waits, so some of it has to be redone. Other people, unable to see when their thing will be finished, start chasing status, raising tickets, calling meetings and escalating, each of which is a fresh demand on the same busy specialists. Defects introduced early are not found until a distant later stage, by which point fixing them is far more costly than catching them fresh would have been.

None of this work would exist if the item had flowed through quickly. It is pure overhead generated by delay, and it lands squarely on the constrained resources, making them busier still. So the organisation looks at its overloaded specialists, concludes it needs to extract even more from them, drives resource efficiency higher, lengthens the queues further, and generates yet more re-work and chasing. The paradox feeds itself. A lot of what a busy portfolio is busy with is the self-inflicted cost of its own slowness.

How to see it

You cannot manage flow efficiency without measuring it, and you cannot measure it from the resource-efficiency dashboard. You have to follow a work item.

Take one recently delivered project or deliverable. Reconstruct its actual timeline from the day work started to the day it delivered. Mark every stretch as either touch time, when someone was actively working on it, or wait time, when it sat waiting for a person, a decision or a review. Add up the touch time and divide it by the total elapsed time. That fraction is your flow efficiency, and the first time most teams calculate it honestly, the answer changes the conversation. The problem was never that people were not working hard enough. It was that the work was barely moving.

Do this for a handful of items and a pattern appears: the waiting clusters at specific points, almost always the handoffs into and out of the constrained resource. That is not a coincidence. It is where the queues are, and the queues are where your delivery time is actually spent.

What to manage instead

The remedy is not to relax and let people be idle for its own sake. It is to stop treating resource efficiency as the goal and start treating flow, the speed at which work moves through the system, as the thing you are actually optimising.

Cap the work in progress. The fewer items in the system at once, the shorter the queues each one waits in, and the higher the flow efficiency, on exactly the same capacity. This is the discipline of starting less to finish more, and flow efficiency is the number that makes its payoff visible.

Protect a margin on the constraint. The reserve capacity that resource-efficiency thinking wants to eliminate as slack is what lets the constraint's queue clear between arrivals, which is what keeps work flowing rather than piling up. Reserve on the constraint is not waste; it is where flow comes from, and defending it is central to escaping the utilisation trap.

Sequence the constrained resource by economic return. When work does compete for the scarce hours, let value per constrained resource hour decide the order, so the queue that remains is spent on the work that returns the most.

And change the headline number. Utilisation answers "are the people busy," which the organisation already knows and which does not govern delivery. Flow efficiency and flow time answer "is the work moving," which is the question that decides when value actually arrives.

The shift

Resource efficiency is intuitive, easy to measure and deeply reassuring, and as a primary goal it is quietly ruinous. It rewards the exact condition, a full backlog in front of every person, that leaves work standing still, and it hides the cost by measuring the one part of the system, the worker, that always looks productive.

The counter-intuitive move is to stop asking whether everyone is busy and start asking whether the work is moving. Follow the item, not the person. Watch how much of a project's life is spent being worked on rather than waiting, and manage to raise it. A portfolio does not deliver value when its people are fully booked. It delivers value when its work stops waiting.

---

Flow Economics is the discipline of understanding how value actually moves through an organisation when its resources are constrained, and of making decisions that maximise what the whole system delivers rather than what each part looks like on its own. If your portfolio is measured by how busy its people are rather than how fast its work finishes, the Flow Economics framework is a good place to see the full picture.