Maybe We’ve Been Thinking About Trainers All Wrong

The role of the trainer.

That comparison made me question a habit I see often in change work: we treat trainer selection as a resourcing problem when it could be a leadership-development opportunity. If organizations want people to show up differently during change (which they should!), we should consider redesigning this role so it feels less like extra work and more like recognition, growth, and trust.

On a recent implementation, the question of who will train end users became very real. And it reminded me of a pattern I have seen on other projects: when organizations reach the point where trainers are needed, the role often lands with more anxiety than energy.

• Do I know the system well enough?
• Am I comfortable presenting to my peers?
• Where am I supposed to find the time?

All completely reasonable concerns. But I found myself having a different reaction: Why aren’t more people raising their hands for this?

And then I realized why that question felt so obvious to me. I was bringing an entirely different definition of trainer into the conversation.

In restaurants, trainer meant: We noticed you.

Restaurants and corporate implementations obviously operate in very different contexts. But both depend on the same human challenge: helping people adopt new behaviors under pressure, in front of peers, while the work still has to get done.

During a New Store Opening, we didn’t wait around for someone to become the foremost expert before identifying trainers. Frankly, how could we?

The restaurant was new. The team was new. Everyone was learning. Instead, the training team and restaurant leaders watched people.

• Who had a great attitude?
• Who was eager to learn?
• Who picked things up quickly?
• Who connected naturally with other people?
• Who showed up with a smile even when things got chaotic?

Those were the people you started watching. And when someone was selected to become a trainer, it meant something. You were one of the rockstars.

Depending on the restaurant, maybe you got a different shirt or a free meal. But the real reward was the status attached to it. Someone noticed you. Someone believed you represented the standards and culture they wanted replicated. And people were proud of it. Nervous, maybe – but excited. Something they told their families about. Because becoming a trainer wasn’t just more work. It was often the beginning of what came next.

Trainer could lead to traveling with a New Store Opening team. Trainer could lead to becoming a key hourly employee. Key could lead to management. The trainer pool naturally became part of the leadership pipeline. Looking back, I realize we weren’t just identifying the people who knew how to do the job. We were identifying people we believed could help other people succeed at the job.

That is an important difference.

In implementations, trainer can mean: We need you.

Now contrast that with what can happen during a traditional corporate implementation. The project reaches the point where trainers are needed, and people are assigned (“volun-told”) to take on the role. And suddenly we hear:

• “I don’t know enough.”
• “I’m not comfortable teaching this yet.”
• “I don’t have time.”

The obvious interpretation is that people don’t want additional responsibility. But I think there’s something more interesting underneath it. Maybe they’re also saying:

• I don’t feel prepared for this.
• I don’t know that I’ll be supported while doing this.
• I already have a full-time job that isn’t going away because the project needs me to train.

If that’s the experience we’ve created, reluctance is completely rational – in fact, we fostered it. We haven’t necessarily offered someone an opportunity. We’ve assigned them another responsibility.

And then there’s the “expertise” question.

One assumption I keep coming back to is the idea that the best trainer must be the person with the greatest system expertise. Of course, trainers need enough knowledge to teach accurately. But during an implementation, especially before go-live, how much true expertise exists?

Everyone is learning.

The system is new. Processes are changing. Decisions are still settling into place. That does not mean expertise is irrelevant. It means expertise is incomplete. During implementation, the strongest trainers are not always the people who know the most on day one or who have been most involved during the design and build phases; they are often the people comfortable learning alongside others, asking questions openly, and building confidence even while the organization is still figuring things out. I’d argue that some of the most valuable trainer behaviors are things like:

• Can you build confidence?
• Can you make it safe to ask questions?
• Can you help someone believe, “I can do this?”

Those aren’t system skills. They’re leadership skills.

Which brings me to Change Ambassadors.

This is where the restaurant comparison really started changing how I think about stakeholder engagement. When we, as OCM practitioners, ask leaders to nominate Change Ambassadors for a Change Network, what qualities do we typically ask them to look for? People who are respected by their peers.

• Positive.
• Curious.
• Adaptable.
• Willing to learn.
• Good communicators.
• Influential without necessarily having a leadership title.

And suddenly it hit me: That’s almost exactly how we identified trainers in restaurants. So why treat these as completely separate talent pools?

I’m not suggesting every Change Ambassador should become a trainer. But perhaps we’ve been thinking about the timing backwards. Instead of waiting until a few months before go-live to find trainers, what if we started identifying and investing in them much earlier? Give them exposure to the change. Coach them. Let them practice communicating (this one is especially key). Help them build confidence alongside the project. Then, when training begins, we’re not asking someone to suddenly step into a leadership role.

We’re inviting someone who’s been developing toward it all along. That’s a very different experience.

Recognition versus assignment

That’s ultimately the difference I can’t stop thinking about. In restaurants, becoming a trainer often started with someone saying: We noticed you.

In corporate implementations, becoming a trainer can feel more like: We need you.

Same responsibility. Completely different experience. When trainer roles are framed as recognition, people are more likely to see them as evidence of trust, potential, and growth. When they are framed as a project need, people are more likely to experience them as another demand on capacity they already do not have. The difference is not the task itself. It is the identity the role gives, or fails to give, the person asked to step into it.

That makes me wonder how often what we label as “resistance” is just a response to how participation in change is introduced. People may not be resisting the role itself. They may be resisting the experience of being added to a project plan without the readiness, support, or recognition that would make the role feel worthwhile. Framing matters. Identity matters. Recognition matters.

When we recognize people, we build leaders. When we just assign roles, we add resistance.

So maybe the question isn’t only: Who should train our people? Maybe it starts much earlier: How could we design stakeholder roles so people experience participation in change as an opportunity to grow, not simply one more thing they have to do?

Because the way we design participation shapes how people experience change. If we want trainers who build confidence in others, we should start by building confidence in them – and that’s something I’m going to keep thinking about.