Theory of Constraints: A Practical Guide

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 was trained in it directly by Goldratt and his team, and I have been applying it for over twenty-five years. 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:

Identify the constraint. What is the one thing limiting the system right now?
Exploit it. Get everything you can out of the constraint as it exists today, before spending a dollar.
Subordinate everything else to it. Align the rest of the system to support the constraint, not to optimize locally.
Elevate the constraint. If exploiting and subordinating are not enough, invest to increase its capacity.
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.

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.