You named the system champion in ten minutes. The team chose theirs ten years ago — and it's not the same person.
Every rollout has the same scene. Someone asks in the meeting: "who's going to be the key user?" And the manager points to the youngest person on the team, the one who's "good with computers."
On the project spreadsheet, it makes perfect sense. In the shop, it doesn't.
Because when the machine makes a strange noise at three in the morning, nobody calls the person who's good with computers. They call the mechanic with twenty years at the company, who has never been invited to a project meeting.
Last week we talked about the first login — the minute each person silently decides whether the system is theirs or the boss's. Today is the natural follow-up: who they look to before deciding.
The key user born on the org chart
The "key user" role came from big system projects and made its way into maintenance without anyone questioning it. And it's almost always chosen by one of three criteria: whoever is most comfortable with technology, whoever can step away from the routine without being missed, or whoever never says no to the boss.
Notice that none of the three is "the person the team listens to."
In thirty years I've seen that choice made dozens of times, from both sides of the table. And I've seen what happens to the chosen one in the following months: he becomes "the system guy." He answers questions, logs what others didn't log, carries messages from management, chases overdue work notes.
👉 In his coworkers' eyes, he stopped being one of them. He went over to the other side.
And then the manager is puzzled: he picked a champion and got a data-entry clerk. With luck. Without luck, he got an inspector nobody invites for coffee anymore.
👉 The title came from above. Authority, in maintenance, has always come from below — from whoever solved the problem when nobody else could.
We follow people who are like us
Nobody changes a habit because they heard a good argument. They change because they saw someone like them — same uniform, same shift, same complaints — do things differently and do well.
The manager can present the system with the best slides in the world. The technician will wait to see what that coworker he trusts does. If the coworker opens the screen and checks the history before taking the pump apart, that's it: the presentation happened right there, no projector needed.
👉 Influence isn't a title. It's similarity plus results.
There's a second, subtler mechanism. People who really influence others don't start by pushing. They start by meeting people where they are: speaking their coworkers' language, acknowledging their complaints, admitting what's still annoying about the system. Only then do they show the way. Whoever shows up leading without having met people where they are runs into a polite wall.
And the third, which explains why appointing someone usually goes wrong: the same gesture changes meaning depending on the motive others see in it. Before the badge, he used the system because it helped. After the badge, he uses it because it's his job.
👉 The day you hand over the title, what was an example becomes advertising. And everyone has learned to discount advertising.
Signs of an imposed champion
They show up early, and are almost always read as "lack of team engagement":
- Everyone hands him their paper to enter. The champion has become the department's only real user.
- The nickname. "Talk to the system owner." "Here comes the inspector." Said with a laugh. It's not a joke.
- The real questions never reach him. In front of the boss, they ask him. In the corner, they ask someone else — or go without an answer.
- He starts saying "you guys have to." He switched pronouns without noticing. The team noticed.
- The best technician in the place has never been heard about the system. Nobody asked his opinion. He didn't offer it either.
👉 The cost that doesn't show up: you burn out a good professional. He loses his place among his peers and gains no authority in return. He's stuck in the middle of the hallway, alone, defending a tool he didn't choose.
And there's the operational risk. Adoption that rests on a single person isn't culture — it's dependence. He changes shifts, goes on vacation, or quits, and usage collapses in two weeks.
What the software shows — and what it can't see
From my side of the table, with the usual honesty.
Every rollout needs a point of contact — ours do too. Someone who validates the master data, sets the schedule, and owns the configuration. That's legitimate and necessary.
👉 But a point of contact isn't a champion. The point of contact answers to the project. The champion answers to the team. Confusing the two is the root of almost everything I described above.
What Manusis4 helps you see: every work request opened, every work order closed, every work note has a name and a time. Looking at the records from the first weeks, you can see who started using it without being told — who opens the work request right away instead of mentioning it in the hallway, who describes the cause with care, who goes back to the asset history before laying a hand on the machine.
What the software can't see: why the others follow that person. Trust isn't a data field. Credibility on the shop floor can't be configured, can't be imported from a spreadsheet, and doesn't come in any update.
👉 The system shows the trail of who uses it. Who the team respects, only someone present on the floor can see.
Five moves to find — not manufacture — champions
- Before you appoint anyone, observe. For two weeks, notice: who does the team call when the machine has a problem? Who does the new hire sit next to at lunch? That list is your department's influence map. It rarely matches the org chart.
- Look for people already using it without being told. The records from the first weeks show you. Start the conversation with curiosity, not praise: "I saw you checked the pump's history before opening it. Did you find what you needed?"
- Ask for help, don't hand out a title. "I need your opinion: what's getting in people's way in the system?" And change, that same week, at least one thing he pointed out. That's what makes him a voice: his coworkers see that talking to him changes something.
- Protect his place among his peers. No entering other people's work notes. No reporting who isn't using it. No praise that sets him apart — "if only everyone were like him." The day he becomes an informant, you've lost the champion and the team has lost a coworker.
- Have more than one, and include the skeptic. One per shift, with different profiles. And don't avoid that distrustful veteran everyone respects. When he says "this helped me," it's worth more than ten trainings.
👉 None of this is a persuasion technique. It's respect for a hierarchy that already exists and isn't on the org chart.
This week's reprogramming
Answer without thinking too hard: who does your team turn to when things get tight?
Now the second question: has that person ever been heard about the system?
"Champions aren't appointed. They're recognized. The team chose before you did."
Take this sentence to your next project meeting. It replaces the question "who's going to be the key user?" with a much more useful one: "who does the team already follow — and what does that person think about all this?"
Next week
👉 There's a kind of resistance that doesn't argue, doesn't complain, and doesn't skip training. It says "sure, no problem" — and stays on paper.
In #66 we'll talk about it: silent resistance — and why the easy "yes" should worry you more than the "no" said out loud.
Until then.