The CI Paradox

Something I’ve been pondering for a while: the more organisations try to manage continuous improvement through programs, the less continuous improvement actually happens.

Not because people aren’t trying. But because the moment improvement is structured as a program, it gets separated from the work itself. And once that separation happens, it’s very hard to undo.

Why organisations create CI programs

It’s not an unreasonable instinct. Leaders want visibility of whether improvement is happening. Governance structures are built around projects, they’re easier to fund, report on, and hold someone accountable for. CI accountability gaps are real and need attention. When something is a priority, organisations resource it.

So a CI team gets formed and programs begin.

The paradox emerging

Continuous improvement is supposed to be continuous. The word is right there. But a program, by definition, has scope, milestones and an end date. Continuous improvement doesn’t.

When you create a CI team, you send an unconscious signal: improvement is their job. CI sits in that team over there. Everyone else just does their usual work. Problems get escalated rather than solved by the people who encounter them every day. Teams stop looking for better ways of working because that’s not their role anymore.

This is the ownership paradox. The more organisations centralise improvement, the less teams feel responsible for improving. The natural human instinct to get better at things, which is genuinely how people operate when the conditions allow. But outsource the improvement, and you outsource the instinct with it.

That doesn’t mean CI teams shouldn’t exist. They can be incredibly valuable in building capability, introducing methods, and helping teams solve harder problems. But when they become the owners of improvement, the people doing the work stop improving it themselves.

CI is a behaviour, not a program

Before an organisation can embed CI properly, it needs to get clear on what it actually means. Not in the abstract. Practically. What does improving look like in the team, doing the work, serving these customers?

At its core, CI is the ongoing effort to close the gap between how work is done and how it could be done so customers get a better, faster, less frustrating outcome.

CI is what teams do to improve their own work. It might mean changing a process, removing a step that creates rework, or fixing a handover that keeps breaking down. The scale is local: the people doing the work see the problem and fix it.

On the other hand - a project is what you need when the change is bigger than any one team can own. It spans functions, requires significant investment, or needs someone to coordinate what the team can't do alone.

The line between them isn't always clean. But the useful question is: can the team identify this problem and change it themselves (even if the capability doesn’t exist yet)? If yes, that's CI. If the answer is no, that's when a project might make more sense.

So why does local CI keep ending up in a central team?

Most organisations don’t lack improvement initiatives. They lack systems that allow teams to improve their own work. Teams don’t have visibility of how the work is actually going. There’s no rhythm for reflection built into how they operate. And there’s no clear authority to change anything without escalating.

When CI becomes a priority and none of those conditions exist, a central team feels like the only option. It isn’t. But it’s the natural outcome of a system that was never designed for local improvement.

The system determines whether improvement happens. Not the methodology. Not the team created to own it. If the conditions don't exist for teams to improve their own work, they won't — regardless of how committed the organisation is to the idea.

Think about how improvement works when the conditions are right. A contact centre team reviews yesterday's errors every morning — what broke and forced customers to call, what do we do differently today? There is no program, no steering committee, no outside influences to get in the way. Just a team with good data, a regular conversation, and the authority to adjust.

A real example of this - Zara built a competitive advantage on the same principle. Improvement wasn't managed by a dedicated team. It was built into how every team operated. Store feedback flowed directly to designers, and new products moved from concept to store in weeks. It was a system designed to improve as it ran.

Three conditions for CI to happen naturally

The objection I hear most often is: “without structure, CI will never happen. We’re too busy. We don’t have the capability.” It’s a fair challenge. But it’s a problem with how the work is designed.

For CI to happen naturally, three conditions need to exist:

Visibility. Teams need to be able to see how their work is actually going. Not just whether outputs were delivered, but where the friction is, where things keep breaking down, where customers are getting stuck.

Rhythm. There needs to be a regular conversation. Even 5 minutes a week can make a difference. A consistent habit of reflection built into how the team operates.

Authority. People need to actually be able to change something when they spot a problem. If every fix has to go through a CI team, an approval process, or a steering committee, the instinct to improve dies quickly. Improvement has to be something people are trusted to do.

These aren’t radical conditions. Most teams could have all three with a few small changes.

When improvement should be a project

Some improvement genuinely needs project structure. Change spans multiple teams, requires significant investment, or is too complex for any one team to own alone.

And if your CI program has been running for years, it's worth asking: is it still improving things, or has it become part of the norm? Programs are built to solve the problems of the moment they were created. If they're still running with the same scope years later, they're probably not improving the organisation anymore. They're maintaining it.

The real role of transformation functions

Continuous improvement isn’t something you run. It’s something you design the organisation to do naturally.

That reframes what transformation functions are actually for. The question isn't "how do we run improvement initiatives?" It's "what needs to be true for teams to improve continuously without us?" That's a harder question. And a much more interesting one to solve.

If you'd like to pressure test how CI is working in your organisation, let’s connect.