How to Find the One Resource That Sets Your Delivery Speed

Almost every piece of advice in Flow Economics begins with the same instruction: find your constraint. Protect the constraint. Sequence by value per hour of the constraint. Do not load the constraint past the point where its queue explodes. It is the hinge the whole discipline turns on.

And almost nobody tells you how to find it.

The instruction is treated as if the answer were obvious, when in practice it is one of the things organisations most reliably get wrong. Ask a leadership team which resource limits their delivery and they will usually point at the team that looks busiest, complains loudest, or has the longest backlog. Sometimes that is the constraint. Often it is not, and optimising the wrong resource is worse than doing nothing, because it feels like progress while the real bottleneck goes on setting the pace untouched.

So this piece is about the step the rest of the method depends on: how to actually identify the one resource that governs how fast your portfolio delivers.

The constraint is not your busiest team

The most natural mistake is to equate the constraint with high utilisation. The busiest team must be the bottleneck, surely, because they are the ones with no room left.

But utilisation only tells you how full a resource is. It says nothing about whether that resource sets the speed of the whole system. A team can run at a hundred percent and not be the constraint at all, if the work they produce simply flows into a queue somewhere else and waits. They are busy, but they are busy building inventory that a later step has not caught up to. Loading them harder would not speed anything up; it would just grow the pile in front of the true bottleneck.

The constraint is a different thing. It is the resource that governs the pace of the entire flow: the step that, if it stopped, stops delivery across the portfolio, and that, if it sped up, speeds up everything downstream of it. Every unit of work the organisation actually completes has to pass through it. That is what makes it the constraint, not how full its calendar looks.

So the question to ask is not "who is busiest?" It is "what is everything waiting for?"

Read the queues, not the people

The most reliable way to find the constraint is to stop watching the workers and start watching the work.

Follow a representative piece of work from the moment it starts to the moment it delivers, and mark every point where it sits idle. This is the flow-efficiency lens: in most knowledge work, a task spends the large majority of its life waiting, not being worked on. The places it waits are not random. Work piles up in front of the constraint and thins out behind it, for the same reason traffic backs up behind the one narrowed lane and runs clear beyond it.

That asymmetry is the tell. In front of the constraint, a queue forms and does not clear. Behind it, resources go quiet, waiting for the constraint to hand something on. If you can see where work consistently accumulates on one side and starves on the other, you have found the resource that everything is pacing itself against.

A few practical signals point the same way, and they are worth looking for deliberately:

Everyone waits on the same name. When work stalls, the explanation keeps resolving to one team, one skill, or one person. Escalations converge on the same desk.

Expediting always routes through them. When something genuinely urgent has to be pushed through, it is their time that has to be freed up to do it. You do not expedite through spare capacity; you expedite through the bottleneck.

Their availability sets the dates. Delivery commitments across unrelated projects all seem to bend around the same resource's calendar. When they take leave, multiple plans move.

Other people are blocked rather than busy. Around the constraint you find resources that are idle not because there is no work, but because the work they need is still sitting in the constraint's queue.

None of these on its own is proof. Together they converge on the resource that is actually governing your throughput.

The clone test

Here is a quick sanity check once you have a candidate. Imagine you could clone one resource for a month, at no cost, and put the duplicate to work. Whose copy would clear the most stalled work across the portfolio?

If cloning your candidate would unblock a dozen waiting projects, you have almost certainly found the constraint. If cloning them would just produce more output that then sits waiting somewhere else, you have found a busy non-constraint, and the real bottleneck is further along. The test forces you to reason about the whole system rather than about who looks stretched, which is exactly the shift that finding the constraint requires.

It may not be a person at all

The word "resource" invites you to look for a team or an individual, and often that is right. But the thing setting your pace is frequently not a person.

It can be a shared asset: a single test environment, one piece of specialist equipment, a licence with a seat limit. It can be a specific skill held by only a handful of people inside an otherwise large team, so that the team looks well staffed while the one capability everything depends on is desperately thin. And very often the real constraint is not physical at all. It is a policy: a sign-off that only one committee can give, a governance gate that meets fortnightly, a rule that work cannot start until a document is complete. A policy constraint throttles flow just as effectively as a scarce specialist, and it is cheaper to fix, because you can change a rule faster than you can hire a rare skill. It is also the constraint people are least likely to look for, because no one is visibly overloaded. The queue forms in front of a decision, not a desk.

So when you trace the waiting, do not stop at the first busy team. Ask what that team is itself waiting for. Sometimes the answer is another resource. Sometimes it is a signature.

The constraint moves, and that is fine

One more thing to expect: the constraint is not permanent. Relieve it, and the bottleneck shifts to whatever the next-slowest necessary step is. That is not a failure of the analysis; it is the system telling you the first constraint is no longer the binding one.

This unsettles people, because it seems to mean the ground never stops moving. In practice the constraint moves far more slowly than the anxiety about it suggests. It does not change week to week, and chasing it at that frequency is just reacting to noise. Locate it, work with it deliberately, and re-check when something structural changes: a big piece of work finishes, a key person leaves, demand shifts. The constraint is a slow-moving fact about your system, not a live feed.

Why getting this right is the whole game

It is worth being blunt about the stakes, because they are asymmetric in a way that is easy to miss.

An hour lost on the constraint is an hour of portfolio throughput lost, and it cannot be recovered, because everything the organisation delivers has to pass through that resource. There is no slack behind it to make the time back. An hour saved on a non-constraint, by contrast, is worth almost nothing: that resource had spare capacity anyway, so making it faster just means it waits a little longer for the constraint, like the rest of the system.

That asymmetry is why identification comes first and everything else second. Every lever Flow Economics offers - protecting a margin of reserve capacity so the constraint's queue can clear, capping the work in flight so it is not buried, sequencing by value per constrained resource hour, pricing a new commitment before you accept it - every one of them acts on the constraint. Aim them at the wrong resource and you get local efficiency bought at the cost of global throughput: a team that gets measurably faster while the portfolio does not move, because you tuned a step that was never the thing holding delivery back.

The shift

The default way organisations spread improvement effort is evenly, because every team looks busy and every team asks for help. Flow Economics says the opposite: most of your resources are not what limits you, and effort spent on them is effort that does not reach the finish line. Find the one resource that governs the pace, and concentrate there.

That is why finding the constraint is not really the first step of the method. It is the step the rest of the method stands on. Name it correctly and every other move - protect, cap, sequence, price - lands where it changes the outcome. Name it wrongly and the same moves, executed just as diligently, change nothing at all. Before you optimise anything, be sure you know which resource is actually setting your speed.

---

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 improvement effort is spread evenly across every team rather than aimed at the one that governs delivery, the Flow Economics framework is a good place to see the full picture.