You are almost certainly working hard on something that cannot help you.
Not because you picked badly. Because every system — a business, a team, a training block, a job search — has exactly one stage that sets the pace of the whole thing, and improving any other stage produces nothing. You can double the speed of a step that was never the problem and the output will not move by one unit. It will feel like effort. It will look like progress on a dashboard. It will change nothing that matters.
This is the least intuitive rule in operations, and it is close to a law. The constraint governs. Everything else is decoration. The job is not to work harder across the board; it is to find the one place where work converts into output, and put your attention there until it stops being the constraint. Then find the new one.
Here is how to do that in about thirty minutes, with nothing but a piece of paper.
Step 1: Draw the line (10 minutes, once)
Pick one outcome you actually care about. Not a goal — a countable unit that arrives repeatedly. “Signed clients.” “Shipped features.” “Published articles.” “Completed hard training sessions.” “Job interviews.”
Now write the actual stages a single unit passes through, in order, from the moment it enters your world to the moment it counts. Actual, not idealised. If work sits in a folder for four days between two stages, that is a stage.
A freelance designer’s line might be: lead arrives → I reply → discovery call → I write proposal → they decide → deposit clears → I do the work → I invoice. Eight stages. Most people have between five and nine. If you have fifteen, you are describing tasks, not stages — group them.
Write the line horizontally with arrows. Leave space under each stage.
Step 2: Find the pile (10 minutes)
Under each stage, write two numbers:
- Queue: how many units are sitting there right now, waiting to be worked on.
- Wait: how long the average unit sits before that stage starts.
The constraint is the stage with the pile in front of it. That is the entire diagnostic. Work accumulates immediately upstream of the bottleneck and starves immediately downstream of it, exactly the way traffic stacks up before a lane closure and runs free after it.
Our designer counts: 11 leads unanswered, 0 discovery calls waiting, 6 proposals half-written, 1 project in progress, 3 invoices unsent. Two piles — leads and proposals. When there are two, the constraint is the later one, because clearing the earlier pile only makes the later pile bigger. Proposals is the constraint. Every hour spent on lead generation makes this business measurably worse.
If nothing is piled up anywhere, your constraint is upstream of the line entirely: you do not have enough demand, and the whole exercise becomes a marketing problem. That is a useful answer too.
Step 3: Prove it with the two-week test
Piles can lie. A stage can look backed up because you had one bad week. So before you rebuild anything, run the cheapest possible confirmation.
Pick the suspected constraint. For two weeks, add capacity to it and only to it — a few extra hours, a template, a temporary helper, whatever is easiest to reverse. Change nothing else. Deliberately do not improve any other stage, even where you can see easy wins. That restraint is the test.
Then check the outcome number, not the stage number. If throughput at the end of the line rose, you found it. If the stage got faster but total output did not move, you were wrong and the real constraint is elsewhere — look one stage further downstream, which is the most common location of a missed bottleneck.
Two weeks is the right length because it is long enough to clear noise and short enough that being wrong costs you almost nothing.
Step 4: Exploit before you expand
Everyone’s instinct at this point is to add capacity: hire someone, buy a tool, work Saturdays. Do that last. In order:
1. Protect it. The constraint should never be idle and should never do work that isn’t the constraint. If proposals are the bottleneck, proposal time is the first thing on the calendar and the last thing to be moved, and the person writing proposals does not also chase invoices. An hour lost at the constraint is an hour lost from the whole system. An hour lost anywhere else is free.
2. Offload everything that isn’t the hard part. Most constrained stages are 20% irreplaceable judgement and 80% assembly. Split them. Our designer’s proposal is a scoping decision (irreplaceable) wrapped in formatting, case studies, pricing tables and terms (all reusable). Build the wrapper once. The constraint now only does the judgement.
3. Subordinate the rest of the line. Slow the upstream stages down to the constraint’s pace on purpose. This feels insane and it is correct. Our designer answers leads twice a week instead of daily, because a lead answered instantly and then left waiting nine days for a proposal converts worse than one answered in three days and proposed in four. Speed at a non-constraint doesn’t create output. It creates queue — and queue creates the impression of overload, which is what makes people quit systems that were actually fine.
4. Only now, add capacity. If protecting, offloading and subordinating have all been done and the pile is still growing, you have earned the right to spend money. And you now know exactly what to spend it on, which is the part most people get wrong when they hire.
Step 5: Re-map, because it moves
Fix a constraint properly and it stops being the constraint. The bottleneck relocates — usually to the stage directly after it, which was never tested at this volume before. This is the step almost everyone skips, and skipping it is how organisations end up with a superb sales team and a delivery function on fire.
Put a 15-minute recurring block in the calendar — monthly is plenty — called re-map. Redraw the line, recount the piles, and ask one question: is the pile still in the same place? If it moved, your priorities moved with it, today, whatever the quarterly plan says.
Worked: the same method on four different jobs
The consultant with too much pipeline. Line: lead → call → proposal → close → deliver → invoice. Pile at deliver. Constraint is delivery, so every new lead is actively harmful. Correct move: stop selling for six weeks, productise the delivery, raise prices to shrink demand to capacity. Revenue goes up while lead generation goes to zero.
The engineering team that ships slowly. Line: spec → build → review → QA → deploy. Pile at review — 14 open pull requests, average wait 3.2 days. Nobody’s coding speed is the issue. Correct move: protect two review windows a day, cap work-in-progress so nobody starts a fifth thing while four sit unreviewed, and make review the highest-status task on the team rather than the chore you do when you’re tired.
The person trying to get fit. Line: intent → scheduled → completed → recovered → adapted. Pile at recovered — sessions get done, but each one is performed tired, so nothing adapts. Adding training volume makes it strictly worse. Correct move: the constraint is sleep and food, and training goes down until recovery clears. See the minimum effective dose for what that looks like in practice.
The job seeker sending 200 applications. Line: role found → applied → screen → interview → offer. No pile anywhere, because nothing is coming back. Zero queue at every stage means the line isn’t the problem — the input is. Correct move: stop applying, fix the thing that converts application into screen, and accept that going from 200 applications to 20 is an improvement.
The scripts
Most of the difficulty is social, not analytical. Three sentences that do most of the work:
Declining upstream work: “Happy to take this on — the honest answer is it would sit in the queue until the 20th, because that’s where the backlog is. Would you rather I start it then, or should we find another route?”
Protecting the constraint from meetings: “That block is the only thing that moves our output number, so I can’t give it up. I’ve got three other windows this week — any of them work?”
Explaining why you slowed a stage down: “We’re not doing less work. We’re releasing it at the pace the next stage can absorb, so it stops piling up and going stale. The end number goes up, not down.”
Six ways this goes wrong
- Measuring stage speed instead of system output. A stage getting faster is not a result. The only number that counts is units out the end. Track exactly one.
- Fixing the loudest stage. The stage that complains most is usually the one starved by the real bottleneck, not the bottleneck itself. Starvation is noisy; overload is quiet and behind.
- Calling yourself the constraint. “I’m the bottleneck” is not a diagnosis, it’s an apology. Which stage? Which piece of that stage? Answer at that resolution or you will just work later.
- Refusing to slow anything down. Subordination is the step people skip because it feels like giving up ground. It is the step that produces most of the gain.
- Hiring at the wrong stage. Adding a person upstream of the constraint increases the pile and the payroll and nothing else. This is the single most expensive version of this mistake.
- Mapping once. A constraint map from six months ago describes a system that no longer exists. If you are not re-mapping, you are optimising history.
Do it this week
Thirty minutes, in one sitting: draw the line for one outcome (10), count queue and wait under every stage (10), circle the pile and name the constraint out loud (2), then write down the three things you will stop doing because they are upstream of it (8).
That last item is the whole point, and it is the part that will feel wrong. You are going to deliberately underinvest in things you are good at, that are visibly productive, and that people will thank you for. Do it anyway. The constraint governs, and everything else is decoration — including, especially, the decoration you are proud of.
Related reading: the say-no playbook for protecting the block once you’ve found it, and the proof-metric playbook for choosing the one output number this whole method depends on.