What continuous improvement champions actually do

A champions network is not a committee. It is a way of putting improvement capability where the problems actually are.

Part of my current role is coordinating continuous improvement champions across different functions and regions. When I describe this, people often hear committee, and assume meetings. That is not what it is, and where it is treated that way it stops working almost immediately.

The problem it solves

A central improvement team has an obvious limitation: it is not in the room when the problem happens. By the time an issue reaches a specialist, it has been summarised, and the summary has already lost most of what made it interesting.

Champions are people embedded in their own function who have the method and the mandate to notice things. They are not full-time improvement staff. They are people doing the actual work who have been given a way to act on what they see.

What they are good at that I am not

A champion knows the informal process. They know which step everyone quietly skips at month end, which approval is a formality, which system the team stopped trusting two years ago and now works around. None of this appears in documentation, and none of it is offered to a visiting specialist in the first meeting.

They also carry credibility that I cannot manufacture. A change proposed by someone who does the work lands differently from the same change proposed by a central function. It reads as improvement rather than as an initiative.

A change proposed by someone who does the work is improvement. The same change proposed centrally is an initiative. The word people use tells you whether it will survive.

What makes it fail

• No time. If champion work is expected on top of a full workload with no protection, it becomes the thing that slips every week.
• No visible outcome. If the first few improvements go into a backlog and nothing happens, the network learns that raising things is pointless, and it stops.
• Method without support. Sending people on training and then leaving them to it produces frustration. The method is the easy part; applying it inside a live function with competing priorities is not.
• Treating it as reporting. The moment it becomes a status update exercise, the honest information disappears.

What my job actually is

Mostly it is removing obstacles and closing loops. Making sure something raised gets an answer, even when the answer is no with a reason. Providing method support when someone is midway through mapping a process and stuck. Connecting two people in different regions who are solving the same problem separately, which happens more often than anyone expects.

The measure I care about is not how many improvements were logged. It is whether people still bring things forward six months in. That number tells you whether the network is real or whether it has become a form.