Chapter 1: A Confession

When I first read The Goal¹ in 1992, I thought I understood it.

I was twenty-seven years old and working at Xerox in upstate New York when I read Eli Goldratt’s book. It hit me with such force that I moved to Los Angeles to run production planning at one of Xerox’s factories. This factory supplied printed circuit board assemblies, or PCBAs, to Xerox factories making copiers, printers, and fax machines.

Like the UniCo plant in The Goal, the factory suffered from a large past-due backlog, poor on-time delivery, and high inventories. It supplied every Xerox factory, so if it struggled, they all struggled. I was excited by the chance to use what I had learned from The Goal to turn it around.

The daily “sunrise” meetings were exactly like the book had described. Every morning there was a different explanation—a different reason—for why yesterday’s production schedule had been missed, followed by congratulations and pats on the back for handling the latest crisis or calming another angry customer. I thought I only had to find THE constraint that was holding the factory back and the rest would follow.

So, after my first week, I went looking for the constraint. I looked and looked, and I couldn’t find it. Inventory was supposed to pile up in front of the constraint, but in this factory it was everywhere.

If you’ve ever tried to bring a powerful new idea to life, you know that feeling. The theory makes perfect sense; reality refuses to cooperate.

After another week, I stopped trying to follow the theory and started trying to understand the factory. I called together the shop supervisors and asked them a simple question.

“You have told me that the production schedules we give you do not make sense. I agree. If you were doing my job, how would you schedule this factory?”

Their answers taught me a great deal—about the Theory of Constraints, about management, and about trusting people more than the data. They explained that the factory had two distinct flows. One was a high-volume Surface Mount Technology, or SMT, flow configured like an assembly line: boards went in one end, finished assemblies came out the other. It flowed well.

The real problem was the low-volume business, where the same equipment was shared by many different products, each requiring different setups and routings. Then they said something that caught me by surprise.

“Just schedule the DDAR machine,” they said. “It inserts electronic components into the printed circuit boards. That’s our critical machine. Don’t worry about scheduling the others. Give us three days before DDAR and three days after it, and we’ll manage the upstream and downstream machines within that window.”

These supervisors understood their operation. They knew how to manage it, and they hadn’t even read the book.

Using their answers, we built a simple spreadsheet for scheduling the factory and turned it around, reducing inventory by fifty million dollars, virtually eliminating the past-due backlog, and increasing on-time delivery to 98 percent in just sixty days.

Al Dugan, the worldwide head of manufacturing came to visit. Our presentation slot was canceled last minute—he was running late. When he came to the shop floor, I stepped in front of him and said the supervisors had something to tell him. He stopped, he listened, and afterward he wrote a letter saying it was the highlight of his visit—not just the numbers but ownership of the first line supervisors.

Over the next thirty-five years, I would apply the Theory of Constraints in high-volume factories, job shops, aircraft maintenance, engineering organizations, hospitals, shipyards, a mine, and service businesses on five continents. I would work alongside extraordinary people, build companies, lose companies, succeed beyond anything I imagined, and fail more publicly than I ever expected.

Along the way, I realized something. The Theory of Constraints was even more powerful than I had believed—but not for the reasons I first thought.

This is not a book about the Theory of Constraints. There are already excellent books that explain the theory. This book is about what thirty-five years of applying that theory taught me. Many of those lessons confirmed what Eli had written. Some surprised me. A few contradicted what I thought I understood. Together, they changed the way I think about operations, about business, about leadership, and about causing change.

Chapter 2: Managing by Constraints

The Five Focusing Steps Are Invaluable. Their Sequence Is Flexible.

• Identify the system's constraint.
• Decide how to exploit the system's constraint.
• Subordinate everything else to the above decision.
• Elevate the system's constraint.
• If, in the previous steps, the constraint has been broken, go back to Step 1. Do not allow inertia to become the next constraint.

When I first learned the Five Focusing Steps, I was taken by their elegance. After Xerox, I thought I understood them. We had transformed one of the company’s worst-performing factories by organizing everything around what the supervisors recognized as the critical resource. We had found and elevated a constraint that should never have been the constraint but had become one because the number of operators had been reduced from two to one as a cost-cutting measure.

I believed I knew how the theory worked. Together with Pratik and Ravi, I started Thru-Put Technologies to provide production planning and scheduling software based on it. Pratik was a relative I had met briefly at a family wedding. Ravi was his neighbor who wrote the first lines of code on December 31, 1992. Within a year, we had real customers.

One of the first was PL Porter, a seat-controls manufacturer near Los Angeles. Glen Hobbs, the production manager, had found us at an APICS conference, bought the software, and started using it. Then he called me.

“What good is your software?” he asked. “I can optimize the schedule better than your algorithm.”

He was right. He knew his factory better than any software ever could. He knew the machines, the operators, the setups, and all the practical realities that never appear in a routing file. I told him so, but then I asked him another question.

“Glen, the software gave you the starting point. Without it, what would you have optimized?”

He thought for a moment. “You’re right,” he said.

I pushed further. “All that optimization—the precise sequencing, the fine-tuning—the variability of the shop floor will overwhelm a precise schedule before it’s even executed. Many of those decisions can be made only in real time, on the floor, not in the software at the time of planning.”

Glen shifted his attention from perfecting the plan to managing execution. On-time delivery improved. Throughput increased. Before long, he had been promoted.

At PL Porter, I learned that exploitation could not be delegated to software. Software could help identify the problem and create a coherent starting point, but exploitation required human judgment, exercised in real time by people who understood the system.

Then came Allied Signal. They manufactured aircraft wheel brakes. Their process included a large curing furnace, and everyone naturally assumed the furnace was the constraint. But when we scheduled the real constraint—a different machine where every part required a different setup—the schedule kept demanding furnace setup changes with every part. Had we followed it literally, we would have created the very constraint we were trying to avoid.

So we stopped trying to schedule the furnace. Instead, we placed a buffer of work in front of it and asked the operators to manage it. Look at the queue. Group similar parts. Batch intelligently. The software would schedule the real constraint. The operators would manage the furnace.

It worked.

For years I summarized Allied Signal by saying that, until flow has been established, subordination comes before exploitation. That is largely true, but it is not an absolute. The important insight is that we had to understand the system before the sequence became obvious. We were not asking ourselves which step came next. We were asking what the system needed.

Accurate Tool made the lesson even clearer. Rob Cocco had inherited a small job shop outside Philadelphia from his father. He had read The Goal. He had even read The Haystack Syndrome. He loaded his data into our software and called me two days later.

“There are some glitches,” he said. “Your software gives different Red Lane Peaks and First Day Loads (temporary overloads on non-constraints) every time. But it doesn’t matter—that’s all nonconstraint stuff. I’ll manage it.”

“There are some glitches,” he said. “Your software gives different Red Lane Peaks and First Day Loads (temporary overloads on non-constraints) every time. But it doesn’t matter—that’s all nonconstraint stuff. I’ll manage it.”

Rob ignored the advice. “I’m going to put a lock on the warehouse,” he said. “I control what gets released onto the shop floor based on the schedule. That’s it.”

Seven days later, throughput was up ten percent. Seven days after that, another fifteen percent. Within three or four weeks, throughput had increased by sixty to seventy percent.

No training program. No change management. No buy-in workshops. Just a lock on a warehouse door. Managerial courage, physically expressed, simple enough that nobody could argue with it, immediate enough that results arrived before doubt had time to organize itself.

Thirty years later, I found myself confronting the same lesson in an industry I knew nothing about. In 2023, I was given an opportunity to run Vulcan Mozambique, Africa’s largest coal mine. I had never worked in a mine. I had never even seen one.

When I arrived, the mine was losing twelve million dollars a month, and we were not meeting our production and revenue goals. To meet them, we had to dig more coal from the mine, process more coal in the washery, and transport more coal to the shipping port. Apparently, there were three interactive constraints in the business.

The trains were the first problem we tackled because digging and washing more coal would be a waste if we could not move it to the port. There were twenty-one trains running a 900-kilometer circuit between the mine and the port. We could not increase the number of trains; we had to run them faster. Every previous attempt to improve performance had focused on making the trains move faster and reducing train stoppages. But the more I studied the system, the less convinced I became that speed was the issue.

I kept asking questions until the system finally came into focus. Was it the scheduling of trains? The failure of traction motors? The high moisture in coal that delayed loading? The rains washing away sections of the tracks? The villagers and their goats walking onto the tracks?

Then we realized that the unloading station at Nacala was the real constraint. One unloading station. Almost four hours required to unload one train. Twenty-one trains arriving irregularly— sometimes queueing up for unloading, sometimes leaving the unloading station idle. No wonder the total time to unload twenty-one trains was close to 120 hours. The cycle time for each train was equal to the time taken to cycle all trains through the constraint! Once we saw that, the answers became obvious.

We reduced the fleet from twenty-one trains to eighteen operating on a timetable. The other three became a buffer. Rhythmic departures and the buffer ensured the unloading station could work at full capacity and queues did not propagate backward. A bit of process improvement brought the unloading time down to 3.5 hours.

We reduced the number of trains by fifteen percent, cut cycle time by forty-five percent, and increased haulage by fifty-five percent.

Fewer trains. More coal.

Only afterward could I look back and recognize the Five Focusing Steps. They had all been there. We had identified the constraint, exploited it, subordinated everything else to it, and only then considered elevation.

Across Xerox, PL Porter, Allied Signal, Accurate Tool, and Vulcan, every one of the Five Focusing Steps was present, but not every step was equally important. Thinking through all the steps was indispensable. Without them, none of these problems would have been solved. But the starting point was different every time.

Xerox was a textbook implementation, even though we started with a wrong constraint. At PL Porter, the software created the starting point, but exploitation happened on the shop floor. At Allied Signal, subordination had to be tackled first. At Accurate Tool, Rob skipped straight to the simplest possible form of subordination. At Vulcan, identifying the constraint correctly was the key, and I spent days doing that.

What Reality Taught Me

• Each of the Five Focusing Steps is powerful by itself.
• But they are not a recipe. They are a way of understanding systems.
• Sometimes the solution is straightforward; sometimes it takes effort.
• When the solution finally appears, it is usually simple: a spreadsheet around the DDAR, a starting schedule Glen could improve, a buffer in front of the furnace so that it doesn't become a constraint, a lock on the warehouse door, eighteen trains instead of twenty-one.

‍

A Personal Note

Many times, I wonder whether I would have learned as much without my co-founders at Thru-Put, Pratik and Ravi. We didn't start the company just to become tech millionaires. We did it because we had fallen in love with The Goal and believed scheduling could change the way factories were managed. Whenever we hit a dead end, we went back to first principles. We challenged each other relentlessly and kept asking what the system was really telling us.

‍

Find this article interesting, read:

Part 2: Managing Imperfection Without Creating Micromanagement

Part 3: From Insight to Breakthrough: The Philosopher-Warrior

‍

Read more articles:

Why Software Has Struggled to Deliver in the Construction Industry?

How CCPM and Little’s Law Reduced Cycle Time in Aircraft Maintenance at WR-ALC?

Reducing Cycle Time by 33% at WR-ALC: A U.S. Air Force Case

Solar Projects Don’t Miss Timelines for the Reasons You Think

Critical chain project management (CCPM): why projects remain late and how CCPM actually fixes it?

Why projects are late even when everything seems managed?

Beyond fragmentation: Toyota's cell manufacturing model offers a blueprint for construction

What if our best attempts to minimize time and cost overruns in projects are pointless?

How we can solve the late project problem?

Implementing critical chain in large infrastructure projects

Part 1: Why critical chain is not a science?

Part 2: Who said critical chain is not a science?

Part 3: Let’s make critical chain a science