Theory of Constraints Manufacturing: Why You Couldn’t Use It

By Dr Lisa Lang, TOCICO Certified Expert and developer of the Velocity Scheduling System

Originally published March 6, 2026 | Updated September 2026

Dr Lisa has been named a “Manufacturing Champion” by Newsweek and featured in USA Today, CNBC, and Yahoo Finance for her work with custom job shops.

Theory of constraints manufacturing is the practice of applying TOC principles – specifically identifying and subordinating everything to the single constraint limiting throughput – in custom manufacturing environments. Most manufacturers understand TOC after reading The Goal but cannot implement it; the gap between theory and a working shop floor system is where VSS operates.

At some point, you read The Goal.

Maybe you read it twice. It made that much sense.

Goldratt laid it all out: the bottleneck, drum buffer rope, throughput accounting. The logic was airtight. You could see exactly why your shop was struggling, right there in a novel about a fictional plant.

So you went looking for how to implement it.

You found DBR resources. You found Theory of Constraints manufacturing communities and consultants who had spent years studying constraint management and could talk about buffer sizing for hours. You found books that went deeper into the theory. And then you hit the wall.

The wall between “this makes complete sense” and “here is how I actually schedule 400 custom jobs across 50 machines using this, starting tomorrow” turned out to be enormous.

You found resources built for academic mastery, not shop floor execution. You found frameworks designed for manufacturing environments that bore little resemblance to your high-mix, variable-routing, custom-job reality. You found plenty of people who understood TOC deeply and very few who could tell you specifically how to transition your scheduler’s whiteboard to throughput-thinking on Monday.

You closed the book.

You Made the Right Call

That was a rational decision. Not a failure of intelligence or commitment. Not a lack of persistence. The wall was real, and here is how I know: you were not alone on the other side of it.

I know because I asked the same question from the front of a room for years. At my peak I was giving 50 speeches a year. I would ask the audience: how many of you have read The Goal? About 25 percent of hands would go up. More in a manufacturing group. Then I would ask: how many of you implemented it? Most of the hands would come down. Sometimes all of them.

Goldratt asked the same question. I served as his global marketing director. I watched him work audiences around the world. Same question. Same result. The founder of the methodology, in a room full of people who had read his book, would see almost no hands stay up on “implemented it.”

That is not a failure rate. That is documentation. The gap was in the territory, not in the people who tried to cross it.

The “closed the book” moment is nearly universal among serious TOC students in a custom job shop environment. They engage with the theory. They find it compelling. They search for the bridge from “I understand the methodology” to “here is how I run my specific shop with it.” That bridge, in accessible and practical form, was not there.

Stopping when a bridge is not there is correct decision-making. Job shop owners make resource allocation decisions every day. “Cut losses on a path with no accessible route to results” is the same decision you make on the floor when a job cannot be completed as designed. That is production management. That is not quitting.

If you closed the book, you made the right call. What I want to explain is why the bridge did not exist, and why that changes now.

Why Theory of Constraints Manufacturing Is Harder to Implement Than It Looks

Here is what nobody explained about why the wall was so hard to cross.

Every scheduling tool you have ever been trained on, whether built into an ERP, a bolt-on job shop scheduling software module, MRP, or lean, runs on efficiency-thinking. The directive is: maximize utilization. Minimize cost per unit. Batch for efficiency. Load every machine to capacity.

Theory of Constraints and DBR run on throughput-thinking. The directive is: maximize flow. Protect the constraint. Release work based on constraint capacity. Let non-constraint utilization vary with actual demand.

These are not different versions of the same idea. They prescribe mathematically opposite behaviors for the same variable: resource utilization.

Your scheduling module is designed to increase WIP. Not as a bug. As a feature.

John Little proved in 1961 that WIP equals Throughput multiplied by Lead Time. This is not a theory. It is a mathematical identity: if WIP increases and Throughput holds, Lead Time must increase. That is not negotiable. Every time your scheduling module loads a machine to maximize utilization, it increases WIP. More WIP means longer lead times. Your scheduling module is the source of the lead time problem it was purchased to solve. Not because of a defect. Because of its design principle. It is optimizing for the wrong thing, correctly.

That contradiction does not stay theoretical for long. It shows up on the shop floor in a way your scheduler knows intimately. The scheduling module says load machine X to 100 percent because it is available. Throughput-thinking says machine X is not the constraint, so its utilization should vary with what the constraint can absorb. One tells you to keep the machine busy. The other tells you to let it wait. You cannot do both.

So your scheduler, who understands TOC, looks at the scheduling report, knows the signal is wrong, overrides it with judgment, and then has to explain to you why a machine is sitting idle when the system says there is work to do. Every day. That is not a skill problem. That is a system contradiction.

Consider what that day looks like in practice. The scheduling module says machine 7 is available with four hours of capacity. The system generates a work order to load it, a small run to keep the machine productive. By efficiency metrics, the correct move is to run it. By throughput-thinking, machine 7 is not the constraint. Loading it now creates a WIP pile-up in front of the constraint later this week, extending lead times on the jobs that actually matter. The correct move is to let machine 7 sit.

The scheduler knows this. They skip the work order. At the end of the week, machine 7 shows 72 percent utilization on the report. The shop owner asks why a machine sat idle when there was work available. The scheduler explains, again, that idle capacity at a non-constraint is not waste. It is buffer. Having this conversation every week is not a knowledge problem. The knowledge is there. The tool simply does not reflect the logic the shop is trying to run.