Goldratt said “the admiration with sophistication is totally wrong.” He said “complicated solutions don’t work, but simple ones might.” He built the entire Theory of Constraints on a concept he called Inherent Simplicity: every system, no matter how complex, has a small number of leverage points that govern everything.
I was trained by him. I taught it for 30 years. I still believe it. But after twenty years of process simplification in job shops, I’ve started to think we’ve been applying it wrong.
He was wrong about one thing.
Not the principle. The application. Goldratt understood something most people don’t: to simplify well, you have to deeply understand. You can’t compress what you haven’t mastered. That’s why simplification in his hands was genius, and in most people’s hands it’s just cutting corners.
But here’s what Goldratt never questioned: he assumed the people running the system had to be able to follow it. So the system had to be simple enough for humans. That wasn’t a flaw in his thinking. It was the only option available to him. The execution model was human. Period.
What if it isn’t anymore?
The Problem With Process Simplification in Job Shops
I want you to think about the most recent SOP you wrote. Or rewrote. Or “streamlined.”
Not a theoretical one. The actual document sitting in your shop’s system right now for your most critical process.
Here’s what I already know about it without seeing it.
It’s simpler than it should be.
Not because you’re lazy. Not because you don’t understand your own process. Because somewhere between the first version and the current version, you stripped things out. You had to. A quality check got dropped because the second-shift guys never did it anyway. A branching decision got flattened to a single path because new hires couldn’t follow the logic. An inspection step got reduced from five measurements to two because the operator doing it was already behind on three other jobs.
You know exactly what I’m talking about.
And it wasn’t just you. Every management framework you’ve ever encountered told you to do exactly this. Simplify. Standardize. Design for the weakest link. Build processes around what humans can realistically follow.
That’s not a strategy. It’s the law of gravity in operations. Nobody questions it because everybody has lived it.
You’ve watched it happen. The new hire who skips step 12 because “nobody told me that one mattered.” The experienced operator who takes shortcuts at 4 PM because he’s been on his feet since 6 AM. The quality inspector who eyeballs the measurement instead of using the gauge because she’s 30 parts behind. These aren’t bad employees. These are human beings doing what human beings do.
So you adapted. You built everything around one question: “What can I actually get people to do consistently?”
And the answer is always: less than you want.
Here’s what I want you to do right now. Pull up the SOP or work instruction for your highest-dollar job. The one that makes you the most money. Now answer three questions.
How many steps were in the original version of this process? Think back to when you first designed it, when you captured everything that mattered.
How many steps are in it now?
For every step you removed, why did you remove it?
I’ll save you some time on that last one. Almost every answer falls into one of these:
“People weren’t following it.”
“It was too complicated for training.”
“We couldn’t get consistent execution.”
“Nobody had time to do it all.”
Notice something? Not a single one says the step was wrong. Not one says “we removed it because it didn’t add value.” You removed steps that added real value because humans couldn’t reliably execute them.
Every time you “streamlined” a process, you weren’t making it better. You were making it survivable. There’s a difference. The better version already existed. You built it. Then you had to kill it because the execution model couldn’t sustain it.
And you did this with every process in your job shop. Not just one. Your quoting. Your scheduling. Your inspection protocols. Your routing logic. Your customer communication. Every single system in your shop has been simplified. Compromised. Not because the simple version was better, but because the better version wasn’t survivable with human execution. That’s the real cost of process simplification in job shops. Not efficiency gained. Capability lost.
You’ve been running your job shop for 10, 15, 25 years. And every single year, the direction of travel has been the same. Simpler. Fewer steps. Lower bar. You call it “streamlining.” You call it “standardizing.” You call it “being practical.”
What if you’ve been optimizing in the wrong direction this entire time?
Not because simplifying was the wrong call. It was the right call. Given the constraint you were working under. But what if that constraint just disappeared?
Here’s the thing about practical versus possible. The practical version is what your team can run. The possible version is what the work actually requires.
Thirty years of dumbing it down. Now you can smarten it up.
What Happened When I Stopped Simplifying
I’ll tell you what happened to me. Because it’s the same thing that’s happening in your shop, just in a different wrapper.
About a year ago I started using AI for my business. Writing emails, drafting content, that sort of thing. Simple prompts. “Write me an email about scheduling challenges.” “Summarize this transcript.” Basic stuff.
And it was fine. Good, even. Saved me time.
But here’s what happened next, and I want you to pay attention because this is the opposite of everything I just described about every other system I’ve ever built.
I started adding complexity.
Not because I’m a masochist. Because the AI could handle it. I gave it more context about my methodology, and the output got better. I gave it my voice patterns, my vocabulary, the specific way I talk about things, and it started sounding like me instead of a robot. I gave it my product registry with verified facts and stats, and it stopped making things up.
So I kept going. Every time I added a layer of sophistication, the output improved. Every time I made the instructions more detailed, more nuanced, more specific, it executed better. Not worse. Better.
That had literally never happened to me before. Not once in 30 years.
Every system I’ve ever built with humans went the other direction. Start ambitious, simplify when reality hits. Start with the ideal, strip it down to what people can actually follow.
But with agents, I kept building up.
One skill became five. Five became twenty. I built specialized agents that called on specific skills in specific sequences. I built critics that checked the agents’ work. I built orchestrators that coordinated the critics. I ended up with what I call “the Dorian Gray of system prompts.” Every time the AI did something I’d told it not to do, or didn’t do something I’d told it to do, I’d say: “We’ve had this conversation before. I don’t want to have it again. What do we need to add to make sure this never happens again?” And the instructions got longer, the role descriptions turned into personas, then I gave the personas frameworks and mental models, and I’m still going.
You know where I am right now? 173 skills. 33 agents. And the system keeps getting more complex, not less. Because every layer of complexity I add makes it perform better.
I actually have to ask the AI: “Okay, here’s what I’m trying to achieve. Which of the many skills or combination of skills should I use?” I built a system so sophisticated that I need AI to help me navigate it.
And here’s the part that made me laugh out loud when I realized it.
I have spent my entire career telling shop owners to simplify. Standardize. Design for the weakest link. And the first time in my life I had an execution engine that didn’t need me to dumb things down, I went in the exact opposite direction. Instinctively. Without anyone telling me to. Because that’s the direction the work always wanted to go. I just never had an execution model that could sustain it.
Practical meant compromised. I just couldn’t see it.
Your Job Shop Has the Same Problem
Now here’s why I’m telling you this. Because I taught this pattern for years. And every shop that got it, every one that saw the difference between practical and possible, hit the same wall: they could see it, but they couldn’t sustain it at scale. Not with human execution. Not with the tools they had.
Think about your scheduling process. Be honest about it for a minute. How many factors does your scheduler actually hold in their head when they’re deciding what to run next? Buffer penetration? Customer tier? Setup family? Tooling availability? Full-kit status? Work center queue depth? Operator capability match?
Most schedulers, even the great ones, work with maybe five or six of those at the same time. Not because the other factors don’t matter. Because the human brain can’t juggle them all on 200 open orders while the phone is ringing about a late job.
So you simplify. You flatten. You go from eight priority factors down to three: the hot list, whoever’s screaming loudest, and due dates. And every factor you dropped is a factor that’s still affecting your job shop scheduling. You just stopped managing it. That’s process simplification in job shops at its worst: not fewer steps, just fewer factors considered.
That gap between what you’re managing and what’s actually affecting your throughput? That’s the cost of choosing practical over possible. And it shows up as late deliveries, rework, expediting, and margin you never capture.
Tanya lived exactly this. Thirty employees, precision machining, 59 years in business. They were good. Not great. Never better than 70% on-time delivery. And not for lack of trying.
“We were beating on our own people to be better, more efficient,” she told me, “but the more complicated jobs and more variables we were adding, the harder it was to get things done. It was becoming unmanageable.”
That’s the practical version talking. Too many variables for humans to manage, so you simplify until it’s survivable.
When they implemented VSS, the system changed what they focused on. Same people, same machines, same jobs. Different rules. On-time delivery went from below 50% to consistently between 90 and 100. Lead time dropped from 10.9 days to 4.8. And Tanya’s dad, the tough old-school CEO who bet real money it wouldn’t work? He lost that bet.
“It was all the same people just changing their focus.”
That’s what happens when the system stops requiring humans to hold all the variables in their heads.
Different industry, different size, different problems. Same pattern. The shops that run 15 people and the shops that run 150 hit the same ceiling for the same reason.
But here’s what VSS alone still requires: humans following the system. Every day. Every shift. Without drift.
And that’s where the next wall shows up.
Why We Built iVSS
And if you’re thinking “I’ve tried software before,” I know. Most of these shops had too. ERP scheduling modules that promised optimization and delivered a prettier version of the same broken logic. Add-ons that bolted AI onto rules that guaranteed failure. The problem was never the technology. The problem was that every tool tried to automate the practical version, the dumbed-down version, the one you’d already compromised. Nobody asked what the possible version was supposed to look like.
I wrote about this a while back. I had a VSS alumni have his employees take a 32-question VSS quiz. They all passed. Perfect scores. Knew every concept, every rule, every reason behind the rules. And his shop was still drifting. Not because they didn’t understand. Because understanding and executing under pressure are two different things. Even perfect knowledge doesn’t guarantee compliance when you’re behind on three jobs, the phone won’t stop, and your best operator just called in sick.
That’s why we built iVSS.
The results across 550+ shops: 198% mean productivity increase, 42% on-time delivery improvement, 87% WIP reduction. Those numbers come from a 2021 study of 442 shops. Not theory. Not projections. Exposed capacity in real shops with real jobs.
Here’s how.
The Velocitizer™ continuously adjusts flow based on what’s actually happening on your floor right now. Not the schedule from this morning. Not what the ERP thinks should happen. What is happening, minute to minute. It holds every factor simultaneously. Due dates, setup families, machine capabilities, queue depth, operator skills, full-kit status. All of them. Every time. No fatigue. No drift. Nobody has to play cop to make sure it happens.
And the Correlizer™ runs in the background learning your shop. Finding correlations your best scheduler would find if she had 40 hours a week, three years of clean data, and nothing else to do. She doesn’t. The software does. She uses her freed-up judgment on the problems worth thinking about.
Your team stops fighting the system because the system makes the right decision the easy decision. Easier to comply than not. They don’t revert to old habits because the software won’t let them.
Implementation takes days, not months. Most shops start seeing the shift around week five.
VSS+iVSS comes with a guarantee: 30% flow increase in the first 90 days or a full refund. Cancel anytime after that.
Every process in your shop has a ceiling version you had to strip down because humans couldn’t sustain it. What if you could put those steps back?
Goldratt was right that inherent simplicity exists. Every system has a few leverage points that govern everything. He was right that you need deep understanding to find them. Where he was wrong was assuming the execution had to be simple too. He simplified because humans had to run it. That was the only option he had.
It’s not the only option you have.
If you want to see what the possible version of your shop looks like, let’s talk.
Strategy Session – velocityschedulingsystem.com/contact
Lisa
P.S. Goldratt would have loved this argument. Deep understanding of the system, plus an execution model that doesn’t force you to dumb it down. That’s not anti-simplicity. That’s simplicity completed.
