Why Continuous Improvement Fails: The Loop Nobody Closes

Last week ended on a promise: the return leg. What a team does with the distance between what it shipped and what it meant to ship.

Every operation has that distance. You released something at the standard you set, and you knew at the time it was not everything you wanted. The list of what it still does not do exists, whether or not anybody wrote it down.

Closing that distance is a different discipline from deciding to release. That is this week, and it completes the trio.

Chapter four of The Resilience Engine calls them the Improvement Triad. Three frameworks that only work together. Two weeks ago, Kaizen and SMART Goals, cadence pointed at a destination. Last week, SMART Goals and Wabi-Sabi, a defined standard paired with the latitude to release at it. This week is the last pairing and the one that turns the whole thing into a loop: Kaizen and Wabi-Sabi. Frameworks 11 and 13.

The mechanism

Three parts. The third one is where most operations get it backwards, and I was one of them for years.

The first is ownership.

An improvement that arrives finished has nobody attached to it. An improvement that arrives rough has somebody attached to it, because whoever made it rough is the only person who knows what it still needs.

The book is direct about where implementation belongs. Not with managers. Not with outside consultants. With the people closest to the work, who hold both the authority and the responsibility to test changes in their own domain. Kaizen begins at the gemba, the actual place the work happens, on the premise that the person doing the job has information no external expert can reach.

That premise is not a compliment to the workforce. It is a claim about where information physically lives.

The second is latitude.

Wabi-Sabi is the acceptance that a thing can be worth having while it is still incomplete. Read as an aesthetic it is useless here. What it does in an operation is make a rough first attempt releasable at all. Without it, the only change that clears the bar is the fully worked one, and the fully worked one almost always comes from an engineer, because engineers are the ones with time to work it fully.

Take away the latitude and you have not raised your standards. You have quietly reassigned who is allowed to improve anything.

The third is direction, and this is the one I had wrong.

For years I ran continuous improvement in plants where engineers were assigned to lead it. That is the default nearly everywhere, and it produces real results while the engineer is there.

An engineer aimed at management is irreplaceable. Somebody has to assemble scattered savings into a case a budget holder will actually approve. No operator has the standing or the sightline to do that. Remove the function and the improvement system runs out of money inside two quarters.

The same engineer aimed at the workstation becomes a queue. Findings travel to him, wait for his attention, travel back. That is transit, not incompetence, and transit is expensive here. Kaizen puts a ceiling on the whole cycle: two to four weeks from identifying a problem to standardizing the answer. Past a month, the book's own verdict is that you are running traditional change management with better vocabulary. An engineer who visits cannot stay under that ceiling regardless of how good he is, because the constraint is his calendar and not his judgment.

Same person. Same competence. The direction he is pointed decides whether the loop turns.

Why each rail fails alone

Run Kaizen without the latitude and you get a suggestion box. The machinery exists, the meetings happen, and the input never arrives, because the only ideas that clear the bar are the ones already finished, and finished ideas do not come from people who are busy doing the work.

Run the latitude without Kaizen and you get one round of change and nothing after it. Something rough goes out, everyone agrees it will get better, and there is no cycle scheduled to make it better. The team notices. The next time somebody says try it and we will improve it, nobody believes them.

Run both without closing the loop and you get the failure I lived with longest.

We ran a visual priority system on healthcare product orders. Expedited orders were tagged red so anyone could see at a glance what had to move first. It was a good control and it solved a real problem the day it went in.

Then red spread. More orders qualified, then more, until a scheduler could look at the queue and see almost nothing else. The control was still functioning exactly as designed. It had simply stopped carrying information, because a marker that applies to everything separates nothing.

The obvious response was to tighten the criteria. We did some of that. It bought a few weeks.

What ended that approach was a planner. She said we could not keep doing the same thing, that we had to go back and find what was actually driving these. I said the way back was root cause, one expedite at a time. She was right that the tightening was the wrong direction and I would have kept going in it.

So we stopped managing the expedites and started tracing where they originated, one at a time, refusing to accept the first explanation. They were not random, and they had nothing to do with how anything was being produced. They clustered around commercial events nobody had connected to the schedule: new accounts coming on, product placements landing, additions to existing accounts. That information existed. It sat with the sales team and had never been connected to anything the operation could see.

The priority system had not broken. It had collided with something already failing three departments away, in a function nobody had thought to look at.

Which is the return leg. The change that does not work is the one that tells you where to go next, provided somebody goes.

The part nobody builds

Here is the problem that shows up once the loop is actually running at the workstation.

You cannot see it.

Work improved at the source leaves no record. A step gets resequenced. A recurring task quietly stops. Nobody responsible classifies any of it as an initiative, so none of it enters the reporting stream. What does enter is whatever happened to fit a template, and that is a smaller category and generally a more fragile one.

Your instrument therefore over-reads what was easy to write up and under-reads what actually holds. Nothing can be amplified while it stays invisible.

That is where the gemba walk stops being a manufacturing ritual and becomes a measurement instrument. This has nothing to do with oversight, or with visibility for its own sake. Going to the place where the work happens is the only method that captures the improvements your reporting was never built to see. You are not asking how the numbers look. You are asking how the result is being obtained, in enough detail that you could reproduce it somewhere else.

Two weeks ago the subject was connecting people's metrics so each function could trace its own effect on the others. Call that sight aimed outward: the team perceives the operation. What I am describing now is sight aimed inward. You perceive the team.

Same failure, mirrored. Most operations build neither.

Running the loop

One move this week.

Pick your best-performing area. Not the one in trouble. The one that is working, where the numbers are quietly good and nobody is asking questions because nothing is on fire.

Go there. Spend an hour. Ask one thing, in this form: show me how this actually gets done. The sequence, step by step, from the people running it.

You are looking for the changes nobody reported. They will be small enough that whoever made them will be surprised you asked, and that surprise is the signal. Then find out which of those changes would work in three other places and put them there.

That is the whole loop. Somebody improves something where the work is. You go find it. It gets repeated somewhere else. Nothing about it requires a program, a steering committee, or a transformation office.

Where Act II goes next

Act II has been assembling one claim: structure beats charisma. Stacks, links, and loops, each of them a way of making a system hold without a person standing there holding it. This week the loop learns to close, which is what makes it a loop instead of a line.

The distance between what you released and what you meant to release is the agenda for the next cycle. But only if somebody owns the thing, has the latitude to change it, and is standing close enough to it to notice.

That is the last of the Improvement Triad. Act III starts next week, and it moves from how a team improves to what an operation is for.

Oscar

Want to see whether your team's improvement loop actually closes? The Resilience Engine Systems Audit maps it: myresilienceengine.com/systems-audit