Theory of Constraints

What it is

Goldratt published The Goal (North River Press, 1984) as a business novel — a protagonist manager saves a failing factory by applying a small set of principles drawn from the author’s optimization research. The novel was how ToC reached a wide audience; Goldratt later formalized the ideas across subsequent books including What Is This Thing Called Theory of Constraints? (1990) and Critical Chain (1997). The framework has since been adapted far beyond manufacturing — project management, software delivery, healthcare, distribution, even policy.

The core claim is short: every system has exactly one constraint at any given time. The constraint — also called the bottleneck — is the step that determines the overall throughput of the system. If you can process 100 units upstream and 100 downstream but the middle step handles only 30 units, the system produces 30 units. Throwing more capacity upstream produces a larger pile in front of the middle step; throwing more capacity downstream produces a larger pile of idle capacity after it. Neither increases throughput.

Goldratt’s focusing five steps are the operational form:

1. Identify the constraint. Which step determines throughput?
2. Exploit the constraint. Get the most out of it without adding resources — eliminate waste at the bottleneck specifically.
3. Subordinate everything else. Upstream and downstream steps match the constraint’s pace. Running them harder just makes piles.
4. Elevate the constraint. If exploitation isn’t enough, now add resources — more people, more capacity, a structural change.
5. Repeat — once the old constraint is no longer the bottleneck, a new one will emerge. Find it and start over.

For software delivery, the constraint is often non-obvious. Teams assume the bottleneck is coding (because coding is visible), when it’s actually code review (invisible queue time), or release windows (batched throughput), or environment provisioning (capacity limit). ToC is the discipline of finding the actual constraint before prescribing a fix.

When to use it

Reach for the Theory of Constraints lens when:

• A team is investing improvement effort in the wrong place — automating tests that take an hour when the release window holds work for three days; adding engineers to a team whose bottleneck is code review. The ToC lens is the corrective.
• You’ve just produced a value stream map and need to decide where to target the first improvement. The step with the longest wait or the lowest first-pass yield — given its position in the flow — is the constraint candidate.
• The team is considering multiple automation targets and the facilitator wants to prevent the “automate everything that’s easy” failure mode. Only the bottleneck’s local automation improves system throughput.
• A project keeps slipping its deadline and adding more people doesn’t help. The bottleneck is almost never the number of people; it’s usually a single step that can’t be parallelized.
• The team is optimizing one part of the system at the expense of others. ToC explains why local optimization can actually hurt global throughput (by increasing WIP at the constraint, for example).

Don’t reach for the Theory of Constraints lens when:

• The problem isn’t throughput-related. ToC is a flow-and-capacity framework. For problems of quality, fit, or customer value, different tools apply.
• The constraint is external and you don’t control it. A team blocked on a third-party vendor with a hard SLA can’t elevate the constraint by adding team capacity. The conversation is procurement or contract, not ToC.
• The system has meaningfully different modes. A team whose constraint is “release approval” during normal operation but “incident response” during outages has two systems. Analyze each mode separately.
• The team is culturally opposed to naming a bottleneck. ToC requires someone to say “this step is the constraint” out loud. If the step’s owner takes that as blame, the exercise will stall. Establish that the constraint is a property of the system, not the person, before starting.

How to run it

Total time: 30–45 minutes, usually embedded inside a larger exercise like value stream mapping or an automation workshop. Not typically a standalone session.

Identify the constraint (10–15 min). Walk the flow end-to-end and look for:

• The longest wait time in the pipeline. If work piles up somewhere, that’s a strong candidate.
• The step with the lowest first-pass yield. A step that rejects and sends work back is effectively slower than its raw process time suggests.
• The step whose owner has the highest WIP. Individual capacity often maps to system capacity.
• The answer to “where do things always pile up?” Ask the team directly — the team almost always knows where the pile is, even if they’ve never said it out loud.

If two steps are competitive candidates, don’t compromise — pick one. ToC requires commitment. The wrong pick will become obvious in execution and you can iterate.

Exploit the constraint (10 min). Brainstorm what the constraint’s owner could do to get more out of the step without adding resources. This is usually where the biggest gains live and teams most often skip it.

• Can the constraint’s inputs be better prepared so less time is spent on rework?
• Can quality checks be pushed upstream so the constraint sees fewer rejects?
• Can non-constraint work be moved off the constraint’s plate?
• Can the constraint’s process itself be simplified?

Example: if the constraint is code review, exploiting it means pre-reviewing designs before code, requiring CI-green PRs before human review, templating common reviews, tightening PR scope. None of these adds reviewer capacity; they make existing reviewer capacity go further.

Subordinate everything else (10 min). Agree that upstream and downstream steps will match the constraint’s pace — not run harder. This is counterintuitive for teams that equate “busy” with “productive.” The discipline is that upstream work ahead of the constraint just makes a pile; downstream capacity idle behind the constraint is not a problem.

• Stop overfeeding the constraint with WIP.
• Stop idle downstream steps from trying to “look busy” by reaching backward for work.
• Establish flow-matched pacing (explicit WIP limits, pull-based work intake) that keeps the constraint fed at its own rate.

Elevate, if necessary (5 min). Only if exploitation and subordination aren’t enough: now add resources. New team members, new tools, structural change to the step itself.

• Elevation is expensive. Most teams skip exploitation and jump straight to elevation, then wonder why the new capacity didn’t help.
• If elevation happens, it often changes which step is the constraint (step 5 — repeat).

Repeat (ongoing). The constraint moves. A successful ToC intervention ends with a new constraint, often at a step that was previously comfortable. Plan for the iteration.

Worked example

A team’s value stream map shows the following waits:

The code review step looks bad — 18 hours of wait. The release window looks worse — 72 hours. But which is the constraint?

Identify. The release window sets the system’s maximum throughput: no story gets to customers more often than weekly. Even if code review took zero time, the work would sit for up to seven days waiting for the window. The release window is the constraint.

Exploit. Before adding release resources, what can the team do to get more out of the window they have? Batch-related changes together to reduce the cost of each release; cut the post-release verification from four hours to one by automating the checklist; pre-check release-readiness Thursday evening so Friday’s window opens with zero queue. These are exploitation moves — no new capacity, just better use of the capacity that exists.

Subordinate. Upstream steps should not try to produce work faster than the release window can consume. An aggressive PR merge pace that creates a 30-story backlog at the release window is counterproductive — the work ages, conflicts accumulate, the window isn’t big enough to process it. Match the upstream merge rate to the release window’s throughput.

This is the counterintuitive part. The team’s instinct is “ship faster everywhere.” ToC says: slow down upstream to match the bottleneck, then attack the bottleneck.

Elevate. Exploitation and subordination have limits. Eventually the team moves to on-demand deploys — release orchestration, canary deploys, feature flags, the apparatus of continuous delivery. This is elevation: new structural capacity at the constraint. Weekly becomes daily becomes on-demand.

Repeat. Once the release window is no longer a 72-hour wait, the constraint moves. The 18-hour code review wait, previously masked, now dominates. The team runs the five steps on code review next — exploit with better PR discipline, subordinate with matched merge rates, and eventually elevate with async review tooling or more reviewer bandwidth.

Without ToC discipline, a team with this flow often invests in automating the already-fast CI step, or the already-brief deploy step — satisfying work that doesn’t change the lead time number. The ToC lens keeps the investment targeted at the step where improvement actually compounds.

Common failure modes

• Automating or improving the non-constraint. The team proudly shortens the CI run from 20 minutes to 5. Lead time doesn’t change — the release window was already the bottleneck. Satisfying work, zero impact. Fix: apply the five focusing steps before picking improvement targets.
• Elevating before exploiting. Adding reviewer capacity when the existing reviewers are spending half their time on easily-prevented rework. The cheaper, faster exploitation moves were skipped. Fix: exhaust exploitation before considering elevation.
• Pretending the constraint doesn’t exist. Teams that can’t name their bottleneck out loud — usually because of political sensitivity — can’t apply ToC. Fix: establish the “constraint is a property of the system, not a person” framing up front. The release-window bottleneck isn’t the release manager’s fault; it’s a policy choice.
• Moving to elevation because exploitation is uncomfortable. Exploitation often requires stopping counterproductive behaviors (aggressive upstream merging, over-staffing non-constraint steps) — politically harder than buying new tools. Fix: surface the counterproductive behavior explicitly and treat subordination as the real work.
• Treating the constraint as permanent. The team identifies the constraint, attacks it, wins — and then stops. The constraint moved, and the new constraint is now the thing to attack. Fix: after every successful ToC intervention, re-run step 1.
• Over-applying to quality or fit problems. ToC is about flow capacity. Problems of “we built the wrong thing” or “the code is buggy” aren’t ToC problems; they need different tools. Fix: if the issue isn’t throughput, use the right framework — user research, 5 Whys, fishbone — rather than forcing ToC onto a shaped-differently problem.

References

In the playbook

• Value stream mapping — the mapping technique that surfaces the constraint in visual form.
• Automation workshop — applies the ToC lens to prioritize automation candidates at the bottleneck.
• 2.8 Delivery processes & tools — the pipeline-capabilities chapter where constraint thinking informs tooling choices.

External references

• Eliyahu M. Goldratt and Jeff Cox, The Goal: A Process of Ongoing Improvement (North River Press, 1984, 4th ed. 2014) — the business novel that established ToC. Still the best introduction.
• Eliyahu M. Goldratt, What Is This Thing Called Theory of Constraints and How Should It Be Implemented? (North River Press, 1990) — the formal treatment.
• Eliyahu M. Goldratt, Critical Chain (North River Press, 1997) — ToC applied to project management.
• Donald G. Reinertsen, The Principles of Product Development Flow (Celeritas, 2009) — modern product-development extension; especially useful for understanding why upstream overwork harms constrained systems.
• Theory of Constraints Institute — the organization Goldratt founded; useful for modern practitioner resources.
• Gene Kim, Kevin Behr and George Spafford, The Phoenix Project (IT Revolution Press, 2013) — The Goal retold for software delivery. The best bridge for engineers new to ToC.