Sign inGet started
Skills / Productivity-habits

Theory of Constraints

An hour lost at a bottleneck is an hour lost for the entire system. An hour saved at a non-bottleneck is a mirage.

Theory of Constraints (TOC) is a management philosophy built on a single axiomatic truth: every system has exactly one bottleneck that governs total throughput, and improving anything else produces negligible results. Developed by physicist Eliyahu Goldratt through his 1984 business novel 'The Goal' — which has sold over 7 million copies — and formalized across 10+ books and the TOCICO certification body, TOC provides a repeatable 5-step algorithm for finding and eliminating constraints, a suite of logic trees for diagnosing root causes and resolving chronic conflicts, and domain-specific tools for production, project management, and distribution. It applies equally to factories, software teams, project portfolios, supply chains, and growing companies.

By Eliyahu M. Goldratt · Free
Specimen 01 · Live diagnosisTheory of Constraints
Input

“We run a software team of 14 people. Goal is shipping features that generate revenue. The problem is we've been missing every sprint deadline for…”

Diagnosis
Let's start where Goldratt always started: not with solutions, but with the constraint we haven't named yet.
Full transcript ↓
Calibrated referenceagent-skills.ai
The gap

Stop improving everything. Find the one constraint that limits your entire system.

TOC begins with a single question: what is the goal of your system, and what is preventing it? Goldratt's 5 Focusing Steps provide the master algorithm: (1) IDENTIFY the constraint — the weakest link in the system; (2) EXPLOIT it — squeeze maximum output without new investment; (3) SUBORDINATE everything else to serve the constraint; (4) ELEVATE it if steps 2–3 are insufficient; (5) PREVENT INERTIA — return to Step 1 when the constraint shifts. For complex diagnosis, the Thinking Processes provide six logic trees: the Current Reality Tree (CRT) traces Undesirable Effects to a single Core Problem via cause-and-effect chains; the Evaporating Cloud dissolves chronic conflicts by surfacing hidden assumptions; the Future Reality Tree validates that proposed solutions produce desired effects without negative branches. Domain-specific tools include Drum-Buffer-Rope (DBR) scheduling for production, Critical Chain Project Management (CCPM) for eliminating student syndrome and Parkinson's Law from projects, and the Mafia Offer for crafting unrefusable value propositions. Throughput Accounting replaces cost-world metrics with three measures: Throughput (T), Inventory/Investment (I), and Operating Expense (OE) — decisions are evaluated on T↑, I↓, OE↓, not arbitrary cost allocations.

The problem

Most improvement efforts attack local efficiency — optimize that department, speed up this process, cut costs everywhere — while the constraint, the one choke point limiting total system output, remains untouched or actively starved. Goldratt called this the 'cost world' trap: measurements and incentives reward local performance that has no bearing on system throughput. The result is a system where everyone is busy, projects multiply, and output barely moves.

The solution

Stop spending effort improving things that cannot improve your system's output. Walk away with the constraint identified, a plan to exploit it fully before investing a dollar more, and every other part of your system subordinated to feed it — the exact sequence that makes TOC practitioners report 30–50% throughput gains from existing resources.

You bring
  • A description of your system's goal and where output is falling short of it
  • Observable symptoms — where work piles up, which resource everyone waits on, which deadlines slip repeatedly
  • A chronic conflict or dilemma where every solution seems to create a new problem
  • Current metrics or operational data: cycle time, throughput, delivery performance, project slip rates
You get
  • A named constraint — the single leverage point where focused effort actually moves system-wide output
  • A text-based Current Reality Tree mapping your Undesirable Effects to a single Core Problem
  • An Evaporating Cloud diagram with surfaced assumptions and at least one injection to dissolve the conflict
  • A constraint exploitation plan — maximum throughput from existing capacity before spending a dollar
  • A subordination checklist auditing all non-constraint activities to confirm they protect and feed the bottleneck
In action

Watch the methodology work.

Three specimens from a single real session: the same situation, unaided and calibrated, the full transcript, and the skill answering live in the channel where the work happens.

Fig.01The same situation, two ways
Specimens A · B
Specimen AVague
Unaided

“Your plant runs three shifts, has invested in new CNC equipment, and is running overtime in two departments — yet ships 310 units a day against a target of 500. The plant manager blames machine reliability. The floor supervisor blames raw material quality. The sales team blames poor scheduling. You've run four improvement workshops this quarter, each generating action items, none moving the output number.”

×Vague — nothing concrete to act on.
Specimen BCalibrated
With Theory of Constraints

“Constraint identified: the heat treatment station at 94% utilization while all other stations run at 60–70%. Exploitation: a dedicated operator during shift changeovers and pre-staged batches eliminate idle time, recovering 18% of lost capacity at zero capital cost. Subordination: upstream stations are paced to never flood or starve the heat treatment queue. Output reaches 430 units by week three — not from working harder, but from finally working on the right thing.”

Specific, grounded, and ends with one clear next step.
Fig.02A real session, unedited
In-app · assistant
Theory of ConstraintsClaude
Theory of Constraints
Let's start where Goldratt always started: not with solutions, but with the constraint we haven't named yet. What is the goal of your system — and what's the number, or the result, you're most dissatisfied with right now?
We run a software team of 14 people. Goal is shipping features that generate revenue. The problem is we've been missing every sprint deadline for four months. Everyone says they're slammed, but we're still not shipping.
That gap between 'everyone is overloaded' and 'we're still not shipping' is exactly where TOC starts. In most systems, people are busy but the constraint is actually idle — because everything upstream is overwhelming it. Before we do anything else, let's identify your constraint. Three questions: Where in your pipeline does work visibly pile up — where is there always a queue? What step do other people wait on before they can continue? When a feature ships late, what reason is given most often?
Code review, honestly. PRs sit for two or three days sometimes. Developers finish their work and then just wait. When things are late it's almost always 'still waiting on review.'
That's your constraint — code review capacity is your bottleneck. Step 1 of the 5 Focusing Steps is complete: IDENTIFY. Now here's the key insight from Step 2, EXPLOIT: an hour of your senior engineer's review time is worth more to the system than an hour of them writing new code, because their code adds to the queue while their reviews move the system. Before we talk about adding reviewers, let's exploit existing capacity. Two questions: What percentage of PRs come back with major rework — meaning the reviewer has to look at the same code twice or three times? And how large are your typical PRs?
A lot of engineers batch up a week of work into one PR — they can be huge. And yeah, major rework happens a lot. Reviewers often send comments that require significant changes before they'll approve.
You have two exploitation levers right now that require zero new headcount. First: enforce a PR size ceiling — nothing over 200 lines of logic unless architecturally unavoidable. This typically cuts per-PR review time by 60–70% because reviewers can hold the whole change in working memory and spot issues faster. Second: add a developer pre-review checklist — does it build clean, do tests pass, is the intent described clearly — so your reviewers aren't burning constraint time on things the author should catch. Now for Step 3, SUBORDINATION: what are your likely reviewers — senior engineers — being asked to do that competes with review time right now?
They're in a lot of planning meetings and they're writing code themselves at the same rate as everyone else.
That's your subordination failure. Every non-review hour a senior engineer spends adds work to the constraint rather than clearing it. Subordination means their schedule changes: morning meetings yield to a protected 'review first' block; personal coding tasks are lower priority than unblocking review queues. That's not a demotion — it's the highest-leverage work in your system according to Goldratt's logic. One more thing to check: is there a policy anywhere — sprint planning, team norms, manager expectations — that explicitly or implicitly penalizes engineers for doing review instead of 'producing' code? Policy constraints are often hiding behind capacity constraints. Want me to build a Current Reality Tree that maps missed deadlines, engineer frustration, and rework back to the core policy driving the review bottleneck?
Reply to Theory of Constraints
What the skill is doing
015 Focusing Steps Walkthrough
02Constraint Identification Diagnostic
03Current Reality Tree (CRT) Builder
Fig.03The same skill, in the channel you already use
WhatsApp · live
9:41
TOTheory of Constraintstyping…
Messages are end-to-end encrypted. No one outside of this chat can read them.
Today
We run a software team of 14 people. Goal is shipping features that generate revenue. The problem is we've been missing every sprint deadline for four…9:14✓✓
Let's start where Goldratt always started: not with solutions, but with the constraint we haven't named yet.9:14
What is the goal of your system — and what's the number, or the result, you're most dissatisfied with right now?9:15
Message

The same skill, where the work happens.

No new app to learn. The methodology runs over the WhatsApp Business API, so the answer lands as a reply in the thread you’re already in — same rigour, zero context-switch.

Reads the situation, names the pattern, returns one concrete next move.
Delivered in seconds, inside a conversation that already exists.
Specimen · WhatsApp Business API · live
Capabilities

What it does, specifically.

Each capability is a distinct move drawn straight from the source methodology — not a generic assistant guessing.

CapabilityC-01

5 Focusing Steps Walkthrough

A guided, Socratic walk through Goldratt's master algorithm applied to your specific system — factory, project pipeline, service operation, or software team. The conversation moves from identifying the weakest link, to exploitation actions that require no investment, to subordination decisions that align the whole system, to elevation only when steps 2–3 are exhausted.

Directly implements Goldratt's 5 Focusing Steps from 'The Goal' (1984) — the core repeatable TOC algorithm applicable across every domain and industry, including the anti-inertia fifth step that prevents improvements from stalling after a constraint shifts.
CapabilityC-02

Constraint Identification Diagnostic

Structured questioning to locate your system's physical, policy, or market constraint — distinguishing between capacity bottlenecks, measurement policies that mask flow, and market constraints that require fundamentally different responses. Most organizations mistake symptoms (busy people, missed deadlines) for the constraint itself.

Draws on Goldratt's constraint taxonomy (physical vs. policy vs. market) and his diagnostic heuristic: the constraint is always the place where inventory accumulates upstream, and it is never the resource everyone is loudest about — from 'The Goal' and TOCICO body of knowledge.
CapabilityC-03

Current Reality Tree (CRT) Builder

Elicits the Undesirable Effects (UDEs) in your system — the symptoms that feel disconnected — and maps them into a cause-and-effect tree that traces back to a single Core Problem. Rather than fighting symptoms, the CRT reveals the one root cause whose removal collapses multiple UDEs simultaneously.

Based on the Current Reality Tree from Goldratt's Thinking Processes, introduced in 'It's Not Luck' (1994), using sufficiency logic (IF...THEN chains) to validate each causal connection and identify the Core Problem — defined as the node that, if removed, eliminates the most UDEs.
CapabilityC-04

Evaporating Cloud Conflict Resolution

Structures a chronic organizational conflict or personal dilemma as two legitimate needs stemming from a shared goal, surfaces the hidden assumptions that make them appear incompatible, then challenges those assumptions to find injections — solutions that satisfy both sides without compromise.

Based on Goldratt's Conflict Resolution Diagram (CRD) / Evaporating Cloud from 'It's Not Luck' (1994) and 'The Choice' (2008), which holds that every chronic conflict rests on at least one invalid assumption — once identified and challenged, the conflict dissolves entirely rather than being managed.
CapabilityC-05

Critical Chain Project Buffer Planning

Redesigns a project plan by stripping the safety time hidden in individual task estimates (student syndrome and Parkinson's Law), consolidating it into a project buffer at the end and feeding buffers at merge points. Buffer penetration — not individual task lateness — becomes the project health metric.

Implements Critical Chain Project Management (CCPM) from Goldratt's 'Critical Chain' (1997), which identifies that projects fail not from lack of safety time but from safety time being consumed by multitasking, bad multitasking, and student syndrome — all addressed by removing individual padding and managing shared buffers.
CapabilityC-06

Throughput Accounting Decision Analysis

Evaluates a business decision — hiring, purchasing, pricing, make-vs-buy, product mix — through TOC's three-metric lens: does it increase Throughput (T), reduce Inventory/Investment (I), and reduce Operating Expense (OE)? Produces a specific T/I/OE impact statement, replacing arbitrary cost allocations with system-level financial reasoning.

Based on Goldratt's Throughput Accounting framework from 'The Goal' and 'The Theory of Constraints' (1990), which replaces traditional cost accounting — which he argued drives local-optimum behavior — with a hierarchy where T always takes priority over OE and I reductions.
Tested

Graded before it shipped.

Every skill is scored against independent scenarios for methodology fidelity before it goes live — not vibes, a rubric.

What it produces
OutputD-01

Current Reality Tree (CRT)

A structured cause-and-effect map connecting your Undesirable Effects via IF...THEN sufficiency logic to reveal the single Core Problem. Each arrow is a validated causal claim. The tree shows which root cause, if addressed, collapses the most symptoms simultaneously — the highest-leverage intervention point in your system.

OutputD-02

Evaporating Cloud Diagram

A five-element conflict map: shared goal, two legitimate needs, two conflicting requirements, enumerated assumptions behind each conflict arrow, and injections that challenge invalid assumptions to dissolve the conflict. A standalone deliverable for any chronic dilemma that has resisted resolution.

OutputD-03

Constraint Exploitation Checklist

A prioritized list of actions to maximize throughput at the identified constraint without capital investment — eliminating downtime, reducing setups, removing policies that starve it, ensuring it never waits on non-constraints. Typically the highest-ROI document produced in any TOC engagement.

OutputD-04

Critical Chain Buffer Plan

A restructured project timeline with individual task safety removed and consolidated into a project buffer (end) and feeding buffers (merge points). Includes buffer sizing guidance and penetration monitoring schedule — the mechanism that replaces milestone-based project management with buffer consumption tracking.

OutputD-05

Subordination Audit

A systematic review of all non-constraint activities and policies, rated as 'supports constraint,' 'neutral,' or 'actively undermines constraint.' For every item in the third category, a recommended policy or behavioral change that realigns the system to protect and feed the bottleneck.

The source

Grounded in the original work.

Every answer traces back to a real source and the practitioner who wrote it — not a secondhand summary. Here is the source of record.

Source authorA-01

Eliyahu M. Goldratt

Eliyahu M. Goldratt (1947–2011) was an Israeli physicist who became one of the 20th century's most influential management thinkers. His 1984 business novel 'The Goal' introduced the Theory of Constraints and has sold over 7 million copies, remaining required reading in MBA programs worldwide. Goldratt founded the Goldratt Institute, authored 10+ books on TOC applications across manufacturing, healthcare, project management, and distribution, and established the TOCICO (Theory of Constraints International Certification Organization) to formalize the methodology's body of knowledge.

Status · Inspired by Eliyahu M. Goldratt’s work — not yet claimed. Are you Eliyahu M. Goldratt?
Primary sourceS-01

The Goal: A Process of Ongoing Improvement

by Eliyahu M. Goldratt

Israeli physicist turned management theorist; creator of TOC; 'The Goal' sold 7M+ copies; founder of the Goldratt Institute; established TOCICO certification body; taught in top MBA programs globally.

Read the original ↗
Citationtocico.org
In the build queue

Be first to run it.

Theory of Constraints is being built right now. Leave your email and we’ll tell you the moment it goes live.

Notify meEmail
At launchI want to run the 5 Focusing Steps on my operation. We keep missing output targets even though everyone seems at capacity — can you help me identify whether our constraint is physical, a policy, or something else entirely?