Look at who is already using the tool most and ask what they use it for. The answer identifies the person and, more usefully, the specific tasks the tool suits, which is the material any wider rollout should be built on rather than the feature list.

Time, and permission to spend it helping colleagues rather than only on their own work. Occasionally a route to raise problems that get fixed. Formal recognition can help and can also cost them the peer standing that made them persuasive, so it is worth asking rather than assuming.

What if a team has none?

Treat it as evidence rather than as a vacancy. After a reasonable period with access and no uptake, the likeliest explanation is that the tool does not fit that team's work, and importing an enthusiast produces a demonstration rather than adoption. Ask that team what they tried before spending more.

Glossary

Champion user

A champion is the person in a team who takes a tool up first and brings colleagues with them, which moves adoption further than formal training generally does.

In plain terms

Somebody in the team works out how to make the tool useful for the work they all do, and then other people copy them. It is not a role anybody was given, and the reason it works is proximity: the person doing the same job as you, using it on the same material, is more convincing than any demonstration, because they have already answered the question of whether it applies here.

Why it matters

Because it is the cheapest thing available in adoption and it is routinely bypassed in favour of the expensive things. A training session reaches everybody and is forgotten; a colleague reaches a few people and changes what they do. Organisations that notice who has already made a tool work, and give them a little time to help, get more movement than a programme costs several times over.

How it works

They emerge rather than being appointed, and the distinction survives every attempt to organise it. Somebody had a problem the tool happened to fit, persisted through the first awkward attempts, and arrived at something that works for their actual job. Naming a champion who has not been through that produces an advocate without evidence, which colleagues detect immediately.

What they contribute is credibility rather than expertise. They know less about the product than the vendor and they know the work, so what they say is specific: use it for this bit, not that bit, and watch out for this. That is the form advice has to take before somebody will change their method, and no central communication can produce it.

The commonest way organisations lose them is by adding weight. A person who was helping colleagues in the ordinary course of their work is given a title, a mandate and a reporting line, and the thing that made them persuasive, that they were a colleague rather than a representative, is what has just been removed. What they usually need is time and permission, not a role.

Their absence in a team is information rather than a gap to be staffed. Where nobody has taken a tool up after a reasonable period, the likeliest explanation is that it does not fit the work well, and importing an enthusiast from elsewhere tends to produce a demonstration rather than adoption. That is worth knowing before more is spent.

Two sources of the same advice

Both columns contain accurate information and only one of them changes behaviour, which is easier to see once the questions at the bottom are separated. A training session is well suited to the first question and is usually delivered before anybody has the second, so by the time somebody is standing in front of a task wondering whether to try the tool, the session is weeks old and was never about their situation anyway. The colleague opposite is answering at the moment of the decision, about this material, having already made the mistakes. That timing is most of the effect. It also explains why the cheapest intervention available is usually to give the person who has already worked it out a couple of hours a week and leave everything else alone.

Seen in the wild

One person in a team who works out which drafting tasks an assistant genuinely helps with, and which it does not.
ChatGPT
The colleague who builds the first automation that saves the team real time, after which others ask for their own.
Make
Somebody who learns which questions internal search answers well, and tells people which ones to bother asking.
Glean

Common misconceptions

People assume

We should appoint champions in each team.

In fact

Appointing one produces an advocate without evidence, which colleagues read accurately as a representative rather than a peer. What works is noticing who has already made it work and giving them time, which is a smaller intervention and the only one that preserves the thing that made them effective.

People assume

It is a nice extra alongside proper training.

In fact

In most rollouts it does more of the work than the training does, at a fraction of the cost. Training explains a tool; a colleague explains what to use it for on this team's material, which is the question people are actually stuck on.

Questions

How do we find them?: Look at who is already using the tool most and ask what they use it for. The answer identifies the person and, more usefully, the specific tasks the tool suits, which is the material any wider rollout should be built on rather than the feature list.
What do they need?: Time, and permission to spend it helping colleagues rather than only on their own work. Occasionally a route to raise problems that get fixed. Formal recognition can help and can also cost them the peer standing that made them persuasive, so it is worth asking rather than assuming.
What if a team has none?: Treat it as evidence rather than as a vacancy. After a reasonable period with access and no uptake, the likeliest explanation is that the tool does not fit that team's work, and importing an enthusiast produces a demonstration rather than adoption. Ask that team what they tried before spending more.