Why most continuous improvement programs don’t stick

Most continuous improvement programs don’t fail because the methods are wrong. Lean, Six Sigma, and operational excellence (OPEX) principles are well established. Instead, the programs fail because they are designed as initiatives rather than as operating systems.

That distinction matters. While initiatives rely on sponsorship, cadence, and attention, operating systems rely on defaults, incentives, and habits. When executive focus or business priorities shift (as inevitably happens) initiatives decay. Operating systems persist.

Join the PEX Network community

Don't miss any news, updates or insider tips from PEX Network by getting them delivered to your inbox. Sign up to our newsletter and join our community of experts. 

Learn More

The structural fragility of top-down continuous improvement

Traditional continuous improvement programs follow a familiar pattern. Senior leadership defines a methodology, launches it with visible sponsorship, certifies practitioners, and tracks adoption through periodic reviews. Early results are often positive. Participation is high, metrics improve, and a key project or two lands. Then, quietly, the system weakens.

The failure is structural. Top-down continuous improvement assumes that improvement is something people opt into rather than something embedded in how work gets done. Teams are asked to step out of their core responsibilities to ‘do continuous improvement,’ often through workshops, Kaizen events, or formal projects. Improvement becomes an additional task, not part of daily execution.

This design creates three predictable problems. First, improvement competes with delivery under pressure, and delivery always wins. Second, accountability is diffuse: leaders sponsor, experts facilitate, teams participate, but no one owns improvement as a daily obligation. Third, the system depends on sustained executive attention, which is a scarce and volatile resource.

When sponsorship fades, the habits fade with it. I’ve experienced that firsthand.

A contrast case: When intent isn’t enough

In my Microsoft days I was a manager who participated in a big CIO-driven Six Sigma rollout. The program had strong leadership intent, clear standards, and broad communication. Teams were trained. Audits were conducted. Early traction looked promising.

However, Six Sigma remained an overlay on top of existing work rather than a redesign of how work was planned and executed. Managers were accountable for outcomes, not for maintaining the system. Teams treated audits as events, not as signals. New executives came in, and over time, focus drifted. Not because people disagreed with Six Sigma, but because the rollout didn’t change the operating model.

The lesson is not that Six Sigma or similar frameworks are flawed. It is that methods cannot compensate for weak structural integration.

Register for All Access: Future of BPM 2026!

Continuous improvement becomes part of the operating DNA in an Amazon division

Early in my Amazon tenure I created an organization-level continuous improvement program with one objective: embed continuous improvement into the team’s DNA. What should that look like?

First, I had an allergic reaction to the idea of training mandates. By luck I had a couple good continuous improvement practitioners on the team, and instead of immediately training people (approximately 200 total employees at the time), I worked with them to set up a project identification, prioritization, approval, and tracking program. Simple at first – name of the project, what the project would fix, and level of complexity to execute (‘Just Do It,’ a Kaizen, or a more complex project).

The two continuous improvement people and my most senior direct report approved projects (so that individuals couldn’t game the rewards system by submitting junk ideas). This also provided real-time learning for the team on what to look for and how to make sure it was meaningful.

The launch was me communicating and incenting (via rewards and recognition) individuals identifying viable projects. At first the output metric was a count of projects, which gave us a strong traction signal with little opportunity for gaming. I was convinced that ‘embedding continuous improvement into the team’s DNA’ needed to involve creating the habit of continuous improvement, so incenting the behavior of finding project opportunities seemed on point.

As I wanted strong buy-in from my organization, I spent the time really convincing the leaders under me that this approach was the right one. It was also controversial with my VP and his peers, who vocally advocated for a monetary savings goal in year one. My push-back about creating habits (e.g. making it part of the operating system) won.

Did we train people? Absolutely. For most team members, training by my two continuous improvement practitioners was ‘just in time’ and focused on what each individual needed to know to execute their project. Yes, their project – whenever we could, the person who came up with the idea got to drive the improvement. That way they learned a skill right when they needed (e.g. how to do a Kaizen), then they got to immediately practice the skill.

Just Do It projects were super simple (e.g. run an experiment with a streamlined manual SOP) and could produce results in days. Other projects took more time. We did track the productivity results, but we set goals on project volume and rewarded the same in the first year.

In the fifth year after establishing the program, it produced $1.7 million in finance-verified productivity gains and executed 691 total projects (all sizes), which was >1 project per employee. The mix shifted from mostly Just Do It projects in the first year to 39 percent Kaizens and 10 percent higher-complexity efforts. 

Design choices: Which ones created durability

A handful of the design choices were most important in driving results.

• Incentives over intent: Incenting people to see the potential improvement and then say something (i.e. submit the idea) was critical in habit formation.
• Sequencing before scale: In hindsight, the way we sequenced was very Six Sigma and also very Amazonian – we focused on controllable inputs (number of viable projects) versus outputs ($ saved).
• Defaults over discipline: Creating the habit made seeing and thinking in continuous improvement terms a default behavior, not something where management pressure was needed.
• Clarity in place of control: Teams do not need constant oversight. They need unambiguous definitions of success, failure, and ownership, which our program’s measurement system provided.
• Anticipate versus react: One example was the ‘finance verified savings.’ I anticipated continuous argument over how ‘real’ the productivity gains were, so I worked with the finance team who supported my organization on a quantification methodology. Use their template? Results verified, no argument or drama (but some audit of course).

None of these choices requires sophisticated tooling – Excel, Sharepoint, etc. were more than sufficient. In fact, tooling often obscures weak design by creating the illusion of progress.

Leadership’s real role

The leader’s job in continuous improvement is not to champion the program. It is to provide and reinforce clarity. When improvement is clearly owned, clearly triggered, and clearly tied to consequences, it persists without enthusiasm or reminders.

This distinction becomes even more important as artificial intelligence (AI) accelerates execution. Faster systems amplify structural weaknesses. If improvement depends on human attention and goodwill, AI will expose that fragility quickly. If improvement is built into the operating model, AI becomes an accelerant rather than a risk.

The bottom line

Continuous improvement sticks when it stops being an initiative and starts being infrastructure. Most organizations already know what to improve. The harder question is whether they are willing to redesign how work actually runs so improvement becomes unavoidable. That is not a cultural challenge. It is a design choice.

All Access: Future of BPM 2026

You asked, and we listened. Business process management (BPM) remains the cornerstone technology for driving organizational transformation, according to the survey results featured in the latest PEX Report. As we look toward 2026 and beyond, generative AI, agentic AI, and intelligent process orchestration are redefining how processes are designed, executed, and optimized. BPM is your key to adapting swiftly and effectively in this new era.

PEX Network is bringing together industry leaders, technology innovators, and thought leaders to answer your biggest questions and explore the advancements reshaping business today. And you're invited. Register for free to save your spot now! 

Register Now