Week 15: Your Dedicated CI Team Might Be the Reason CI Isn't Working
Your Dedicated CI Team Might Be the Reason CI Isn't Working
This is going to upset some people.
Particularly people who work in CI teams. I know, because I have been one of those people. I have led CI teams. I have built CI teams. I have recruited for CI teams. I have defended CI teams in budget meetings when finance wanted to cut them.
And after 20+ years and more than 40 organisations, I have come to a conclusion that I find genuinely uncomfortable.
In many organisations, the CI team is the single biggest barrier to CI becoming a culture.
Not because they are bad at their jobs. Often the opposite -- they are excellent. Technically skilled. Passionate about improvement. Committed to results.
But their very existence sends a message to the rest of the organisation that is devastating to improvement culture: "Improvement is their job. Not mine."
The Outsourcing Problem
Think about what happens when you create a dedicated CI team.
You hire four or five people with Lean Six Sigma expertise. You give them a mandate: drive continuous improvement across the organisation. You give them a budget, a reporting line, and a set of targets.
They get to work. They identify improvement opportunities. They run projects. They facilitate workshops. They deliver results. The dashboard looks good. The business case shows ROI on the team.
And absolutely nobody else in the organisation is improving anything.
Because why would they? There is a team for that. CI has been outsourced to a department. Just like IT handles the technology. Just like HR handles the people issues. Just like finance handles the numbers. CI handles the improvement. Everyone else handles "the real work."
I saw this pattern play out with shocking consistency. At a manufacturing site, I asked a production supervisor what improvement projects his team was working on. He looked at me blankly. "You need to talk to the CI team about that."
His team. His process. His daily frustrations with waste, rework, and inefficiency. And he had mentally outsourced ownership of improving all of it to four people in an office upstairs.
That is not a CI culture. That is a CI service department. And it is a model that will never -- never -- produce the kind of widespread, embedded, self-sustaining improvement that transforms an organisation.
The Numbers Tell the Story
Let me give you the mathematics.
A typical CI team has four to six people. A typical organisation has hundreds or thousands of employees. Even the most productive CI team can run maybe 15 to 20 structured improvement projects per year. Each project might take three to six months.
Now consider the alternative. If every team -- every production team, every office team, every maintenance team, every customer service team -- had one active improvement going at any time, how many improvements would that be? In a company with 50 teams, that is 50 improvements running simultaneously. In a company with 200 teams, that is 200.
The CI team delivers 15. The organisation, if enabled, delivers 200.
That is the scale difference between a CI team model and a CI culture model. And it is why the most impactful CI programmes I have ever been involved with -- including the Shell deployment across 12,000 FTEs -- were built on embedding capability in every team, not concentrating it in a department.
At Shell, we did not build a large central CI team. We built CI capability into the operating rhythm of every team at every level. Daily stand-ups owned by the team. Weekly improvement reviews owned by the team. Monthly performance reviews owned by the leaders. The CI professionals existed as coaches and enablers, not as the people who did the improving.
The difference in output was orders of magnitude. Not 10% more improvement. Ten times more improvement. Because when every team is improving, the aggregate impact dwarfs anything a small dedicated team could produce.
The Dependency Trap
Here is the other problem with dedicated CI teams that nobody talks about.
They create dependency.
When the CI team facilitates every improvement, the organisation never learns to improve independently. When the CI team runs every root cause analysis, the operators never develop the skill. When the CI team builds every process map, the team leaders never learn how to see their own process.
The CI team becomes a bottleneck. Not of capacity -- though that happens too -- but of capability. The capability lives in the CI team and nowhere else. If the CI team is busy, improvement waits. If the CI team is disbanded -- which happens in every budget cycle -- improvement stops entirely.
I have seen this happen at least ten times. An organisation builds a CI team. The team delivers excellent results for two to three years. Then a budget cut comes. Or a reorganisation. Or a new CEO with different priorities. The CI team is reduced or eliminated.
And improvement stops. Completely. Because nobody else knew how to do it. The capability walked out the door with the CI team.
Compare that to an organisation where CI capability is embedded in every team. If one person leaves, the team still knows how to run a stand-up, update a visual board, do a root cause analysis, and implement a countermeasure. The capability is distributed, not concentrated. It survives personnel changes, budget cycles, and reorganisations.
The Coach, Not the Player
I am not saying CI expertise should not exist. It should. Deeply.
What I am saying is that the role of CI expertise should be coaching, not doing.
The CI professional's job should be to build the capability of others, not to deliver improvement themselves. To teach teams how to do root cause analysis, not to do root cause analysis for them. To coach leaders on how to run an effective improvement review, not to run the review themselves. To design the operating rhythm and the capability building plan, not to be the person standing at every board, facilitating every workshop, and writing every A3.
The best CI professionals I have ever worked with measured their success not by the projects they delivered, but by the projects they did not need to be involved in. Their goal was to make themselves unnecessary to the daily improvement effort. To build capability so deep and so wide that every team could identify, investigate, and solve problems independently.
At Johnson Controls, I restructured the CI function across EMEA and Latin America from a delivery model to a coaching model. Instead of CI specialists running projects for the business, they coached business teams to run their own projects. The transition was painful. Slower at first. Messier. Less controlled.
But within twelve months, the volume of improvement activity had tripled. Because it was no longer limited to the bandwidth of the CI team. Every team was capable of running its own improvement, with CI coaches available for support on complex problems.
The CI team's project count went down. The organisation's improvement output went through the roof.
The Disband Principle
Here is the principle I now teach, and it makes CI professionals deeply uncomfortable.
The measure of a successful CI team is how quickly it can disband.
Not because CI does not matter. Because CI has been successfully embedded. The capability has been transferred. The operating rhythm is established. The culture of improvement is self-sustaining. And the dedicated CI team is no longer needed because improvement is now everyone's job.
I know how that sounds to someone whose career is "CI professional." It sounds like I am arguing for their elimination. I am not. I am arguing for their evolution. From doers to coaches. From a permanent department to a capability-building function that works towards its own obsolescence.
The best CI professionals I know have embraced this. They understand that their value is not in running projects. Their value is in building organisations that can run their own projects. And that is a much more challenging, much more impactful, and much more rewarding role than being the person with the Lean toolkit who gets called when something is broken.
What to Do Instead
If you currently have a dedicated CI team, here is the transition path I recommend based on what I have seen work.
Phase one: Shift from delivery to co-delivery. The CI team runs projects alongside business teams, not for them. Joint ownership. Joint accountability. The business team learns by doing, with expert support.
Phase two: Shift from co-delivery to coaching. The CI team coaches business teams who now run their own projects. The CI professional attends reviews, asks questions, provides guidance -- but the team does the work. Owns the work.
Phase three: Shift from coaching to on-demand support. Teams run their own improvements independently. The CI professional is available for complex problems, capability building for new team members, and continuous development of the operating rhythm. But they are not embedded in daily improvement activity.
Phase four: Embed and evolve. CI capability is part of every role. The CI "team" has evolved into a capability development function that ensures new joiners learn the improvement methodology, the operating rhythm continues to mature, and advanced capability is available for the most complex challenges.
This transition takes 18 to 24 months in most organisations. It is not fast. But it is permanent. And permanent beats fast every single time.
Here is the uncomfortable question: if your CI team disappeared tomorrow, would improvement continue? If the answer is no, your CI team has not built a culture. It has built a dependency. And dependencies, eventually, always get cut.
Start building CI capability in every role, not just a department. The Stormholt 30-Day Improvement Starter Guide gives every team the tools to begin improving independently.
https://stormholt.org/products/stormholt-30-day-improvement-starter-guide