Skip to content

Theory of Constraints

The method behind the work. How we find the one thing that matters most, and what we do about it.

Eliyahu Goldratt was a physicist, not a business professor. He looked at organizations the way a physicist looks at a system: find the constraint, understand the forces acting on it, and change the right thing. Not everything. The right thing.

He called this the Theory of Constraints. I learned TOC over years of study: a graduate program at Washington State University taught by Dr. James Holt, Goldratt Group workshops and Satellite Programs, and nearly every TOC conference where Eli Goldratt spoke in the United States and abroad. I hold TOCICO certifications in TOC Fundamentals, Thinking Processes, and Critical Chain Project Management, earned in 2005 and 2006. I have been applying TOC for thirty years across healthcare, manufacturing, technology, and small business. It is the foundation of everything we do at Common Sense Systems.

This page is a reference. It explains the core idea, the main tools, and how I use them in practice. If you want to see one of these tools applied to a real problem, the hidden conflicts in healthcare post is a good starting point.

The Core Idea

Every system has a constraint. One thing, at any given time, limits how much the system can produce. Improve that one thing and the whole system improves. Improve anything else and nothing changes.

Think about a kitchen in a busy restaurant. Orders come in. Prep cooks chop vegetables. Line cooks assemble plates. The dishwasher cycles through racks. But only one oven fits in the space. Every dish that needs the oven waits its turn. The oven is the constraint.

You could hire a faster prep cook. You could buy an industrial dishwasher. You could remodel the dining room and seat fifty more people. None of it changes how many meals come out per hour, because every meal waits for that oven.

This is obvious in a kitchen. It is far less obvious in a hospital, a software company, or a supply chain, where the constraint hides behind departmental walls, reporting structures, and decades of accumulated assumptions. But the principle is the same. Find the constraint first. Everything else is noise until you do.

Goldratt put it simply: "Tell me how you measure me, and I will tell you how I will behave." Organizations routinely optimize departments in isolation, measuring each one against its own targets. This creates the illusion of progress while the system as a whole stays stuck. TOC starts from the opposite direction: what does the system need, and which single point is preventing it from getting there?

The Five Focusing Steps

TOC gives you a simple process for working with the constraint. Goldratt called them the Five Focusing Steps:

  1. Identify the constraint. What is the one thing limiting the system right now?
  2. Exploit it. Get everything you can out of the constraint as it exists today, before spending a dollar.
  3. Subordinate everything else to it. Align the rest of the system to support the constraint, not to optimize locally.
  4. Elevate the constraint. If exploiting and subordinating are not enough, invest to increase its capacity.
  5. Repeat. When you break one constraint, another becomes the new limit. Go back to step one.

The order matters. Most organizations jump straight to step four: buy more, build more, hire more. But if you have not first exploited what you already have and subordinated the rest of the system, the new capacity often goes to waste.

I saw this clearly at a community hospital in the Pacific Northwest. The cardiology service line told the governing board they needed to build a new cath lab. Demand was growing. Procedure time was booked solid during the day. The request was for tens of millions in construction.

Then a commissioner asked: what happens in the lab after hours?

The honest answer: the cath lab sits empty roughly 75% of every week. Evenings, nights, weekends. The constraint was not physical space. It was staffing and scheduling patterns that no one had questioned because "that's how cath labs operate." Step one, identify the constraint, changed the entire conversation. (That story is told in full in The Cath Lab Is Empty at 2 AM.)

The Thinking Processes

The Five Focusing Steps tell you what to do with a constraint once you have found it. But finding it, understanding it, and designing a solution that actually works requires a different set of tools. Goldratt called these the Thinking Processes.

There are five main tools. Three of them do the heavy lifting in most engagements: the Evaporating Cloud, the Current Reality Tree, and the Future Reality Tree. The other two, the Prerequisite Tree and the Transition Tree, help with implementation planning. I will spend the most time on the Evaporating Cloud because it is where I start almost every engagement, and because it is the tool most people find immediately useful.

The Evaporating Cloud

The Evaporating Cloud is TOC's conflict resolution tool. Its premise is simple: behind every chronic problem is an unresolved conflict, and behind every unresolved conflict is at least one hidden assumption that, once surfaced, opens a path forward.

Most conflicts in organizations are not between people. They are between legitimate needs. Two things that both matter, pulling in opposite directions. People get stuck because both sides are right, and the usual response is to compromise, argue, or avoid the issue entirely. The Evaporating Cloud makes the conflict visible so you can work on it directly.

The structure is straightforward. Five boxes connected by arrows:

  • A is the common objective. What everyone actually wants.
  • B and C are two needs, both necessary for achieving A.
  • D and D' are two actions or conditions. D satisfies B, and D' satisfies C. But D and D' conflict with each other.

The power of the tool is not in drawing the diagram. It is in what happens next: you examine the assumptions behind each arrow. Why does B require D? Is that always true? Under what conditions might it not be? The conflict "evaporates" when you find an assumption that does not hold, because that opens a way to satisfy both needs without the conflict.

An Example: Rachel's Bakery

Rachel runs a bakery. Business is good, but costs are rising and she is trying to decide what to do about pricing. She feels stuck between two choices that both seem necessary and both seem impossible to do at the same time.

The cloud looks like this:

  • A: Run a thriving bakery.
  • B: Maintain healthy margins. (You cannot run a thriving bakery without covering your costs and making a profit.)
  • C: Keep loyal customers. (You cannot run a thriving bakery if your customers leave.)
  • D: Raise prices. (To maintain healthy margins, she needs to raise prices to cover rising costs.)
  • D': Hold prices steady. (To keep loyal customers, she needs to keep prices where they are, because customers are price-sensitive.)

D and D' conflict. She cannot raise prices and hold them steady at the same time. This is where most people stop: it feels like an impossible choice, so they either agonize, compromise (raise prices a little and hope nobody notices), or avoid the decision entirely.

But look at the assumptions. The arrow from C to D' carries a critical assumption: "my customers will leave if I raise prices because they choose me primarily on price." Is that true? Rachel talks to her regulars. She finds that most of them come for the sourdough, which they cannot get anywhere else nearby. They come for the quality and the consistency. Price is a factor, but it is not the reason they walk through the door.

That assumption, once surfaced, changes the situation entirely. Rachel can raise prices on her commodity items (muffins, cookies) while keeping her signature sourdough competitively priced. She protects the relationship that actually drives loyalty while improving her margins. The conflict evaporates. Not through compromise, but through finding and challenging the assumption that made the conflict seem unresolvable.

Every Evaporating Cloud I have built in twenty-five years works the same way. The conflict feels real until you find the assumption that is not true. In healthcare, these hidden assumptions live inside policies, staffing models, and compliance procedures that nobody has questioned in years. They create chronic frustration for everyone involved, and they are almost always solvable once you can see them clearly.

For a deeper example of the Evaporating Cloud applied to a real healthcare policy, see Hidden Conflicts in Healthcare. I have also recorded a video walkthrough of the tool at Resolving a Sweet Dilemma, using Rachel's bakery as the worked example.

The Current Reality Tree

The Current Reality Tree (CRT) is a cause-and-effect diagram. It answers the question: why is the system behaving the way it is?

You start with the symptoms, the chronic problems that people complain about. In TOC these are called Undesirable Effects, or UDEs. Staff burnout. Long wait times. Missed deadlines. Customer complaints. Then you trace backward: what causes each symptom? And what causes those causes?

The CRT is a logical map, not a flowchart. Each connection requires a "because" statement that you can examine and challenge. "Staff are burning out because they are asked to resolve problems that require information they do not have." "They do not have the information because it is captured during the acute stay instead of before admission." You keep tracing until you find the root causes, usually two or three, that drive most of the symptoms.

The CRT is especially useful when an organization is dealing with many problems at once and does not know where to start. Rather than treating each symptom independently, the tree reveals which root causes, if addressed, would relieve multiple symptoms simultaneously. It turns an overwhelming situation into a focused one.

The Future Reality Tree

The Future Reality Tree (FRT) is the CRT's counterpart. Where the CRT maps the current system, the FRT maps the proposed solution. If we make this change, what effects will it produce? Will it actually resolve the UDEs we care about? Will it create new problems?

This is where most improvement efforts skip a step. People identify a solution and implement it without rigorously testing whether it will work. The FRT forces you to think through the cause-and-effect chain of your proposed change before you commit resources. It surfaces negative side effects early, when they are cheap to address, rather than after implementation, when they are expensive and demoralizing.

Implementation Tools: Prerequisite Tree and Transition Tree

Two additional Thinking Process tools help with implementation. The Prerequisite Tree identifies the obstacles between where you are and where you want to be, then sequences the intermediate objectives needed to overcome them. The Transition Tree breaks each intermediate objective into specific actions with expected effects. Together they turn a strategic insight into an executable plan.

TOC and Lean

People often ask how TOC relates to Lean. They are complementary, but they start from different places and they are strong in different situations.

Lean is powerful at eliminating waste in known processes. It maps value streams, identifies non-value-added steps, and systematically removes them. In a stable manufacturing environment with well-understood processes, Lean produces real and measurable results.

TOC starts with a different question: which process should you fix first? In a system with many problems, Lean gives you excellent tools for improving any one of them. TOC tells you which one matters. If you apply Lean to a non-constraint, you will improve that process beautifully and the system will not change at all.

There is also a philosophical difference in how the two frameworks define "value." Lean draws a clean line between value-added work (what the customer pays for) and waste (everything else). In practice, especially in regulated environments like healthcare, this binary breaks down. Compliance documentation is not something a patient would choose to pay for, but it is not optional. Safety checks do not add value in the Lean sense, but removing them would be catastrophic. TOC does not require you to classify every activity as value or waste. It asks a simpler question: is this activity supporting the constraint or not?

The honest observation is that most organizations undercommit to both Lean and TOC. They adopt the vocabulary without the discipline. They do a Lean project here, a TOC analysis there, and neither one gets the sustained attention needed to produce lasting results. The frameworks are not the problem. The commitment is.

Throughput Accounting

TOC rests on three pillars: the Five Focusing Steps, the Thinking Processes, and Throughput Accounting. The first two are about finding and solving the right problem. Throughput Accounting is about measuring whether you actually solved it.

The framework uses three measures. Throughput (T) is the rate at which the system generates money through sales, minus truly variable costs (raw materials, commissions, outsourced processing—things you only spend when you make a sale). Investment (I), which Goldratt also called Inventory, is the money tied up in things the system intends to sell: raw materials, work-in-progress, finished goods, equipment, buildings. Operating Expense (OE) is everything else: salaries, rent, utilities, insurance—the money the system spends whether it sells anything or not.

This is a fundamentally different lens than cost accounting. Cost accounting asks "what does this cost?" and tries to allocate every expense to a product or department. Throughput Accounting asks "what does this produce?" and treats most costs as fixed in the short term. The distinction matters because cost accounting leads to cost-world thinking: cut expenses, improve local efficiencies, reduce headcount. Throughput Accounting leads to throughput-world thinking: find the constraint, exploit it, and grow the system's output. Cost-world thinking tries to cut its way to prosperity. Throughput-world thinking tries to grow its way there. In my experience, the organizations that grow tend to outlast the ones that cut.

Here is a concrete example. A hospital is deciding whether to staff its cardiac catheterization lab on weekends. Cost accounting sees the labor expense: nurses, techs, an interventionalist on call. It looks like a cost center. Throughput Accounting sees the procedures that currently cannot be performed until Monday—the revenue from those cases, minus truly variable costs (catheters, stents, contrast dye), is the throughput the hospital is leaving on the table. When you frame the question as throughput rather than cost, the decision often flips. I explored this exact scenario in The Other Calculation, a Cascade Valley episode where a CFO and a department head arrive at different answers because they are using different accounting frameworks.

Throughput Accounting also clarifies the philosophical difference between TOC and Lean that I described in the TOC and Lean section above. Lean measures value by asking what the customer would pay for. Throughput Accounting measures value by asking what increases T, decreases I, or decreases OE—in that priority order. The priority order matters: throughput has no theoretical upper limit, but you can only cut costs to zero. An organization that focuses on T first and OE second will make structurally different decisions than one that focuses on OE first.

What TOC Is Not

TOC is not a complete management system. It is strong at one specific thing: identifying which problem to solve first. Once you have found the constraint, you usually need other methods to fix it. Lean for process improvement. Six Sigma for variation reduction. Agile for iterative delivery. TOC tells you where to aim. It does not always tell you how to shoot.

It also does not replace domain expertise. Finding the constraint in a hospital requires knowing how hospitals work—the regulatory environment, the clinical workflows, the politics of medical staff governance. The Thinking Processes structure your reasoning, but they do not supply knowledge of the system you are reasoning about. I have seen people build technically correct Current Reality Trees that were useless because the inputs were wrong. The tools do not protect you from your own blind spots. Bad data in, confident-looking but wrong conclusions out.

The most common misapplication of TOC is treating it as a one-time exercise. An organization identifies the constraint, fixes it, celebrates, and moves on. But the Five Focusing Steps are a cycle, not a checklist. When you break one constraint, a new one emerges somewhere else in the system. Organizations that "do TOC" once and then stop will watch the gains erode as the constraint shifts and nobody notices.

Goldratt himself acknowledged that TOC was incomplete and still evolving. One of his principles was "Never say 'I know.'" That applies to the methodology itself. TOC has real limitations. The Thinking Processes are powerful but demanding—building a sound Current Reality Tree takes rigorous logic, honest data, and a willingness to be wrong in front of other people. Not every organization has the appetite for that. And not every problem is best framed as a constraint problem. Sometimes the system is just broken in ordinary ways that do not require a formal methodology to fix.

I say all of this as someone who has used TOC for over thirty years and considers it the most useful thinking framework I have encountered. It is precisely because I trust the method that I can be honest about where it falls short. A practitioner who cannot name the limitations of their own tools is selling something.

How I Use TOC in Practice

Most of my engagements start with a conversation, not a diagram. I ask people what is frustrating them. What they have tried. What keeps not working despite their best efforts. The chronic problems, the ones that survive every reorganization and every improvement initiative, are the ones worth mapping.

From there I usually build an Evaporating Cloud. Not because it is always the right first step, but because it forces clarity about the conflict. If I can name the conflict, I can find the assumptions. If I can find the assumptions, I can test them. And testing assumptions is where breakthroughs happen.

Sometimes the work stays at the cloud level. A single conflict, clearly resolved, can unblock years of organizational paralysis. Other times the cloud reveals a deeper system problem that needs a Current Reality Tree to map fully. The tools are flexible. What matters is following the logic wherever it leads.

I also use TOC in combination with other methods. AI-assisted analysis helps me process large amounts of policy documents, financial data, and operational metrics to build more complete reality trees than I could construct manually. The Post-Acute Care Plan concept is a direct application of TOC's input-quality principle to hospital discharge. The constraint is never just one thing in isolation. It lives inside a system, and understanding the system is the work.

TOC in Practice

The best way to understand TOC is to see it applied. These are case studies and analyses from my own work, spanning healthcare, medical devices, engineering, and small business. Each one demonstrates a different TOC concept in a different setting. The methodology does not change. The context does.

Healthcare & Organizations

The cath lab story above is a clear example of Step 1, identifying the real constraint. The hospital assumed the constraint was physical space. It was actually staffing and scheduling. The full analysis is in The Cath Lab Is Empty at 2 AM.

Healthcare burnout is rarely a people problem. It is a structural conflict between legitimate organizational needs pulling in opposite directions. I mapped two of these conflicts using the Evaporating Cloud in Stop Blaming People, covering both burnout dynamics and discharge delays.

Cycle time is a throughput problem. The faster an organization moves through its decision-observe-act loop, the more adaptive capacity it has. I applied this thinking to hospital operations in Speed as a Strategy, using the OODA loop as a throughput framework.

Some of the most persistent problems in healthcare are policy conflicts that nobody has named. The Evaporating Cloud is built for exactly this. I worked through several examples in Hidden Conflicts in Healthcare.

Patient flow through a hospital is a system dynamics problem. Beds are not the constraint; the constraint is whatever prevents patients from moving through them. I mapped the physics of this in The Physics of Patient Flow.

MedTech & Engineering

A medical imaging company's customer support department was treated as a cost center and measured on cost reduction. The Five Focusing Steps revealed that support was actually the constraint on customer retention and growth. Changing the policy constraint turned cost into revenue. The full case study is From Cost Center to Growth Engine.

On an 18-month defibrillator development program, the communication interface between two subsystems became the constraint on the entire project timeline. Exploiting that single constraint recovered two months of schedule. I wrote up how in The Defibrio Communication Protocol Case Study.

What happens when every department optimizes locally and nobody asks what the system constraint is? A product company with excellent engineering ships late, over budget, and loses its market window. This is a subordination failure, and I traced the pattern in The Perfect Product That Killed a Company.

Small Business

A fine art printing shop in Kent, Washington had a graphic artist buried in rework because orders arrived incomplete. Pre-flight checks, a work-in-progress limit, and an expedite lane recovered 35% throughput in one week. This is drum-buffer-rope at its most basic. The story is in How a Print Shop Found 35% More Capacity in a Week.

If you run a small business and want to understand the Five Focusing Steps without academic language, I wrote a worked example using a remodeling contractor in The One Thing Slowing Down Your Business.

Sometimes the constraint is not operations at all. The website looks great, the service is good, and the phone is not ringing. That is a market constraint, and the fix is not working harder on operations. I wrote about this in Your Website Looks Great. Why Isn't the Phone Ringing?

Teaching & Audio Drama

The bakery pricing dilemma in the Evaporating Cloud section above has a video companion. I walk through building the cloud step by step in Resolving a Sweet Dilemma.

Throughput accounting changes how you make decisions. Cost accounting asks "what does this cost?" Throughput accounting asks "what does this produce?" The difference matters, and I explored it through the Cascade Valley Health System audio drama series in The Other Calculation.

The Cascade Valley series begins with a hospital board meeting where a new voice introduces TOC thinking into a room full of conventional assumptions. That pilot episode is The Meeting That Went Differently.

TOC Learning Path (Books, Research, and Communities)

Most TOC reading lists are either too basic or too academic. This one is sequenced. Start with the foundations, then pick a track based on the problems you solve most often.

Stage 1: Foundation (required before specialization)

  1. Read The Goal and It's Not Luck. This gives you the baseline language of constraints, throughput, and conflicts.
  2. Use the TOC Self Learning Program to fill gaps systematically.
  3. Map your study plan to the TOCICO Body of Knowledge so your progression follows recognized domains.

Track A: Thinking Processes (Cloud, CRT, FRT)

Use this track if your constraints are structural conflicts, policy contradictions, or cross-functional misalignment.

Track B: Operations and Throughput

Use this track for flow, scheduling, capacity, and system-level operational performance.

Track C: Project Environments (Critical Chain)

Use this track for R&D, product development, and multi-project pipeline management.

Track D: Healthcare Systems

Use this track for flow, length of stay, wait times, and cross-continuum coordination.

TOCICO resources that are easy to miss

Suggested cadence

Keep one conceptual source, one empirical source, and one implementation source active at all times. In practice, that means one Goldratt text, one paper, and one case study or webinar each month. This keeps your TOC understanding both rigorous and executable.

Get in Touch

TOC is not a magic formula. It is a discipline. It requires honest answers about what is actually going on, and the willingness to challenge assumptions that have been operating unchecked for years. That is uncomfortable work, and it does not produce overnight results.

But in my experience, it produces the right results. When you find the real constraint and address it directly, the system moves. Not incrementally, but meaningfully. Problems that resisted years of effort resolve in weeks once you are working on the right thing.

If you are dealing with a system that feels stuck, despite smart people and genuine effort, I am happy to think through it with you. Reach me at john@common-sense.com.