← Reference · Nestor G Pestelos Jr · Print this page
Systems Theory · Operations Research
Theory of Constraints
Reference entry · last updated August 26, 2026
The Theory of Constraints (TOC) is a management and systems engineering methodology asserting that any manageable system is limited in achieving higher throughput by a very small number of constraints, typically exactly one active bottleneck at any given time.[1] Formulated by physicist Eliyahu M. Goldratt in 1984, TOC establishes that system optimizations made anywhere other than the active constraint generate excess work-in-progress inventory without increasing finished system output.[2]
Core axioms and accounting definitions
Goldratt measures a plant against three quantities, not against local efficiency:[1]
- Throughput (\(T\)): the rate at which the system generates money through sales. Product made and not sold is not throughput.
- Inventory (\(I\)): money invested in things the system intends to sell. Work-in-process counts as inventory.
- Operating expense (\(OE\)): money spent to turn inventory into throughput.
A local gain that does not raise \(T\), or that raises \(I\) or \(OE\) without a matching rise in \(T\), does not improve the system. Applying those labels to pull requests or unmerged branches is an analogy. It is not a definition from The Goal.
The Five Focusing Steps
TOC outlines a systematic cyclical method to continually expand system capacity:[2]
- Identify the constraint: Locate the specific stage or resource with the lowest capacity that paces the entire system.
- Exploit the constraint: Ensure the constraint operates at 100% efficiency without idle time, waste, or performing low-value tasks.
- Subordinate everything else: Align the operating pace of all non-constraint stages to the capacity of the constraint. Producing faster than the bottleneck creates harmful inventory build-up.
- Elevate the constraint: Invest capital, tooling, or personnel to expand the physical capacity of the bottleneck stage.
- Repeat: after the constraint is broken, a different one limits the system. Return to Identify. Goldratt warns against inertia: do not keep running the old policy after the constraint has moved.[2]
Drum-Buffer-Rope synchronization
To control flow and prevent queue explosion, TOC implements the Drum-Buffer-Rope (DBR) architecture:[3]
- The Drum: The constraint stage sets the production beat (tempo) for the entire organization.
- The Buffer: A bounded queue of work maintained immediately upstream of the constraint to prevent it from ever starving due to upstream volatility.
- The Rope: A signaling mechanism that limits the release of new work into the start of the pipeline strictly to the rate at which the constraint finishes work.[3]
Thinking Processes
Goldratt later added a set of cause-and-effect diagrams called the Thinking Processes. They answer three questions: what to change, what to change to, and how to cause the change.[5]
- Current Reality Tree: traces undesirable effects back to a few root causes.
- Evaporating Cloud: states a conflict and looks for an injection that dissolves it.
- Future Reality Tree: checks that the injection produces the wanted effects without new ones that are worse.
- Strategy and Tactics Tree: turns the future state into sequenced actions. Later presentations use this in place of the older Prerequisite Tree.
This page did not re-read Goldratt's 1990 monograph cover to cover. The three questions and the tree names follow a secondary manufacturing summary that matches the published TOC toolkit.
Bottleneck migration in software engineering and AI
If authoring gets faster and review or test capacity does not, finished delivery stays paced by review. Extra generated code then sits as work-in-process: open pull requests, longer queues, more defects reaching production. Faros AI's 2026 engineering telemetry study reports that pattern as "acceleration whiplash."[4] The TOC claim is the same as on a plant floor: raise the constraint, or extra upstream speed only raises inventory.
See also
- Throughput
- Amdahl's Law
- Acceleration whiplash
- Plan-Approve-Execute
- Triage the system, not your toolbox (essay: identifying the constraint vs acting on it)
References
- ↑ Eliyahu M. Goldratt and Jeff Cox, The Goal: A Process of Ongoing Improvement, North River Press, 1984.
- ↑ Eliyahu M. Goldratt, What is this Thing Called Theory of Constraints and How Should It Be Implemented?, North River Press, 1990. Publisher page: https://www.toc-goldratt.com/en/product/what-is-this-thing-called-theory-of-constraints
- ↑ H. William Dettmer, Goldratt's Theory of Constraints: A Systems Approach to Continuous Improvement, ASQ Quality Press, 1997.
- ↑ Faros AI, "The Acceleration Whiplash" / AI Engineering Report 2026. https://www.faros.ai/research/ai-acceleration-whiplash
- ↑ Vorne / Lean Production, "Theory of Constraints (TOC)." Secondary summary of the Five Focusing Steps, Thinking Processes, and Throughput Accounting. https://www.leanproduction.com/theory-of-constraints/