Chapter 5: Harnessing Ingenuity

Science Takes You Only So Far. The Rest Is Engineering.

There are problems the Theory of Constraints handles beautifully. The constraint is obvious, the logic is clear, and the Five Focusing Steps lead naturally toward the solution. Then there are the other problems. The theory points you in the right direction, but the application does not fit any textbook case. Those problems require invention.

Over the years I have come to believe that this is where much of the value is created. The science tells you where to look. Engineering creates the solution. Every breakthrough I have seen has been different, but they all shared one characteristic. The answer was surprisingly simple.

One of the first examples came from Elecon, a gearbox manufacturer in India. The factory was overflowing with finished gearboxes, yet customers were waiting for deliveries. At first glance, it made no sense. The parts were there. The problem was that they were locked inside the wrong products. Base gearboxes had been assembled with options that did not match current customer orders.

Manoj Agarwal from Thru-Put India asked a simple question. What if we disassembled the finished gearboxes, removed the wrong options, assembled the correct ones, and shipped them?

Cost accounting viewed it as unnecessary rework. Throughput viewed it differently. The parts already existed. We simply had to put them into the configuration customers actually wanted. Within two days, gearboxes that had been sitting in inventory were moving to customers.

That solved one problem and immediately exposed another. Individual cities did not generate enough demand to fill an entire truck, so finished gearboxes continued to wait.

The factory was in Baroda. Auto-rickshaws travelled constantly between Mumbai and Baroda, returning with empty space. Manoj asked another obvious question. Why not use the return trip? One or two gearboxes on each vehicle gave the drivers additional income and customers received their orders days earlier. Freight cost per gearbox increased. Flow improved.

The same pattern appeared the U.S. Air Force maintenance depot in Warner Robins. Aircraft entered heavy maintenance, and some replacement parts had long procurement lead times. The conventional response was to begin reassembly wherever possible while waiting for the missing parts. The result was predictable: hangars filled with partially assembled aircraft, mechanics were spread across too many jobs, and very little actually finished.

The real problem was not supplier lead time. It was resource scattering.

Instead of beginning reassembly immediately, Bill Best and his team created a deliberate holding phase. Aircraft waited until every long-lead part had arrived. Mechanics stayed focused on work that could actually be completed. Supplier lead times did not change. Work-in-process did.

Delta Airlines revealed another form of the same problem. During peak season the airline suffered hundreds of maintenance-related cancellations. Everyone focused on improving maintenance productivity. The real issue was that maintenance parts were staged in Atlanta while the aircraft themselves were spread across the world.

The first solution was straightforward: let the parts travel with the aircraft.

The second was more interesting, and it came from Ajai Kapoor, my co-founder at Realization. Before the summer season, about seven hundred aircraft required maintenance, but there was capacity to perform deep maintenance on only three to four hundred. Rather than touching all seven hundred, we concentrated on completing three hundred properly and left the others alone. The workload became smoother, interruptions declined dramatically, and Delta moved from ninth to second in industry-wide on-time performance.

Vulcan Mozambique produced two more examples.

After the first improvements, the wash plant became the constraint. The obvious solution was to improve reliability, but a wash plant contains roughly one thousand components connected in series. Improving individual reliability could only take us so far.

The idea came from an ordinary event. My car broke down shortly before its scheduled service. Since it was already in the workshop, I asked the mechanic to perform the planned maintenance as well. Driving back to the mine, I realized we were treating planned and unplanned maintenance as separate events.

Why?

Unplanned downtime was inevitable. Why not use it?

We divided planned maintenance into pre-kitted maintenance buckets. Whenever an unplanned breakdown occurred, the maintenance crew immediately executed one of the planned maintenance buckets while the plant was already stopped. Available operating hours increased by roughly one hundred hours each month without adding equipment.

The mine itself revealed another opportunity. Excavators and trucks operated as tightly coupled systems. Failures propagated from one machine to another until overall system availability was far lower than the availability of any individual machine.

Instead of trying to keep every excavator operating continuously, we planned around eight active excavators while four formed a spare pool. Whenever an active line failed, another excavator immediately replaced it. Production continued while repairs took place without disrupting the rest of the mine. Over time, the spare pool also revealed exactly where engineering attention belonged because the machines used most frequently exposed the weakest parts of the system.

One final lesson came from Daisy, a property management company in New York. Nearly one hundred people managed about two hundred buildings, yet customer satisfaction had fallen to twenty percent. Every issue travelled through a chain of specialists. Finance handled one part. Maintenance another. Regulatory another. Every handoff created another queue, and no one owned the outcome.

The solution was to eliminate the handoffs. One person owned each issue from beginning to end. Specialists still contributed, but ownership never moved. The queues disappeared, feedback became immediate, and within weeks customer satisfaction rose from twenty percent to sixty percent.

Looking back, these examples appear unrelated. Gearboxes, military aircraft, commercial airlines, coal mines, and property management have very little in common. Their solutions were completely different. Yet underneath them all was the same pattern.

The issue always was which dependencies in the system were hurting performance. Almost always it was a resource dependency that was being mismanaged. Science identified where the leverage existed. Ingenuity created the intervention.

And the best interventions were always remarkably simple.

What Reality Taught Me

• TOC tells you where to focus. Ingenuity produces the answer.
• Every system requires its own solution.
• The measure of understanding is not sophistication. It is simplicity.

Celebrating Problem Solvers

Almost every implementation required ingenuity, whether technological or managerial. TOC pointed us in the right direction, but the solution came from people who understood their own operations deeply enough to invent it. Watching those moments of ingenuity unfold has been one of the great joys of my career.

‍

Chapter 6: The Philosopher-Warrior

TOC Might Be Common Sense. But It Defies Common Wisdom.

Step jumps in performance do not happen by accident. They happen when someone thinks deeply enough to see what others cannot see, and then acts decisively enough to implement what looks wrong to everyone else.

That combination is rare. Most organizations have plenty of thinkers who never act and plenty of actors who never think. The people who create breakthrough results have both qualities simultaneously. I have come to think of them as Philosopher-Warriors.

Every story in this book required one.

At Xerox, the philosopher asked what the people closest to the work already knew. The warrior trusted the supervisors and bypassed the MRP system.

Rob Cocco was the philosopher who understood which software bugs mattered and which did not. He was also the warrior who put a lock on the warehouse door.

Bill Best was the philosopher who saw resource scattering as the real problem, and the warrior who let aircraft sit idle until the parts had arrived.

At Delta, the philosopher saw that parts location and arrival rate were the real constraints. The warrior deferred four hundred aircraft before peak season and absorbed the criticism that the decision looked like failure.

At Vulcan, the philosophy came first: make-to-order, the unloading station as the constraint, Cash Score over cost per unit. Then came the warrior's work: introducing make-to-order to a mining company, reducing trains when everyone expected more, and making loader decisions based on cash generation when conventional accounting pointed elsewhere.

The result was a transformation from a twelve-million-dollar monthly loss to roughly sixty million dollars of monthly profit.

The philosopher asks: What is the objective? What is the constraint? What assumptions should be challenged? What is the minimum intervention?

The warrior acts on the answers, does not confuse analysis with progress, creates urgency, persists through resistance, and forces movement when necessary.

Neither alone is sufficient. The philosopher without the warrior produces elegant theory that never gets implemented. The warrior without the philosopher produces decisive action in the wrong direction.

Every story in these thirty-five years has been a story of finding that combination—sometimes in a single leader, sometimes in a partnership, sometimes in a team. When it is present, the results follow. When it is absent, even the right theory and the right tools are not enough.

Luck or Destiny?

I have been fortunate to work with many Philosopher-Warriors, only some of whom I've referenced in my stories. None of the successes would have been possible without them. But I don't believe it was all luck. TOC attracts these personalities because it demands both deep thinking and decisive action. It rewards people willing to question assumptions, and act when conventional wisdom tells them not to.

‍

Chapter 7: Still an Unsolved Problem

The Crisis Creates the Opening. Success Leads to Reversion.

After thirty-five years applying the Theory of Constraints in factories, mines, hospitals, startups, construction projects, shipyards, and service organizations—across hundreds of organizations, on five continents, and in almost every kind of operational complexity imaginable—two things remain true: the messier the operation, the more relevant TOC becomes, and the messier the reality, the simpler the solutions must be.

Those lessons have been confirmed over and over again.

There is one more recurring lesson, however, and it continues to trouble me.

During a crisis, organizations become remarkably open to new ways of thinking. Long-held assumptions are questioned. Decisions that would have been impossible a few months earlier suddenly become obvious. People rally around a common objective, and breakthrough performance becomes possible.

Then the crisis passes. The old paradigm begins to feel safe again. Cost control returns to the center. Local optimization quietly reappears. Old measurements regain their influence. Gradually, almost imperceptibly, the organization drifts back toward the very behaviors that created the crisis in the first place. The Philosopher-Warrior leaves the building.

That, I believe, is the hardest problem I have encountered in thirty-five years. Creating breakthrough performance is difficult. Sustaining it may be even harder.

• How do we sustain success after the burning platform has disappeared?
• How do we stop organizations from returning to the comfort of the familiar?
• How do we institutionalize curiosity without institutionalizing bureaucracy?

I don't know.

My Hope

Perhaps this is the next frontier for the Theory of Constraints.

Perhaps this is the problem the next generation will solve.

‍

Appendix: The Allure of The Goal

At the time, The Goal felt like something new. I could not fully explain why. It simply felt different— and more powerful—than everything else I had learned in engineering and management.

Looking back, most operations management methods addressed one of two kinds of problems.

The first are point problems: how to improve a specific machine, part, product, resource, or decision. These problems are often solved with optimization, cost accounting, forecasting, statistics, Pareto analysis, and similar techniques.

The second are process problems: how to improve a sequence of activities. These problems are addressed through methods such as Critical Path Method, Material Requirements Planning, value stream mapping, Lean events, model lines, and business process redesign.

The Goal was different because it addressed a third kind of problem: flow problems.

Flow problems are about the performance of the entire operation rather than any individual resource or process. How do we reduce delivery lead times? How do we shorten project duration? How do we increase patient flow through a hospital? How do we increase the profitability of the whole factory rather than one product?

Flow problems are fundamentally problems of coordination. Most flow time consists of waiting rather than work. Product waits for a machine. A project waits for an engineer. A patient waits for a bed. A mechanic waits for a part. At the same time, capacity is lost because resources wait for inputs, decisions, or downstream availability.

That is why improving one step often fails to improve the whole system. A machine can become more efficient without increasing output. One department can reduce cost while creating queues elsewhere. A local improvement can consume scarce capacity, materials, capital, or management attention that would have created greater benefit somewhere else.

This is what The Goal helped me see. The real question was not how to optimize a single step or redesign a process. It was:

How do we allocate resources and coordinate work so that the entire operation performs better?

The Theory of Constraints gave me three practical ways to think about that question: the Five Focusing Steps, Buffering/ Buffer Management, and Throughput Accounting.

‍

Find this article interesting, read:

Part 1: When the Theory of Constraints Meets Reality

Part 2: Managing Imperfection Without Creating Micromanagement

‍

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