Quick answer: A dedicated continuous improvement team that owns every improvement project creates a structural bottleneck. The fix is not to grow the team or eliminate it, but to transition it through four stages (delivery, co-delivery, coaching, on-demand support) over 18 to 24 months, measuring success by the number of improvements the team was never involved in.

The Ceiling Is Structural, Not Cultural

Ask a production supervisor what improvement their team is running. The answer, more often than not, is "you need to talk to the CI team about that." Their process. Their waste. Their rework. Mentally outsourced.

This is the core problem with a dedicated CI function: once a team owns improvement, everyone else stops owning it. The result is a ceiling on the total volume of improvement work the organisation can produce.

The arithmetic makes the cost visible. A five-person CI team runs 15 to 20 structured projects a year. Fifty teams each running one improvement run fifty at a time. Two hundred teams run two hundred. The gap between those numbers is not a performance issue. It is a design issue. You built a system where improvement scales with one team's headcount instead of the whole organisation's engagement.

What the Numbers Look Like When It Works

One deployment using a single weekly cadence meeting produced 1,662 improvement initiatives in two years. That is not a typo, and it was not a five-person team working weekends. It was the organisation itself, with 137 initiatives live in the first quarter and 392 by the fourth.

Not all of them worked. Roughly 10 to 15 percent never reached realisation. The team said that out loud, which is why people kept bringing ideas. Pretending every initiative succeeds is a faster route to disengagement than admitting some will fail. A 10 to 15 percent failure rate, openly acknowledged, sustained the pipeline far better than a polished dashboard showing only wins.

Compare that to the typical CI team output: 15 to 20 projects per year, each carefully scoped, sponsored, and gated. The centralised model produces higher-quality individual projects but radically fewer of them. And continuous improvement works because a steady stream of improvements, diligently executed, produces transformational results. Volume matters.

The Dependency Trap

There is a second failure mode beyond the bottleneck. When the CI team facilitates every root cause analysis, nobody else learns to do one. Budget cuts arrive. The team shrinks. Improvement stops entirely because the capability walked out with them.

This is the dependency trap. The organisation did not just outsource the work to the CI team. It outsourced the skill. When the team leaves, there is no residual ability to run an A3, facilitate a kaizen event, or structure a problem statement. The function disappears and nothing fills the gap.

The Failure Window: Months 12 to 24

If your CI programme is going to die, it will probably die between month 12 and month 24. That is when the cadence decays, the meeting slips, and the programme quietly stops while the org chart still shows a CI function.

Year one usually looks fine. There is executive attention, a launch, early wins. By month 14 or 15, the novelty has worn off. The weekly review becomes fortnightly, then monthly, then "we should really get that meeting back on the calendar." The CI team is still there. They are still busy. But the system around them has stopped moving.

This is worth watching for because the warning signs are subtle. Nobody announces that CI is over. The org chart does not change. The team keeps running projects. But the frontline has disengaged, and the pipeline of new ideas has dried up.

The Four-Stage Role Change

The fix is a role change, not a headcount change. Move the CI team through four stages over 18 to 24 months:

Stage 1: Delivery. The CI team runs projects end to end. This is where most teams start, and where most teams stay permanently. It builds credibility and demonstrates what good looks like. The mistake is treating this as the destination rather than the starting line.

Stage 2: Co-delivery. The CI team pairs with operational staff to run projects together. The CI practitioner still leads the methodology, but the operational partner owns the problem and the implementation. This is where skill transfer begins.

Stage 3: Coaching. Operational teams run their own projects. The CI team provides support when asked, reviews outputs, and helps with complex analytical methods. The SimplicityHub Academy covers the structured training that underpins this stage, from Green Belt to Black Belt and beyond.

Stage 4: On-demand support. The CI team handles organisation-wide strategic improvement, complex cross-functional problems, and methodology development. Day-to-day improvement belongs to the people who do the work.

The distinction between capability building and capacity building matters here. Capacity building expands the organisation's ability to handle more work through additional staff, equipment, or space. Capability building enhances effectiveness by equipping employees with the tools, skills, and knowledge essential for success. Growing the CI team is capacity building. Teaching the organisation to improve without the CI team is capability building.

What to Measure Instead of Project Count

Most CI teams report the number of projects completed, the financial benefits realised, and perhaps a pipeline of future projects. These metrics all measure the CI team's output. They tell you nothing about whether the organisation is learning to improve on its own.

The measure that matters is the number of projects the CI team was not needed on. When operational teams are running improvements without CI involvement, the coaching model is working. When every improvement still requires a CI facilitator, you have not built capability. You have built a queue.

Transparency helps here. Making goals visible and cascading them to all levels focuses frontline creativity on the problems that matter. One industrial client achieved a 20 percent productivity increase in less than two months by introducing transparent asset-utilisation tracking. The teams that used the assets instantly realised that low utilisation was a bigger problem than any of them had known, and the visibility alone focused their energy on solving it.

Track these alongside traditional CI metrics:

  • Number of frontline-led improvements (no CI involvement)
  • Percentage of supervisors who have led at least one structured improvement
  • Time from idea to implementation for frontline-initiated changes
  • Ratio of CI-led to independently-led projects (this should shift over time)

Why Frontline Involvement Produces Disproportionate Results

Frontline employees are closest to the work and typically have the richest insights on how it can be done better. This is not a motivational statement. It is a structural advantage. The person who runs a process eight hours a day sees friction that a CI practitioner visiting for a week-long kaizen event will miss.

The results bear this out. Cross-functional teams collocated in multi-week sprints achieved 80 percent-plus cycle time improvements. These teams worked together because no single function completely understood most problems end to end, but by sharing knowledge informally and formally, they found solutions that siloed teams could not.

One client cut product testing time by more than 80 percent through a large number of small changes to how its engineering and testing teams collaborated, saving ten weeks. Not one big re-engineering project. Many small adjustments to how two groups worked together, each one modest, the cumulative effect enormous.

This pattern shows up consistently across the process improvement tools that practitioners rely on. The tools work better in the hands of the people closest to the problem.

The Retention Argument

Capability building is not only a performance lever. It is a retention lever. Employees who feel that their development is a priority are more likely to be engaged, less likely to leave, and more likely to contribute positively to the organisation.

When a CI team runs every project on the frontline's behalf, it sends an unintentional message: your job is to execute, not to think. When a CI team coaches the frontline to run their own improvements, the message reverses. The role expands. The work becomes more interesting. People stay.

This matters especially in environments where experienced operators are hard to replace. Losing a veteran who understands every failure mode of a machine is a different problem from losing a graduate trainee. Building improvement skills into operational roles makes those roles more engaging and more valued, which makes the people in them harder to recruit away.

Where to Start

If your CI team currently owns improvement end to end, the transition does not start with an announcement. It starts with the next project.

Pick one. Pair a CI practitioner with an operational lead. Let the operational lead own the problem statement and the implementation plan. Let the CI practitioner coach the method. Run the project. Then do it again with a different operational lead.

The 18 to 24 month timeline is not arbitrary. It takes that long because you are changing habits, not org charts. The CI team needs to learn to coach instead of do. Operational leaders need to learn to own improvement instead of delegate it. Neither shift happens in a quarter.

Measure your progress by how often you are not needed. That is a strange metric for a team that wants to justify its existence, but it is the right one. A CI team that has made itself dispensable for routine improvement has done something far more valuable than completing 20 projects a year. It has built an organisation that improves itself.