Every continuous improvement professional has heard some version of the same complaint.

"We ran a great kaizen event. We came back ninety days later, and people were doing the work the old way again. Why can't we get improvements to stick?"

The instinct is to call this backsliding. Something good happened; the organization slid back from it. The conventional response is to talk about sustainment plans, accountability mechanisms, more discipline.

After more than a decade of being pulled into organizations to figure out why improvement work isn't holding, I think the conventional framing has it wrong. A lot of what gets called backsliding is something else. The change was never actually adopted. There was nothing to slide back from.

This distinction matters, because the two problems have different fixes. Treat an adoption failure as a sustainment problem and you'll spend your energy on the wrong countermeasures. The same thing will happen after the next event.

What a failed handoff actually looks like

The pattern is familiar. A cross-functional team is assembled for a kaizen event. They spend three to five days mapping the current state, identifying waste, designing a new process, and ideally testing some piece of it during the event. They produce a future-state process, write up the documentation, and present results on the last day.

Then everyone goes back to their regular work.

The people who run that process every day -- the nurses, the operators, the technicians, the analysts -- now have a new way to do something. They weren't in the room when it was designed. Maybe they got an email. Maybe they attended a fifteen-minute training session before go-live.

The event team moves on. The supervisor who was in the room is back to running her unit with twenty other things on her plate. The frontline workers, who were never really brought into the change, default to the way they've always done the work. Not out of resistance. Out of the simple fact that the new process never landed in their hands as something theirs.

Come back ninety days later, and you see what looks like the old method. You conclude that the improvement didn't sustain. But there's a question worth asking first.

Did the change actually get adopted in the first place?

In most of the cases I've looked at carefully, the honest answer is no. What happened wasn't drift. The new process was never running in the first place, except inside the kaizen event report.

Why the framing matters

Label this as backsliding and your countermeasures point at the wrong target. You'll build audit checklists. You'll ask supervisors to enforce the new standard. You'll set up monthly reviews to check whether people are following the process. You'll get better at catching deviations.

None of that fixes the actual problem, which is that the people doing the work were never genuinely part of designing the change. The new process was handed to them as an artifact from a closed event, and the predictable thing happened. They didn't take ownership of something they hadn't shaped.

Label it as a failed handoff, and you point at a different set of countermeasures. You change who's in the kaizen event. You change what happens in the days after the event. You change how the new process gets introduced. You stop treating the kaizen event as a moment when improvement gets manufactured and start treating it as the start of a longer cycle of testing and adoption.

The difference between these two approaches is the difference between an improvement program that compounds and one that produces a long series of events whose results never quite hold.

What handoffs that work look like

I've seen handoffs done well, and they share a few features.

The people who run the process every day are in the room during the event. Not as interviewees pulled in for an hour, but as participants. They design the change alongside the engineers, supervisors, and CI specialists. When the event ends, the change is already partly theirs.

The event tests the change on a small scale during the week. Not in theory, not on a future-state map, but as an actual pilot, with the actual people, in the actual workspace. By the last day, the team has real experience running the new method. The handoff has already started.

There's a clear, named owner for the days and weeks after the event. Not "the team." A person. Usually the local leader whose work touches the changed process most directly. That person knows their job for the next ninety days, and they have access to support from the event team or the CI office during that period.

The supervisor's role shifts from enforcement to coaching. This is where my co-founder Greg Jacobson and I have ended up in a slightly different place than most of the CI literature. The standard advice is that supervisors should "hold people accountable" to the new standard. Greg's framing is that what looks like deviation often isn't. He calls himself "the agitator" inside KaiNexus -- the person who slows the team down to ask whether they're about to revert to the old comfortable model. The role isn't enforcement. It's catching the drift before it hardens, with curiosity rather than correction.

That same posture works on the floor. When a supervisor sees what looks like a deviation from the new method, the first move should be a question. "I notice this looks different from what we agreed on. Help me understand what's happening." Sometimes the answer surfaces a real barrier worth fixing. Sometimes the person is running a small improvement experiment of their own. Sometimes the standard needs to evolve because the original design missed something. None of those situations is well-served by a supervisor walking the floor with a clipboard.

There's a real distinction worth holding here, too: "I cannot do it that way" and "I will not do it that way" are different problems. Cannot means barriers, which can be removed. Will not means a choice, which requires coaching, not authority. The authoritarian path -- do it this way because I'm in charge -- just teaches people to get better at hiding how they're actually doing the work.

The follow-up nobody schedules

The other piece organizations skip is the part that comes after the supervisor's coaching. Improvements need a structured follow-up rhythm, and that rhythm has to be planned at the event itself, not improvised afterward. Thirty days, sixty days, ninety days, with named owners and a defined check-in. The kaizen event isn't really over until those check-ins have happened.

Greg has made this point more directly than I have. The reason most kaizen event improvements get lost isn't because anyone meant for them to fail. It's that the team didn't have a shared way to keep the work visible after the event ended. By day thirty, people are deep in their other work. By day sixty, the documentation is buried. By day ninety, what's needed is a system that surfaces the improvement again, not a hope that someone will remember.

Whether that visibility comes from a platform or a physical board matters less than whether anyone is looking at the work two months later and asking how it's going. The discipline is what counts.

Stop calling it backsliding

The next time you walk into a unit ninety days after a kaizen event and see the old method, take a breath before you call it backsliding. Ask the people working the process what they're doing and why. Ask whether they ever really got the chance to make the new method theirs. Ask whether the handoff was a structured transition or just a hopeful one.

The answers will usually tell you the same thing. The change wasn't lost. It was never really there.

That's a different problem, and it has a different fix. Design improvement work as a multi-week process of testing and adoption, with the people who'll run the work in the room, supervisors coaching rather than enforcing, and a defined follow-up rhythm that doesn't depend on memory.

Improvements that are actually adopted don't need much sustainment. They sustain themselves because they belong to the people who do the work. That's the real definition of a continuous improvement culture, and it's the part no kaizen event audit can manufacture after the fact.

See KaiNexus in action and see how teams keep improvement work visible, owned, and moving long after the event ends.