In short
Find the bottleneck by looking for where work accumulates, not where people feel busiest. Walk your workflow and record the queue in front of each step: the constraint is the step with the largest and most persistent backlog upstream of it. Fix it in this order — stop overloading it, remove work that does not need to pass through it, then increase its capacity. Adding capacity first is the most expensive option and frequently unnecessary, because most constraints are carrying work that should never have reached them.
Key takeaways
- A workflow has one constraint at a time. Improving anything else adds cost without adding throughput.
- Queues, not busyness, reveal the constraint. Look for where work waits, not who looks stretched.
- The constraint moves once you relieve it. Re-measure rather than assuming your map is still accurate.
- Most constraints are overloaded with work that should have been filtered, batched or handled elsewhere.
- Limiting work in progress usually improves delivery speed more than any individual efficiency gain.
Every workflow has exactly one constraint
This is the most useful and least intuitive fact in operations. At any moment, one step in a workflow sets the maximum rate at which the whole workflow can produce output. Every other step has slack. Improving a step with slack changes nothing about the output of the system — it just means that step finishes its work earlier and waits longer.
- Constraint
- The step in a workflow whose capacity determines the throughput of the entire workflow. Also called the bottleneck. Its defining characteristic is that work accumulates in front of it and the steps after it are periodically idle.
The practical consequence is uncomfortable: most operational improvement effort is spent on non-constraints and therefore produces no measurable result. A team invests in better tooling for a step that was never limiting anything, throughput does not move, and everyone concludes that process work does not pay. It did not pay because it was aimed at the wrong step.
An hour saved at a non-constraint is not an hour saved. It is an hour of additional idleness at a step that was already waiting.
Finding the constraint: look at queues, not people
The instinctive method — asking who is busiest — is unreliable, because busyness and constraint are different things. People at non-constraint steps are frequently very busy, often because they are handling rework, chasing, or generating more work in progress than the system can absorb.
The queue walk
Take one workflow and one week. At the same time each day, record for every step:
- How many items are waiting to start at this step
- How long the oldest waiting item has been waiting
- How many items this step completed since yesterday
Five days of this is enough. The constraint is the step where the waiting count is consistently highest and, critically, where the oldest item keeps getting older. A queue that grows and drains is a capacity fluctuation. A queue whose oldest item ages steadily is a constraint.
Three corroborating signals
| Signal | What it indicates |
|---|---|
| Steps downstream are periodically idle | They are starved by the constraint upstream |
| Expediting happens at one specific step | People have already discovered the constraint informally and are routing around it |
| One step is where deadlines are habitually renegotiated | The organisation has adapted its promises to this step's real capacity |
That second signal is worth taking seriously. Long before anyone measures anything, teams develop informal workarounds around the constraint — the side-channel request, the favour, the “can you just squeeze this in.” If you want to find the bottleneck quickly, ask where people go when something is urgent.
Fix in the right order: protect, offload, then expand
Once you know the constraint, resist the urge to buy capacity. Work through three options in strict order of cost.
1. Stop overloading it
The constraint is often performing badly not because it lacks capacity but because it is thrashing. Multitasking, interruptions, and switching between half-finished items can consume a startling share of a constrained step's output.
- Limit work in progress. Cap the number of items allowed at the constraint simultaneously. Counterintuitively this usually increases output, because each item finishes faster and switching cost falls.
- Protect it from interruption. If your constraint is a senior reviewer, their calendar is your throughput. Meetings scheduled into their review time are throughput removed.
- Never let it go idle for want of input. The constraint should always have the next item ready. Idle time at the constraint can never be recovered anywhere else in the system.
2. Take work off it
Ask what is arriving at the constraint that should not be. This is where most of the available gain sits.
- Filter earlier. Items that will be rejected should be rejected before they consume constraint capacity, not after.
- Split the work. Often only part of a task genuinely requires the constrained resource. A senior reviewer may need to make three judgement calls in a task that also contains ninety minutes of preparation anyone could do.
- Fix quality upstream. If a third of what reaches the constraint needs sending back, upstream quality is stealing a third of your throughput. This is nearly always cheaper to fix than adding capacity.
- Convert repeated judgement into a rule. Decisions the constraint makes the same way every time are candidates for an explicit rule that someone else can apply.
3. Add capacity
Only now. And when you do, size it against the throughput you actually need rather than against the current backlog, which is inflated by the queueing you are about to eliminate.
The number of constraints worth working on at a time. Parallel improvement programmes across several steps are the standard way that a real gain at the constraint gets buried in noise from changes that could not have helped.
The constraint moves, and you have to follow it
This is the step almost everyone skips, and skipping it is why a successful improvement often fails to produce a second one.
When you relieve a constraint, the workflow's maximum throughput rises until it hits the next-slowest step, which is now the constraint. Your map is out of date the moment the fix lands. If you continue optimising the old constraint — which is tempting, because you now understand it well and have momentum — you will spend real money buying capacity that sits idle.
So: re-run the queue walk four to six weeks after any material change. Expect the constraint to have moved, and expect it to move to somewhere less convenient. It commonly relocates from a doing step to a deciding step, because approvals were previously hidden behind slower work. Once the work speeds up, the approval queue becomes visible, and that is an ownership and decision-clock problem rather than a capacity problem.
When the constraint is outside the business
Sometimes the walk points at a client, a supplier or a regulator. This is a legitimate finding, not a dead end. The available moves are different but real:
- Make it trivially easy for the external party to respond — pre-filled forms, single questions, clear defaults
- Pipeline around the wait so it does not block unrelated work
- Set expectations internally against the real external cycle time rather than the optimistic one
The three measures worth tracking afterwards
Bottleneck work needs a small number of stable measures or it becomes a matter of opinion. Three are sufficient.
| Measure | Definition | What it tells you |
|---|---|---|
| Throughput | Completed items per week | Whether the system got faster. The only measure that matters to the business. |
| Cycle time | Elapsed time from start to done, per item | What a customer experiences. Watch the spread, not just the average. |
| Work in progress | Items started but not finished | Leading indicator. Rising WIP predicts rising cycle time before it happens. |
Two cautions. First, track the distribution of cycle time, not the mean. An average of six days that ranges from two to twenty-eight is a very different business from a consistent six, and customers experience the spread. Second, resist utilisation as a measure. High utilisation at non-constraint steps is not efficiency; it is usually work being generated to fill time, and it inflates work in progress, which makes everything slower.
What good looks like
Throughput up, cycle time down and tightening, work in progress lower than when you started. If throughput has not moved, you did not fix the constraint — you fixed something else, and the honest move is to say so and re-run the walk.
The Mayim Ops assessment scores workflow efficiency alongside nine other dimensions and identifies where work is accumulating, so the queue walk starts from a hypothesis rather than from scratch.
Five ways bottleneck work goes wrong
Recognisable failure patterns, all of which are recoverable if you catch them.
1. Optimising the noisiest step. The step that generates the most complaints is often downstream of the constraint, absorbing chaos created elsewhere. Fixing their tooling improves their experience and not the output.
2. Adding people to the constraint without changing the work. If the constraint is a senior person doing work that requires their judgement plus two hours of preparation, a second senior person doubles the cost to buy a fraction of the throughput that splitting the task would have delivered free.
3. Removing the queue instead of the constraint. Hiding the backlog — distributing it, re-labelling it, holding it upstream — makes the dashboard look better and changes nothing. The wait is still there, it is just less visible.
4. Treating a rework loop as a capacity problem. If items pass through the constraint twice, you have a quality problem upstream masquerading as a capacity shortfall. Buying capacity here doubles the cost of doing the work incorrectly.
5. Declaring victory without re-measuring. The fix felt good, the team feels faster, nobody checked throughput. Six weeks later the constraint has moved and the improvement is invisible in delivery. Measure before, measure after, and publish both numbers.
Frequently asked questions
How do you identify a bottleneck in a workflow?
Look for where work accumulates rather than who seems busiest. For one week, record daily how many items are waiting to start at each step and how long the oldest has waited. The constraint is the step where the queue is consistently largest and the oldest item keeps getting older, and the steps downstream of it are periodically idle.
What is the theory of constraints in simple terms?
It holds that any workflow has one step that limits the throughput of the whole system, and that improving any other step adds cost without adding output. The practical implication is to find that step, protect it from overload, remove work that should not reach it, and only then consider adding capacity.
Should I hire to fix a bottleneck?
Usually not first. Most constrained steps are carrying work that should have been filtered out earlier, split so that only part requires the constrained resource, or prevented by fixing quality upstream. Adding capacity is the most expensive option and often buys throughput you could have had for free.
Does limiting work in progress actually increase output?
Frequently yes, at constrained steps. Running many items simultaneously means each finishes later and a meaningful share of capacity is lost to context switching. Capping concurrent items typically shortens cycle time and reduces the rework caused by half-finished work sitting idle.
Why did our throughput not improve after we fixed the bottleneck?
Two likely explanations. Either the step you improved was not the real constraint, in which case the queue walk needs re-running, or you fixed the constraint and it has since moved to the next-slowest step, which is normal and expected. Re-measure four to six weeks after any material change.