Theory of Constraints

TL;DR

Theory of Constraints: Every system's performance is limited by its single worst bottleneck. Find that constraint, exploit it fully, subordinate everything else to it, then elevate it (increase its capacity). Only then look for the next constraint. Optimizing any non-bottleneck is waste — only the bottleneck determines throughput.

What Is the Theory of Constraints?

Eli Goldratt introduced the Theory of Constraints in his 1984 novel The Goal, which told the story of a manufacturing plant manager using TOC principles to save a factory from being shut down. The core insight: in any system with multiple interdependent parts, the overall performance is limited by its weakest link — its constraint.

This sounds obvious, but its implications are counterintuitive and regularly violated:

Improving non-bottlenecks doesn't increase throughput. If your factory's bottleneck is a single machine that can process 100 units per day, improving every other machine to process 200 units per day accomplishes nothing — the bottleneck still limits throughput to 100. The improvement effort was wasted.

Local optimization is often global degradation. A worker who's efficient at a non-bottleneck step produces inventory that piles up before the bottleneck. The "efficiency" creates cost (inventory holding cost, space, complexity) without creating throughput.

The constraint is the only thing that matters for throughput. Every decision, resource allocation, and improvement effort should be evaluated by its impact on the constraint. An hour of time at the bottleneck is worth far more than an hour anywhere else.

Goldratt distilled his framework into the Five Focusing Steps:

Identify the system's constraint
Exploit the constraint (get maximum output from existing capacity)
Subordinate everything else to the constraint
Elevate the constraint (increase its capacity)
Repeat (don't let inertia become the next constraint)

How It Works

Five Focusing Steps:

Step 1: IDENTIFY
  Where is the bottleneck?
  Signs: work piling up before a step, starved inventory after it,
  long cycle times in one area, firefighting concentrated in one place.
  
  → Map the system. Find where WIP accumulates.

Step 2: EXPLOIT
  How do you get the most out of the constraint RIGHT NOW?
  No additional investment required — just eliminate waste at the bottleneck.
  • Is the bottleneck idle during breaks, setup, or maintenance?
  • Is it processing defects that will be reworked later?
  • Is it doing work that a non-bottleneck could do instead?
  → Every minute of constraint time is precious.

Step 3: SUBORDINATE
  Align everything else to the constraint's pace.
  Non-bottlenecks should run at exactly the speed that keeps
  the constraint fully fed — no faster, no slower.
  → Drum-Buffer-Rope scheduling in manufacturing.
  → Team capacity planning in software.

Step 4: ELEVATE
  Only now invest in increasing the constraint's capacity.
  Add equipment, hire people, redesign the process.
  → Now you've genuinely increased throughput.

Step 5: REPEAT
  Once the constraint is broken, a new one emerges.
  (If not, you've built a nearly unlimited system — rare.)
  → Don't let yesterday's solution become tomorrow's bottleneck.

Three Real-World Examples

The Goal (Manufacturing)

In Goldratt's novel, the plant manager discovers that his factory's constraint is one specific machine ("the NCX-10"). Improving any other machine produced nothing — work piled up before the NCX-10 regardless. The turnaround came from: (1) keeping the NCX-10 running 24/7 including through lunch breaks; (2) assigning dedicated staff to prepare all setups in advance so the machine never waited; (3) routing around the NCX-10 for any batch that could be done on another machine instead. These steps cost almost nothing and doubled throughput at the bottleneck — and therefore for the whole plant.

Software Engineering Bottlenecks (DevOps)

The DevOps movement is largely an application of TOC to software development. In many engineering organizations, the constraint is not writing code — it's the handoff to operations for deployment. Features are completed by developers but wait days or weeks to be deployed because the operations team is overwhelmed.

Improving developer velocity (adding engineers, improving development tools) without addressing the deployment constraint creates a larger backlog before the same bottleneck. The constraint is the bottleneck; everything else is noise.

The DevOps solution: identify the deployment constraint, then exploit (automate repetitive deployment steps), subordinate (developers take partial responsibility for deployment rather than throwing over the wall), and elevate (continuous deployment infrastructure). Throughput — deployed features — increases.

Personal Productivity

An executive discovers she's a bottleneck in her own organization: every significant decision requires her approval. Her team is capable but underutilized because they're waiting for her input.

The constraint is her attention and decision-making capacity. Exploiting it: eliminating all meetings that don't require her judgment (delegate attendance); batching similar decisions to reduce switching cost; reducing decision latency by providing standing decision frameworks. Subordinating: her team restructures their work to consume her time more efficiently, batching questions and pre-digesting options. Elevating: she trains two deputies to make a class of decisions autonomously. Throughput of organizational decisions increases significantly.

When to Use It

✅ Use TOC when:

Diagnosing why a system's throughput isn't improving despite improvement effort
Prioritizing improvement projects (work on the constraint first, always)
Designing workflow systems (manufacturing, software, services)
Allocating capacity in an organization
Understanding why your sales team is growing but revenue isn't (the constraint may be in delivery, not sales)

❌ Limit when:

The system doesn't have clear, measurable throughput
Multiple constraints are genuinely nearly equal in binding power (rare in practice)
The goal is to improve quality or capability rather than throughput of a defined output

Pairs well with	Why
Leverage Points	The constraint is the leverage point for throughput improvement
Feedback Loops	Understanding loops helps identify where constraints will shift after elevation
Diminishing Returns	Non-bottleneck improvements exhibit diminishing returns (go to zero) under TOC
Pareto Principle	The constraint often represents the 20% of effort that drives 80% of throughput

Common Misuses

Optimizing non-constraints. The most common violation. Organizations invest in improving the steps that aren't the bottleneck — making local metrics look better without changing system throughput. If you haven't identified the constraint first, your improvement effort is likely wasted.

Breaking one constraint and forgetting to find the next. The Five Focusing Steps are explicitly iterative. When you elevate a constraint, a new one emerges. Organizations that declare victory and stop looking miss the next constraint — which often emerges inside the solution to the last one.

Confusing the constraint with any resource that's busy. A resource that's 100% utilized is not necessarily the constraint. The constraint is specifically the resource that limits throughput of the whole system. Identify it by mapping where work piles up, not by finding what's busy.

Leverage Points — the constraint is the throughput leverage point
Pareto Principle — constraint identification is a form of 80/20 analysis
Stocks and Flows — work-in-progress inventory buildup reveals constraints visually

FAQ

How do you identify the constraint in a complex system?

Three signals: (1) Where does work pile up? Inventory (physical or digital) accumulates before the constraint. (2) Where are people waiting? Teams downstream of the constraint are idle, teams upstream are overwhelmed. (3) Where does firefighting concentrate? The constraint is the source of most urgent escalations because it defines whether commitments can be met. Map your workflow and look for accumulation.

What's Drum-Buffer-Rope scheduling?

Goldratt's production scheduling method based on TOC. The Drum is the constraint's pace — the heartbeat of the factory. The Buffer is inventory kept in front of the constraint to ensure it's never starved. The Rope is the release mechanism that controls when upstream work is started — releasing work only fast enough to keep the buffer filled, preventing excess WIP from accumulating throughout the system. The result: the whole system runs at the constraint's pace rather than at maximum local efficiency.

Is TOC the same as Lean manufacturing?

Related but distinct. Lean focuses on eliminating waste throughout the system (all waste, everywhere). TOC focuses specifically on the constraint and argues that reducing waste at non-constraints doesn't improve throughput. In practice, they complement each other: TOC identifies where to focus, Lean provides the tools for improvement. Many organizations use both.

Apply with AI

🚀 Find and address your system's constraint with MindMax →

What Is the Theory of Constraints?​

How It Works​

Three Real-World Examples​

The Goal (Manufacturing)​

Software Engineering Bottlenecks (DevOps)​

Personal Productivity​

When to Use It​

Common Misuses​

Related Models​

FAQ​

Apply with AI​

Further Reading​