Eli Goldratt's Theory of Constraints (TOC) is one of those ideas that sounds obvious once you've heard it and changes how you think about operations forever. The core claim: every system has exactly one bottleneck at any given moment, and any improvement anywhere other than that bottleneck is decoration.
Most process-improvement programmes ignore this. They try to make many things 10% better simultaneously and end up with a process whose throughput hasn't moved because the constraint is still the constraint. Here's a practical guide to finding yours and actually relieving it.
What a bottleneck really is
A bottleneck is the step in your process with the lowest sustainable capacity relative to demand. Three properties distinguish a real bottleneck from a slow step:
- It has a queue. Work piles up in front of it. Look for inboxes that grow, tickets that age, files waiting for review.
- It starves the steps downstream. Whoever works after the bottleneck is occasionally idle, or chasing other things to look busy.
- The whole system's throughput is its throughput.If the bottleneck doubles its output, the system doubles its output. If anything else doubles, nothing changes.
That third property is the diagnostic test. If you can't confidently say “doubling X would double throughput,” X isn't the bottleneck.
Where bottlenecks actually live
In knowledge work, bottlenecks reliably cluster in four places:
Approval steps
A step where work waits for a specific named human to read it. The review itself is fast (5 minutes); the wait for the review is long (3 days). The metric to look at is queue time, notreview time.
Specialist steps
Only one person can do this part. When they're on leave or deep in something else, the queue grows. Examples: the one person who knows the contract template, the only engineer who understands the legacy billing logic, the designer who handles all client-facing slides.
Handoffs between systems
When data has to move from system A to system B with a human in between, you almost always find a queue. The human becomes the bottleneck for an entire workflow that's otherwise automated on both sides.
External dependencies
Work blocked on a customer reply, a vendor approval, or a partner team. These are real bottlenecks even though they live outside your control — which means you have to manage them differently.
Finding yours: the queue audit
Run this exercise on a Friday afternoon when the working week is quiet enough to see clearly. Take any process and answer:
- List the stepsin order. Aim for 8–12 steps; fewer means you're missing detail, more means you're drowning in it.
- For each step, write the count of items currently waiting to start that step. (Not in progress — waiting.) Use real numbers from real queues; estimate where you have to.
- The step with the largest waiting queue is your bottleneck candidate.Verify by asking the people downstream: “are you ever waiting on this?” If yes, you've found it.
Some teams resist this because the answer is often politically awkward (“the bottleneck is legal review,” “the bottleneck is the CFO's approval”). That political awkwardness is precisely why bottlenecks persist. The whole programme starts by being willing to name the constraint accurately.
Goldratt's five focusing steps, simplified
The TOC method has five steps. The original is worth reading; the compressed version that's useful in a meeting is:
Step 1: Identify the constraint
The queue audit above does this.
Step 2: Exploit the constraint
Before adding capacity, make the existing bottleneck work harder. Most bottlenecks aren't running at full speed because they get interrupted, do work that doesn't need to be there, or wait on inputs that arrive incomplete. Examples:
- Stop interrupting the bottleneck with low-priority work. Triage before the queue.
- Pre-process inputs so the bottleneck doesn't have to chase information.
- Eliminate the parts of the bottleneck's work that aren't actually adding value — quality checks that should be earlier in the process, formatting that could be templated.
Step 3: Subordinate everything else to the constraint
Don't let upstream steps run ahead of the bottleneck. Doing so just builds inventory in front of it, which feels like progress but isn't. Match upstream throughput to the constraint, even if that means upstream people are occasionally idle. (This is the counter-intuitive step that teams resist hardest. Lean principles have the same idea — local efficiency does not equal system throughput.)
Step 4: Elevate the constraint
Now (and only now) add capacity. Hire another reviewer, automate the manual handoff, add tooling to the specialist. The investment pays back because the system was constraint-limited and now the constraint has more capacity.
Step 5: Repeat
Once the constraint moves (and it will — somewhere else becomes the new bottleneck), start again. Theory of Constraints is not a one-time programme; it's a way of running operations continuously.
A worked example
A 30-person services firm we worked with had a quote-to-cash cycle of 19 days. The team was sure the slowness was “sales taking forever to send contracts.” Queue audit:
- Initial proposal drafting: 2 days waiting
- Sales review: 1 day waiting
- Legal review: 7 days waiting ← bottleneck
- Counter-signature: 1 day waiting
- Onboarding kickoff: 2 days waiting
Step 2 (exploit) reduced legal review wait from 7 days to 3 by introducing a standard contract template that covered 80% of deals without changes. Sales were trained to flag when a deal genuinely needed bespoke terms, and only those went through full legal. Quote-to-cash dropped from 19 days to 11 — without hiring a single new lawyer.
Step 4 (elevate) came later: hiring a part-time contract operations associate to handle the standard-template cases. The cycle dropped to 7 days. Total spend on the change: about half what they had been quoted by a consultant who proposed “sales process re-engineering.”
The trap to avoid
Most process-improvement programmes fail because they don't commit to step 3 — subordinating everything to the constraint. It feels wasteful to have upstream people work at a slower pace. It's not. They're not producing throughput; they're producing inventory that sits in front of the bottleneck. Slower-but-aligned beats faster-but-piling-up every time.
Spend a week finding your bottleneck. Spend a month exploiting it. Only then start thinking about new tools, headcount, or reorganisation. The order matters more than any individual improvement.