Last lesson handed you a rule that sounds almost too neat to be useful: a system’s throughput — the rate at which it actually produces finished output — equals the capacity of its slowest step, the bottleneck. Not the average. Not the sum. The minimum. You watched the line in the slider obey it perfectly, throughput glued to the shortest bar no matter how you dragged the rest.
But the slider had the bottleneck labelled in red for you. The real world is rude enough to leave the label off. Nobody hands you a spec sheet that says “Stage 3 does 30 units an hour, and by the way that’s your constraint.” You walk into a struggling kitchen, a jammed highway, a support team drowning in tickets — and the slowest step is hiding in plain sight, looking exactly like every other step. Your job is to find it anyway.
The good news is that a bottleneck is almost physically incapable of hiding. It leaves two fingerprints everywhere it goes, and once you know what they look like, you’ll start seeing them in queues at the airport, in the one printer everyone fights over, in the deploy that takes all afternoon. This lesson is about reading those fingerprints — turning “throughput = the minimum” from a tidy formula into a skill you can use on a system you’ve never seen before.
Before you read — take a guess
You walk into an unfamiliar workshop. One workstation has a tall, growing pile of half-finished parts waiting in front of it, while the station right after it sits idle with nothing to do. Which station is most likely the bottleneck?
Throughput is the capacity of the constraint
Let’s make the headline rule airtight, because the rest of the lesson leans on it. Three words do all the work, so define them precisely:
- Capacity — the most a single step could process per unit of time if it never had to wait: parts per hour, patients per hour, tickets per day. It’s a step’s top speed, measured in isolation.
- Throughput — what the whole system actually finishes per unit of time. Not a step’s top speed — the system’s real, out-the-door delivery rate.
- Utilization — how busy a step actually is, as a fraction of its own capacity. A station that could do 60 an hour but only ever gets fed 30 is running at 50% utilization. It’s half-idle, and that idleness is a clue, not a flaw.
The rule, stated rigorously: throughput equals the capacity of the lowest-capacity step. Every step upstream of the constraint can only pass work along as fast as the constraint accepts it; every step downstream can only receive work as fast as the constraint releases it. So the constraint’s capacity is a hard ceiling on the entire flow — and the constraint itself runs at (near) 100% utilization while everything else runs below it.
Here’s a worked example. A hospital emergency department moves each patient through four steps. Their isolated capacities (patients per hour):
| Step | What happens | Capacity (patients/hr) | Utilization at full load |
|---|---|---|---|
| Triage | Nurse assesses severity | 18 | 50% |
| Doctor exam | Physician diagnoses | 9 | 100% |
| Labs / imaging | Bloodwork, X-ray | 14 | 64% |
| Discharge | Paperwork, instructions | 20 | 45% |
Throughput is 9 patients per hour — the doctor-exam step, the lowest number. Triage could handle 18, but it’s pointless to assess patients twice as fast as a doctor can see them; the extra speed just builds a waiting room. Notice the utilization column: the bottleneck runs flat-out at 100%, and every other step idles below it. That utilization gap is itself a map — the step pinned at 100% is your constraint, and the slack everywhere else is the throughput you’re leaving on the floor.
The one-sentence version
Throughput = the capacity of the lowest-capacity step. The constraint runs at 100% utilization; everything else has slack — and that slack is wasted speed, not free performance.
A quick gut-check on why average and sum keep failing. The ED’s average capacity is (18 + 9 + 14 + 20) / 4 = 15.25 — but you can’t average your way past the doctor; every patient physically has to be seen by one. The sum is 61 — the fantasy that combined horsepower equals output, which is exactly backwards for a chain where work has to pass through each step in turn. The minimum, 9, is the only number that survives contact with reality.
When to use it
Reach for this the instant you hear someone explain a slow system by pointing at its fastest part (“but our intake is so efficient!”) or its average (“on average we’re pretty quick”). Both are throughput-blind. The only number that predicts real output is the capacity of the single slowest step — so go find that step and ignore the rest of the brag sheet.
How to find the bottleneck without a spec sheet
Almost never will someone hand you the capacity table above. So how do you find the constraint by looking? Watch for its two unmistakable tells — they’re two sides of the same coin, because work that can’t get through the slow step has to go somewhere.
Tell #1 — Work piles up in front of the constraint. Material arrives at the bottleneck faster than it can be processed, so it accumulates: a growing queue, a swelling inventory, a packed waiting room, an inbox that never empties. Wherever you see a pile that keeps getting bigger, the slow step is right behind that pile.
Tell #2 — Everything downstream is starved. The steps after the bottleneck get fed only at the bottleneck’s pace, which is by definition slower than they can handle. So they sit idle, under-used, waiting for work that trickles in. Starvation is the constraint’s shadow, cast forward.
Put them together and you get a precise pointer: the constraint sits exactly between the pile-up and the starvation. Work stacks up just before it; idleness spreads just after it. A few examples to tune your eye:
- The kitchen with one fryer. Plates of half-cooked food back up on the line waiting for the single fryer, while the plating and expo stations stand around with nothing to garnish. Pile-up before the fryer, idle hands after it. The fryer is the constraint — not the chefs who look busy, not the servers who look slammed.
- The highway lane merge. Three lanes squeeze to two. Cars stack into a crawling queue before the merge — and the road past the merge is gloriously, suspiciously empty, moving at full speed. That empty road downstream is starvation; the queue upstream is the pile-up. The merge point is the bottleneck, even though it’s the empty stretch that feels like the “fast part.”
- The support team with one senior engineer. Easy tickets get cleared fast, but every hard one routes to the single senior engineer, and those tickets stack into a growing backlog with her name on them. Meanwhile the junior who’d close them out after her sign-off has a quiet queue. The senior engineer is the constraint; hiring three more juniors won’t touch the throughput.
Drag the pipeline below to watch both tells appear at once. It’s a coffee shop’s morning rush — order, then the single espresso machine, then milk-steam, then hand-off. Watch where the ▓ pile-up forms and where the ░ starvation spreads, and notice they always straddle the red bar.
Find the bottleneck
Morning rush: where the queue forms
Drag each stage’s capacity. The whole line can only run as fast as its slowest stage — the bottleneck (red). Speed up a faster stage and nothing happens; speed up the bottleneck and the line finally moves — until a different stage becomes the new slowest one.
The line runs at 22 drinks/hr — the capacity of “Espresso”, the slowest stage. Every other stage is faster, so 89 drinks/hr of capacity sits idle. Speeding up anything but “Espresso” changes nothing.
The pitfall: blaming the busy-looking step
The bottleneck often doesn’t look like the problem. The starved step downstream looks lazy (“why are they always idle?”), and the overwhelmed step upstream looks swamped (“we need more intake staff!”). Both are misreads. The idle step is starved by the constraint, and the swamped intake is just shovelling work into a pile the constraint can’t clear. Don’t reward the busy-looking step or scold the idle one — read the flow, find where the pile meets the starvation, and push there.
Now make the diagnosis yourself. Same four-stage line; sort each stage by what it’s doing.
A four-stage line runs at capacities 40, 15, 35, and 50 units/hr (in order). Sort each stage by its role in the flow.
Place each item in the right group.
- Stage 4 — 50 units/hr, last in line, also fed only 15/hr
- Stage 1 — 40 units/hr, feeds the slow step faster than it can accept
- Stage 2 — 15 units/hr, the slowest step, running flat-out
- Stage 3 — 35 units/hr, gets fed only 15/hr from upstream
When to use it
Use the two tells whenever you can’t measure capacities directly — which is most of the time. You don’t need a stopwatch on every step; you need to spot the one growing queue and the idleness just past it. In a warehouse, a codebase’s CI pipeline, a passport office, or your own to-do list, the question is the same: where does work pile up, and what sits waiting behind that pile? The answer points straight at the constraint.
A bottleneck only bites when demand exceeds it
Here’s a subtlety that trips up even careful people: a slow step is only a constraint if the system is actually being asked to produce more than it can. A bottleneck needs demand pressing against it to bite.
Define demand: how much output the system is being asked to deliver per unit of time — orders per hour, customers per hour, requests per day. The rule sharpens to this: a step constrains the system only when demand exceeds that step’s capacity. If the market only wants 20 units an hour and your slowest internal step can do 30, that “slow” step is sitting at 67% utilization with capacity to spare — it isn’t holding anything back. There’s no pile-up, no starvation, no queue. Nothing is constrained, because nothing is being pushed to its limit.
Worked example. A small bakery’s slowest step is the single oven, capacity 40 loaves per hour. Two scenarios:
| Demand (loaves/hr) | Oven capacity | Throughput | Is the oven the constraint? | |
|---|---|---|---|---|
| Quiet Tuesday | 25 | 40 | 25 | No — demand < capacity; oven has slack, no queue forms |
| Saturday rush | 70 | 40 | 40 | Yes — demand > capacity; dough piles up, the oven is pinned at 100% |
Same oven, same kitchen. On Tuesday it’s not a bottleneck — buying a second oven would be money lit on fire, because you’d be adding capacity nobody’s asking for. On Saturday the exact same oven is the bottleneck, dough backing up while it runs flat-out. The constraint isn’t a fixed property of the slow step; it’s a relationship between that step’s capacity and the demand pressing on it.
And here’s the twist that widens the whole model: sometimes the slowest thing in the picture is demand itself. If the bakery could bake 40 loaves an hour but the town only ever wants 25, then the binding constraint isn’t inside the bakery at all — it’s the market. This is an external constraint: the system has internal capacity to spare, and the thing capping its output sits outside the process (not enough customers, not enough raw material, not enough sales). When a business with idle machines says “we could make more, people just aren’t buying,” they’ve correctly located a market constraint — and no amount of factory-floor optimization will move it. You don’t fix a demand constraint by speeding up the oven; you fix it by finding more mouths.
Match each term to its precise definition.
Pick a term, then click its definition.
When to use it
Before you spend a dollar widening a “slow” step, check whether demand is even pressing on it. If the queue isn’t growing and downstream isn’t starved, you don’t have a binding internal constraint — and your real bottleneck might be external (the market, your suppliers, your pipeline of leads). Speeding up production when the constraint is demand just builds inventory nobody ordered.
The bottleneck governs the whole
Step back and the picture collapses to a single sentence: find the one slowest step that demand is pressing against, and you know the system’s throughput — it’s that step’s capacity, and nothing else’s. Every other number on the floor is a distraction. The fast steps’ speed is invisible to output. The average is a fiction. The sum is a fantasy. There is one governing number, and the whole skill of this lesson is locating it by sight.
That’s why the two tells are worth burning into memory. You rarely get the capacity table; you almost always get the flow, and the flow advertises the constraint loudly: a pile-up that keeps growing, with idleness spreading just behind it. Stand at the seam between them and you’re standing on the bottleneck. Everything this course does next — wringing more out of the constraint, refusing to waste effort elsewhere, doing the math on how much a fix will help — starts from this one act of pointing at the right step.
A car wash has four stations with capacities 30, 30, 12, and 25 cars per hour (in order: pre-soak, wash, dry, wax). On a busy day with cars lined up at the entrance, how many cars per hour leave clean and waxed, and where will the queue of waiting cars form?
An online store's order pipeline runs: receive order (200/hr) → pick items (60/hr) → pack (90/hr) → ship (150/hr). It's Black Friday and orders are flooding in well past 200/hr. Where will work pile up, and which steps will sit starved?
Fill in the bottleneck-spotting procedure.
Pick the right option for each blank, then check.
To find a constraint by sight, look for where work — the constraint sits right behind that growing queue — and for the steps that are downstream of it. The system's throughput equals the , but only when its capacity.
Recap
Big picture
Spotting the Constraint
- Spotting the Constraint
- The core rule
- Throughput = capacity of the LOWEST-capacity step
- Not the average, not the sum — the minimum
- Constraint runs at ~100% utilization; rest has slack
- Three precise terms
- Capacity = a step’s top speed in isolation
- Throughput = the system’s real out-the-door rate
- Utilization = how busy a step is vs. its own capacity
- The two tells (find it by sight)
- Pile-up: work backs up IN FRONT of the constraint
- Starvation: steps AFTER it sit idle, fed at its pace
- Constraint = the seam between pile-up and starvation
- Real-world fingerprints
- Kitchen: plates back up at the one fryer
- Highway: queue before the merge, empty road after
- Support: tickets stack on the one senior engineer
- Demand makes it bite
- A slow step constrains ONLY when demand > its capacity
- Below that: it has slack, no queue, not a bottleneck
- Constraint can be EXTERNAL (the market, suppliers)
- The pitfall
- Don’t blame the idle (starved) or swamped (upstream) step
- Read the flow, not how busy each step looks
- The core rule
Check yourself: spotting the constraint
What is the difference between a step's capacity and the system's throughput?
Check your answer to continue.
Where this goes next
You can now point at the constraint — by capacity if you’re lucky enough to have the numbers, and by sight (pile-up in front, starvation behind, demand pressing on it) when you’re not. That’s the diagnosis. The obvious next question is the one the whole field was built to answer: now that I’ve found it, what exactly do I do?
Lesson 3 gives you the procedure. It’s Eliyahu Goldratt’s Theory of Constraints and its famous five focusing steps — identify the constraint, exploit it (wring every drop out of it before spending a cent), subordinate everything else to serve it, elevate it (only now add capacity), and then repeat, because the moment you fix one bottleneck a new one appears. You’ve done step one in this lesson. Next, you’ll learn the other four — and why doing them in the wrong order is how smart teams waste years.