Change champions can help a technology program translate between the intended design and the work people actually do. Their value comes from credible local knowledge, practical support, and a route for feedback to change decisions. Appointing enthusiastic employees and asking them to promote the system is a much narrower role, and often leaves the important problems unresolved.
For a transformation manager rolling out a collections-location system across a museum group, the decision is how to establish a champion network with enough time, access, and influence to be useful. Champions should complement operational management, formal support, and accountable design owners. They should not become unpaid substitutes for those functions.
This article develops a working model for selecting, supporting, and evaluating champions. The museum scenario is hypothetical. The recommendations do not assume that a champion network guarantees adoption or that every team needs the same arrangement.
Specify what champions are expected to do. A useful role may include demonstrating approved tasks, helping colleagues find guidance, gathering reproducible problems, explaining local context to the project, and testing proposed changes. Each activity should connect to a receiving owner or decision.
State what champions do not own. They should not approve policy exceptions outside their authority, repair production data informally, promise feature delivery, or carry responsibility for every colleague’s use. Those boundaries protect both the program and the employee taking the role.
Distinguish advocacy from feedback. Champions can explain why a change matters while also reporting that part of the design is unworkable. Requiring them to defend every project decision weakens their credibility with colleagues and deprives the project of useful evidence.
Write a short role agreement covering purpose, protected time, support route, decision access, confidentiality, and review date. The agreement should be realistic within the employee’s main job. A title without capacity is not an operating model.
Choose people who understand the work and can communicate respectfully with colleagues. Technical enthusiasm can help, but it is not sufficient. A highly skilled user who dismisses basic questions may be a poor local guide.
Map the relevant variation before selecting the network. Different locations, shifts, roles, languages, and accessibility needs may require different representation. One champion at head office may not understand the constraints of a remote store or an evening team.
Include constructive skeptics where appropriate. Someone who can explain a legitimate concern clearly may help the project improve more than someone who agrees with every proposal. The role should reward useful inquiry rather than loyalty to the launch message.
Confirm willingness and manager support. An employee should understand the expectations and have a realistic option to discuss the commitment. Their manager must agree which normal work will be reduced or covered; otherwise, the program has merely added another responsibility.
Imagine a hypothetical museum group introducing a shared system for recording where collection objects are held. The rollout affects storage staff, exhibition teams, and specialists who move objects for approved work. Existing local terminology and temporary-location practices vary across sites.
The project appoints champions from the relevant working groups, including a site with limited technical support. Their role is to help colleagues use the approved movement process and bring unclear cases back to the design team. They do not gain authority to bypass custody controls or alter object identity rules.
During practice, a champion notices that colleagues confuse a display label with the object’s authoritative accession identifier. Rather than correcting records informally, the champion captures a safe example, the task context, and the point of confusion. The issue reaches the data and interface owners.
Another champion identifies a temporary exhibition location that the standard training example does not cover. The process owner determines the correct treatment, and the training team updates the guidance. The champion then checks with local staff that the explanation works in practice.
The network also reveals a capacity problem. Colleagues repeatedly seek help during a period when the champion is assigned to another essential duty. The rollout manager and local manager adjust support coverage instead of treating the champion’s availability as unlimited.
The value lies in a closed feedback loop: local observation becomes an owned decision, the decision changes the system or guidance, and the result returns to the people affected. A list of named champions or a high attendance rate at meetings would not establish that the loop works.
Provide early exposure to the actual tasks, known limitations, and approved operating decisions. A champion who learns about a major change at the same time as everyone else cannot reliably explain its implications or prepare local support.
Use realistic practice environments and examples. Champions should experience common exceptions, correction, and escalation, not only the clean demonstration path. They need to know when to help directly and when to stop and involve a specialist.
Maintain a source of current guidance. If different champions keep private notes with conflicting instructions, the network can multiply variation. Give them a way to propose improvements while preserving an approved version that everyone can use.
NHS England’s Change Model Guide discusses leadership throughout an organization and the work of mobilizing people around change. Applying those ideas to enterprise champions is a design analogy, not evidence that a particular network will achieve a measured adoption result. NHS England, The Change Model Guide, 2018
Use a simple issue format: task, observed problem, affected population, consequence, and available evidence. The champion should not need to diagnose the technical cause before raising a problem. A clear reproduction or case description is often enough to route it.
Assign a receiving owner and response expectation. Interface defects, policy ambiguity, training gaps, and resource shortages need different routes. Sending everything to a generic project mailbox can make the champion appear ineffective even when the observation is valuable.
Close the loop visibly. Explain what will change, what will not, and why. If a request is deferred, provide the relevant condition or review point. Champions should not be left repeatedly asking colleagues to be patient without an answer they can stand behind.
Track recurring themes across locations. Several apparently local questions may reveal a common design problem. Conversely, a local variation may be justified and should not automatically become a global requirement. The accountable owner must make that distinction with evidence.
Estimate likely demand before rollout and monitor it afterward. Champions may be effective for brief task guidance but unsuitable as the sole route for outages, complex data repair, or policy disputes. Formal support still needs coverage and escalation.
Set boundaries on availability. Colleagues should know when the champion can help and where to go outside that window. Avoid creating an informal expectation that the person is always reachable, including outside their agreed working arrangements.
Recognize the contribution in the employee’s workload and development discussion. Recognition need not mean a ceremonial award; it should include protected time, access to learning, and a fair account of the work performed. Do not promise career outcomes the organization has not approved.
Review whether the role remains sustainable. If a champion repeatedly absorbs unresolved project defects, the program should fix the source or add appropriate support. Personal commitment should not conceal an under-resourced operating model.
Explain how feedback will be used and who will see it. Champions should not become covert monitors of individual compliance. Their position as a peer can be damaged if ordinary questions are unexpectedly converted into performance reports.
Respect confidentiality and appropriate reporting routes. Some concerns may involve employment, accessibility, privacy, or interpersonal issues that should go through authorized functions rather than a broad project forum. Give champions guidance on those boundaries.
Allow candid disagreement. A champion should be able to say that a feature is limited or that a decision remains unresolved. Accurate explanations are more credible than exaggerated enthusiasm, especially when employees are encountering real difficulties.
Keep managers accountable for management decisions. Champions can help people understand a new task, but managers must set priorities, provide time, and resolve competing instructions. The network cannot compensate indefinitely for supervisors continuing to require the old process.
Look at the quality and disposition of feedback, the usefulness of local support, and whether recurring problems become less frequent after a supported change. Use representative cases rather than counting every conversation as an adoption success.
Ask colleagues whether they can find help and whether the guidance is consistent. Ask champions whether they receive timely answers and have enough protected time. Ask owners whether the issue reports improve decisions. These perspectives reveal different parts of the operating loop.
Avoid using system usage as the sole measure of a champion’s performance. Local task volume, access, staffing, and unresolved defects may affect adoption beyond the champion’s control. Evaluation should reflect the role’s actual responsibilities.
Plan the transition after rollout. Some champions may continue as part of an improvement community; others may return fully to their ordinary roles. Transfer useful knowledge to formal support and retire temporary responsibilities deliberately.
Before appointing the network, write the role, map the work it must represent, and establish who will act on its feedback. Select credible people, protect their capacity, and test one issue from local observation through verified resolution. Change champions matter when they make the transformation more informed and workable, rather than simply making its messages louder.
