Start by taking the concern seriously
Dismissing resistance as "people just need training" usually backfires, because it often isn't a skills gap at all — it's a legitimate question about what this actually means for someone's role and their future at the company, and treating a legitimate question as a training problem to be solved with more enthusiasm tends to make people more skeptical, not less, since it signals the concern wasn't heard in the first place.
Leaders who address that underlying question directly and honestly — even when the honest answer is genuinely uncertain — build far more durable adoption than ones who route around it with generic enthusiasm about the tool's capabilities. People can tell the difference between a leader who's actually engaging with their concern and one who's performing reassurance without substance behind it.
What actually helps in practice
- Be specific and honest about what is and isn't changing for a given role, rather than vague reassurance that doesn't actually answer anyone's real question about their own position.
- Let early adopters — peers, not leadership — share genuine experience; it lands very differently coming from a colleague than from a mandate delivered top-down from above.
- Give people real time to build comfort with a tool before measuring their use of it — forced early adoption breeds resentment, not comfort, and tends to produce exactly the resistance it was meant to prevent.
When the honest answer is genuinely uncertain
Sometimes the truthful answer to "will this affect my role" really is "we don't fully know yet," and that uncertainty is uncomfortable for leadership to say out loud. But an honest acknowledgment of genuine uncertainty, paired with a real commitment to communicate as things become clearer, tends to land better than false, confident certainty that gets exposed as hollow reassurance the first time circumstances actually do change down the line.
Organizations that handle this well also make a point of checking back in specifically with people who expressed resistance early on, rather than treating the initial rollout conversation as the only time this topic gets discussed. That follow-up signals the concern was taken seriously as an ongoing conversation, not dismissed with a one-time reassurance and never revisited again.
It's also worth distinguishing clearly between resistance rooted in genuine job-security concerns and resistance rooted in simple unfamiliarity with a new tool, since the two need meaningfully different responses. The first deserves a direct, honest conversation about roles and the future; the second is often better addressed through hands-on practice time and peer support rather than a formal, top-down conversation about the company's strategic direction.
Leaders who navigate this well also tend to accept that some resistance will remain even after a genuinely good-faith effort to address it, and that's an acceptable outcome rather than a sign the effort failed. Not every person will become an enthusiastic adopter on the same timeline, and treating persistent skepticism from a minority as a rollout failure tends to create more pressure and resentment than simply allowing adoption to happen at different paces across a large organization.