Theory of Constraints

A system's throughput is set by its bottleneck; improving anything else is an illusion.

Throughput is set by the narrowest stage, so improving any other stage only grows the queue in front of it.

To an executive

Investing outside the bottleneck does not increase output, it just builds up unfinished work. Finding the real constraint shows where money and effort actually pay off.

To an engineer

Find the constraint, get the most from it, make other steps work at its pace, then add capacity. Re-check afterwards, because the bottleneck will move.

The idea

Eliyahu Goldratt introduced the Theory of Constraints through The Goal, a business novel about a struggling factory written with Jeff Cox. Its central claim is that every system has at least one constraint that limits its output. Improving anything other than the constraint does not raise throughput; it just piles up more work in front of the constraint.

Goldratt's five focusing steps give a method:

Identify the constraint.
Exploit it: get the most out of it as it is.
Subordinate everything else to it, so other steps work at its pace.
Elevate it: add capacity, if it is still the constraint.
Repeat, and do not let inertia become the constraint, because the bottleneck will move.

Why it works

Throughput is set by the slowest step. A chain moves only as fast as its narrowest link, so effort elsewhere is wasted.

Queues show you where to look. Work piles up in front of the constraint. Following the queues is usually faster than modelling the whole system.

Cheap fixes come first. Exploiting and subordinating often lift throughput without new spending, so elevating is a last step, not a first.

Where it applies

Runtime systems, where a database lock, a single writer or a rate-limited dependency caps throughput.
Delivery pipelines, where a manual test step, a shared environment or an approval board limits flow.
Organisations, where a single expert or a central team becomes the constraint for many others.
Scaling decisions, before adding servers or people to the wrong place.

How to apply

Find the queue. Look for where work waits longest, whether requests, tickets or pull requests.
Protect the constraint's time. Remove work it should not be doing, and make sure it is never idle waiting for input.
Pace everything else to it. Stop pushing more work into the system than the constraint can take.
Add capacity only then. Automate, parallelise or staff the constraint, then look for where the bottleneck has moved.

Example scenario

A company doubled developer headcount to ship faster. Lead time did not change. Every release still waited on a manual security review done by two people, and the queue in front of them simply grew. Faster coding had only produced more work waiting.

The architects mapped where changes waited and found the review held most of the lead time. They moved routine checks into automated pipeline scans, so the reviewers handled only high-risk changes, and limited how many releases could enter review at once. Lead time fell substantially without further hiring, and the next constraint turned out to be a shared test environment.

Questions to ask

Where does work queue up and wait, in the system or in the delivery process?
If we made this step twice as fast, would overall throughput actually rise?
Once this bottleneck is fixed, where will the next one appear?

When not to use it

Systems with no stable bottleneck, where demand is so variable that the constraint moves constantly; capacity buffers and flow control matter more.
Problems that are not about throughput, such as correctness or security, where speeding up flow is beside the point.

How it misleads you

Assuming the constraint is technical. It is often a process, a policy or a person. The opposite trap is fixing one bottleneck and declaring victory: the constraint always moves somewhere, and the five steps are a loop, not a project.