By Dr. Lisa Lang, TOCICO Certified Expert and developer of the Velocity Scheduling System
Process simplification in job shops refers to reducing operational complexity – routing steps, setups, WIP, and decision points – to make flow more predictable and throughput easier to increase. Goldratt’s Inherent Simplicity principle holds that complex systems become simpler once you locate the constraint; the challenge is that standard simplification projects attack symptoms, not the system.
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 exact