Pour water out of a bottle and watch what limits you. It isn’t the wide glass body, which could empty in a blink. It’s the narrow neck. The water can only leave as fast as the slowest part of the path lets it — and you could blow the body of the bottle out to the size of a barrel without pouring a single drop faster. To speed things up, there’s exactly one thing worth touching: the neck.
That humble bottle is a complete model of how almost every system behaves, and the subject of this entire course. A factory, a hospital, a checkout line, a software deploy, a morning routine, a six-lane road that suddenly merges to two — each is a chain of steps, and in every one of them a single step is the neck. How much the whole system actually delivers is set by that one slowest step and, maddeningly, by nothing else. We have a name for it: the bottleneck.
What a bottleneck is
A bottleneck is the single step in a process whose limited capacity caps the output of the whole process. “Capacity” just means how much that step can handle per unit of time — cars per minute through the merge, parts per hour at the slowest machine, tickets per day from the one overloaded team. The bottleneck is whichever step has the least of it.
And here’s the rule that makes the concept worth a whole course — the one number to take away from this lesson:
Throughput — the rate at which a system actually produces finished output — equals the capacity of its bottleneck. Not the average of the steps. Not the sum. The minimum.
Every other step is faster than it needs to be. Their extra speed is invisible to the system’s output, because the work still has to squeeze through the neck before it can leave. A five-stage assembly line whose stages can do 50, 30, 45, 35, and 60 units an hour does not produce 50, or 60, or the average of 44. It produces 30 — the slowest stage — and the other four spend part of every hour idle or piling up work they can’t pass along.
The one-sentence version
A bottleneck is the slowest step in a chain, and a system’s real output (throughput) is set by that one step alone — so the whole game is finding it and pushing there, not everywhere.
See it move
You don’t have to take the rule on faith — here’s the machine itself. Each bar is one stage of an assembly line, and you can drag its capacity. The dashed line is the line’s actual throughput. Watch two things. First: throughput always sits exactly at the shortest bar — the bottleneck, in red. Second, and this is the whole course in one gesture: drag a taller bar up or down and the throughput line doesn’t budge — that capacity is wasted (the faded part of the bar). Only when you move the bottleneck does the line move — and the instant another stage becomes the slowest, the red badge jumps to it.
Find the bottleneck
One line, one constraint
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 30 units/hr — the capacity of “Weld”, the slowest stage. Every other stage is faster, so 70 units/hr of capacity sits idle. Speeding up anything but “Weld” changes nothing.
Spend twenty seconds dragging those sliders. Try to make the line run faster by raising the tallest bar — you can’t. Then raise the red one and feel the difference. Everything ahead is just learning to read what you’re already seeing.
Before you read — take a guess
An assembly line has five stages that can process 50, 30, 45, 35, and 60 units per hour. With raw material always available, how many finished units does the line actually produce per hour?
Why this breaks our instincts
Look again at how wrong the tempting answers feel. The average (44) feels fair — surely a line of mostly-fast stages is fast on average? But you can’t average your way past a wall; the work physically has to go through the 30-unit stage. The sum (220) is the instinct that “more total horsepower = more output,” which is how we think about a team’s combined effort — and it’s exactly backwards for a chain. And the fastest stage (60) is the part we’re proudest of, the shiny machine we want to credit — which contributes nothing to throughput at all.
This is what makes bottlenecks worth studying. Our untrained reflex, faced with a slow system, is to improve whatever is easiest, or to make every part a little better, or to upgrade the part we happen to understand best. In a chain, all three are mostly wasted motion. There is one step that matters, and improving any of the others — however satisfying, however visible — moves the system’s output by exactly zero.
The pitfall this whole course fights
The number-one mistake is local optimization — improving a step that isn’t the constraint and feeling productive while the system doesn’t speed up at all. Worse, speeding up a non-bottleneck can pile up work in front of the real one and leave the steps after it starved. Effort spent anywhere but the bottleneck is, for the system’s output, effort thrown away.
How this connects to what you already know
This isn’t a fresh start — it’s feedback loops and systems thinking pointed at a specific, ruthless question. Systems thinking taught you to stop staring at parts in isolation and look at how the whole behaves; the bottleneck is the sharpest possible version of that lesson, because it says the whole’s behavior is governed by one part you have to go find. When you reach the last course’s idea of a leverage point — the place where a small push changes everything — you’ll recognize the bottleneck as the most concrete leverage point there is. Push the constraint and the system transforms; push anywhere else and it absorbs your effort and shrugs.
There’s a loop here too. Relieve the bottleneck and a new slowest step appears — the constraint doesn’t vanish, it moves. That endless “fix one, reveal the next” cycle is a feedback structure you’ll learn to ride rather than fight.
The map of the course
Five teaching lessons, then one exam you can’t undo:
- The Bottleneck — the single slowest step, throughput as the minimum, and how to spot the constraint in any process (look for the pile-up in front of it and the idleness behind it).
- The Theory of Constraints — Goldratt’s five focusing steps: identify, exploit, subordinate, elevate, repeat — the actual procedure for governing a constraint.
- Don’t Polish the Wrong Stone — why improving a non-bottleneck does nothing (and can hurt), the local-optimization trap, and the inventory it piles up.
- Amdahl’s Law — the math of speeding up one part of a pipeline, why even an infinite speedup of a non-bottleneck has a hard ceiling, and how to do the arithmetic of “how much will this actually help?”
- The Constraint Always Moves — why fixing one bottleneck reveals the next, how to ride that cycle, and the everyday bottlenecks hiding in your traffic, your team, your queries, and your mornings.
Then a Final Exam — graded, one question at a time, one-way: once you answer, it locks. No back button, no retries.
How to use this course
One rule does most of the work: guess before you peek. Commit to an answer in your head before you reveal any explanation. Bottleneck problems are full of answers that feel right — average it, sum it, credit the fast part — and turn out backwards. The small sting of guessing wrong is what makes the real rule stick.
Next up: the bottleneck itself — what it is, how throughput collapses to its capacity, and the tell-tale signs that let you point at the constraint in a system you’ve never seen before.