Managing Resistance and Adoption
Lena Moreau leads a twelve-person customer support team at a software company. When she announced that the team would start using an AI tool to triage tickets and suggest first-draft responses, her most experienced agent, a fifteen-year veteran named Roy, crossed his arms and said flatly: "This won't work here. Customers want to talk to humans, not get AI responses." Lena's first instinct was to argue, to list the benefits, to remind Roy that the decision was made. She did not. Instead she got curious about what Roy was really worried about. That choice, treating his resistance as information rather than obstruction, is the difference between an adoption that stalls and one that sticks. This lesson is about how to do that across a whole team: how to understand resistance, address it, and move people from anxiety to active use without resorting to mandates.
What This Lesson Covers
The central reframe of this lesson is simple and powerful: resistance is feedback, not obstruction. When a team member pushes back on AI, they are usually telling you something real about a concern that needs addressing. Managers who dismiss those concerns as irrational fail; resistance persists, adoption stalls, and genuinely useful changes get abandoned. Managers who understand the concerns, address them directly, and provide support succeed, because they recognize that adoption takes time and support, not mandates.
This lesson covers the adoption curve (the predictable mix of fast and slow adopters on any team), the types of resistance and how each one is answered differently, the change management principles that make adoption work, the five stages people move through, and a worked phased adoption plan with real adoption percentages. We follow Lena and her support team throughout.
The Adoption Curve: People Adopt at Different Speeds
On any team, people fall into predictable groups when it comes to a new way of working. Knowing the groups stops you from treating slow adopters as a problem to be fixed; they are a normal and expected part of every rollout.
- Innovators and early adopters (roughly 15 to 20%): they embrace AI quickly with little persuasion, are self-directed learners, and tolerate risk. They respond to the chance to try something new and to new capabilities. On Lena's team, two agents were here.
- Early majority (roughly 35 to 40%): they adopt after seeing the early adopters succeed. They want evidence before changing, and they need support and training. They respond to proof of value, a clear process, and help.
- Late majority (roughly 25 to 35%): they adopt once it is clearly mainstream. They start skeptical and need reassurance. They respond to a demonstration that it is genuinely working and to clear expectations.
- Laggards (roughly 5 to 10%): they resist longest and may only adopt when the old way no longer works. They often have valid reasons for their skepticism. They respond to having their concerns understood, direct conversation, and support. Roy, despite his experience, was sitting here at the start.
Different speeds are not a sign that some people are wrong. An early adopter and a late-majority adopter are both healthy parts of the curve. Your job is to know where each person sits and give them the support that fits.
The Types of Resistance, and How Each Is Answered
Not all resistance is the same, and the biggest mistake is responding to every form of it identically. There are five distinct types, each needing a different response.
Rational resistance is based on legitimate concerns: "I worry AI will make mistakes that hurt customers" (a valid quality concern), or "I'm already busy, new tools will overwhelm me" (a valid workload concern if unsupported). The response is to address the underlying concern directly with evidence, process changes, and support.
Identity-based resistance is tied to professional identity: "I'm a writer, if AI does the drafting, am I still a writer?" The response is to help the person see how their role evolves rather than disappears: "You're still a writer, now you have time to focus on deeper storytelling."
Status quo bias is simple preference for things as they are: "We've always done it this way." The response is to acknowledge what was genuinely working before, show what the new approach adds, and support the person through the transition.
Competence concerns are worries about being able to learn: "I'm not tech-savvy, this will frustrate me," or "I learn slowly, everyone will be ahead of me." The response is differentiated learning: one-on-one support, extra time, and small early wins that prove learning is achievable.
Change fatigue is exhaustion from too many recent changes: "We just changed processes last year, why again?" The response is to acknowledge the fatigue honestly, explain why this change matters, and deliberately limit other changes during the AI transition.
Roy's stated concern ("customers want humans") was on the surface. Underneath, when Lena listened, sat a mix of identity-based resistance (he was the expert who knew the best answers) and a rational quality concern (he feared generic AI replies would damage relationships he had spent years building). Naming the real concern is what made it addressable.
Six Change Management Principles
These six principles turn a chaotic rollout into a managed one. They apply whether you are changing tools, processes, or anything else that asks people to work differently.
- Communication precedes adoption. Before the change, explain what is changing and why. During the transition, keep communicating progress and addressing concerns. After, celebrate successes and fix lingering issues.
- Involvement builds ownership. Include the team in decisions about implementation, get their input on how to make it work, and let them help shape the change rather than just receive it.
- Show the benefits. Use quick wins, simple metrics, and real stories of a colleague succeeding with AI. Evidence beats assertion.
- Provide support. Training to teach the new way, coaching for those who struggle, resources like documentation and templates, and time to practice before full implementation.
- Acknowledge loss. Even a positive change takes something away: a familiar way of working, a hard-won confidence. Saying "I know this is different from how you've always worked, and that's hard" helps people move forward.
- Build in feedback. Regular check-ins ("How's it going? What's working? What isn't?"), visible adjustments based on what you hear, and a continuous-improvement framing: "We're learning together."
The Five Adoption Stages
People move through five stages, and your role shifts at each one:
- Awareness: people know the change is coming but may not understand it, and anxiety is common because the unknown is scary. Your role: communicate clearly, answer questions, reduce anxiety.
- Understanding: people grasp what the change is and why, but may still be skeptical. Your role: explain the rationale, address concerns, build the case.
- Acceptance: people acknowledge it is happening and are willing to try, even if not enthusiastic. Your role: provide training and support, celebrate early wins.
- Adoption: people are actively using the new way; some struggle, some excel, early successes emerge. Your role: coach, troubleshoot, reinforce the benefits.
- Integration: the new way is simply normal, and people adapt it to their own work. Your role: monitor, refine, help others learn.
Different people move through these stages at different speeds. The work is to know where each person is and meet them there, rather than assuming everyone is at the same point.
The Resistance Conversation Framework
When someone resists, a reliable six-step structure keeps the conversation productive. This is exactly what Lena used with Roy:
- Listen. "Tell me what you're thinking about this change." Do not interrupt; really listen. Roy explained: "I've built relationships with customers. They trust me. AI suggestions will be generic."
- Clarify. "Help me understand. Is your concern about the quality of responses, or about your role?" People are not always clear about what is actually bothering them.
- Validate. "That's a reasonable concern. A lot of people worry about that." Validating does not mean agreeing with the resistance; it means you understand the concern. Lena said: "It sounds like customer relationships are really important to you. That makes sense."
- Address. "Here's how we're handling that." Provide information, support, or a process change. Lena reframed: "What if AI helps you research faster, and you still decide how to respond? You stay in control of the relationship." She also shared early data showing customer satisfaction had held steady where the tool was piloted.
- Invite. "Would you be willing to try it on just one ticket?" Give a choice, do not mandate. Lowering the stakes makes it about learning, not compliance.
- Support. "If you try it, I'll be right here to help. You're not on your own with this."
Roy agreed to try it on one ticket. A few weeks later Lena could tell him: "I noticed you used the AI suggestion on that complex billing issue and customized it really well. That's exactly the right balance." Roy adopted, not because his resistance was ignored or overridden, but because his concern was understood and answered.
Worked Example: A Phased Adoption Plan With the Change Curve
Lena mapped her whole rollout against the change curve, the predictable emotional arc people travel during any significant change: from initial denial, into a dip of frustration and anxiety as they grapple with the new reality, through a turning point of experimentation, and finally up into commitment as the new way becomes normal. Her job at each stage of the curve was different, and she set realistic adoption targets for each phase.
Phase 1, Weeks 1 to 2 (Awareness, the top of the curve before the dip). She announced the change four weeks before launch, ran an open Q&A, and explained honestly what AI would and would not change about people's jobs, including job security directly. Target active use: just her two early adopters, about 17%, piloting the tool. The goal here was not usage; it was reducing anxiety and getting ahead of the denial reaction.
Phase 2, Weeks 3 to 4 (Understanding and Acceptance, descending into the dip). This is where frustration peaks and where most rollouts fail. She ran hands-on training, shared the early adopters' concrete wins, and held the resistance conversations with her laggards, Roy among them. She deliberately scheduled no other team changes during this window to avoid stacking change fatigue on top of the dip. Target active use climbed to about 40% as the early majority started, on the strength of the evidence the early adopters provided.
Phase 3, Weeks 5 to 6 (Adoption, climbing out of the dip). The late majority began once they saw it clearly working. Lena coached the strugglers one-on-one, paired the nervous with the confident, and celebrated every attempt, not just every success. Target active use: about 65%.
Phase 4, Weeks 7 to 8 (Adoption to Integration, the climb to commitment). The tool became routine. Roy, the original holdout, was now using it daily and had even shown a newer agent a trick for customizing the AI draft. Target active use: about 80%, with the remaining 20% being occasional or minimal users, which Lena treated as acceptable.
Ongoing (Integration). Adoption settled around 85 to 90% regular use. Lena kept light-touch monitoring and started exploring advanced features. Notice that adoption never hit 100%, and that is normal and fine. A small group of minimal users is a healthy outcome, not a failure. The shape of the climb (slow start, a dip in the middle, then a steepening rise to a plateau) is exactly what the change curve and the adoption curve predict. Because Lena planned for the dip in Weeks 3 to 4 instead of panicking when adoption looked slow, she supported the team through the hardest stretch instead of abandoning the tool right before it would have taken off.
Use Case: Differentiated Support for Late Adopters
Not every resistant person resists for the same reason, so Lena did not use one approach for all. With her slower-adopting agents, she met each one individually and tailored her response to the specific concern. For an agent with an identity concern, she said: "Let's talk about what being great at support means. I think it's solving people's real problems. AI gets you the first draft faster so you can spend your energy on the tricky cases that need your judgment." For one comfortable with the current pace: "No pressure to handle more volume. But how about we use the saved time on the complex escalations you actually enjoy?" For a skeptic burned by past tools: "I know the last tool we rolled out was a mess. Let me show you why this one is different." She also shared success stories ("Roy was the most skeptical of anyone, and now he uses it every day"), and she celebrated trying, not just succeeding: "I saw you used AI on that ticket. How did it go?" The result was slower adoption from this group, but real adoption, with satisfaction intact.
Anti-Patterns to Avoid
- "My way or the highway." Dismissing resistance and mandating adoption produces external compliance, not genuine adoption. People comply while you watch, then revert. Address concerns; some resistance is data.
- "Accommodate all resistance." The opposite failure: postponing the change indefinitely because someone objects. Some resistance never fully resolves. Listen, address legitimate concerns, then make the decision and support everyone through it.
- "Blame the late adopters." When adoption is slow, blaming people for "not wanting to change" misses the real cause, which is usually insufficient support, unclear benefits, or unaddressed concerns. Diagnose the change management, not the people.
- "One size fits all." Treating every resister identically ignores that a scared person and a skeptical person need different things. Differentiate.
- "Adoption ends at go-live." Stopping attention after launch lets adoption regress. Plan for three to six months of active support, then ongoing monitoring.
Human Judgment Checkpoints
When managing resistance, pause and ask yourself: Am I dismissing legitimate concerns, or just not wanting to hear them? Is slow adoption really resistance, or is it insufficient support I haven't provided? Am I rushing the pace and creating change fatigue? Do I actually understand this specific person's concern, or am I assuming? Am I being patient with different adoption speeds? These questions keep you honest, and they are also where responsible leadership lives: address job-security concerns directly and honestly, be clear that humans remain accountable for AI-assisted work, and protect the team's psychological safety so that struggling to learn is normal and supported, never punished.
Practice and Reflection
Reading about Roy is not the same as sitting across a table from your own version of him. Work these five exercises against a rollout you are actually running, and write your answers down. The writing is what turns a framework into a plan.
1. Map the resistance and its root causes. Name the specific people who are resisting, one line each. For every person, record what they are saying out loud, then what you suspect the real concern underneath is, the way Lena separated "customers want humans" from Roy's fear about the relationships he had spent years building. Then ask honestly whether the concern is rational: would a reasonable person in that seat hold it? Finish each entry with what would actually address it. Do this person by person rather than for the team as a whole, because the entire point is that the concerns differ.
2. Plan your change communication end to end. Write the timeline before you announce anything. When and how will you make the pre-announcement? What exactly will you say about why this matters and what it means for people's jobs? How will you handle questions and concerns, and where will people be able to raise them safely? What training will you provide, and when? How will you keep communicating during the transition rather than going quiet after launch? And how will you recognise successes when they arrive? Document the whole plan as one page you can hand to your own manager.
3. Hold one real resistance conversation. Pick the person whose resistance is currently costing you the most and schedule a conversation. Use the six steps in order: listen, clarify, validate, address, invite, support. Afterwards, write down what you learned about their concern, especially anything that surprised you, since the stated objection is rarely the whole story. Then follow up a few weeks later and check: did addressing the concern actually help, or do you need to adjust the support you offered?
4. Design differentiated support across the adoption curve. Sort your team into the four groups and decide what each one specifically needs. Your early adopters may need advanced learning and a visible role mentoring peers. Your early majority need evidence, a clear process, and time. Your late majority need more coaching, direct support, and extra time to get comfortable. Your laggards need a direct conversation and one-to-one support more than they need another training session. Write the plan for each group rather than a single plan for everyone.
5. Plan the support structure that outlasts the launch. Adoption is a process, not a launch day, so decide now who is available for questions (you, a peer champion, a training team), how people ask for help (a chat channel, office hours, email), how often you will check in, and when you will formally assess progress: week four, week eight, week twelve. Add one more line that most plans miss: what you will change if adoption is slower than you expected. Deciding that in advance keeps you diagnosing your own change management instead of blaming the team.
Related Lessons
This lesson sits inside a cluster of team enablement material, and three lessons in particular pair with it.
- Assessing Team AI Readiness comes first in practice. Knowing where your team already sits, in skill, in confidence, and in attitude, is what lets you predict where resistance will show up and shape your adoption strategy before you announce anything.
- Building Team AI Capability is the other half of adoption. Much of what looks like resistance is really a capability gap, and sustained adoption depends on the ongoing skill building that lesson covers rather than on a single training session at launch.
- Establishing Team AI Norms reduces the confusion that breeds resistance in the first place. When people know what is expected, what is allowed, and who is accountable, several of the anxieties in this lesson never get a chance to form.
Frequently Asked Questions
How long does adoption actually take? Plan for three to six months of active support for full integration, even though basic usage can reach a majority in four to eight weeks. The middle dip is real; people often look stuck right before they break through.
What if someone simply refuses? First, make sure you have genuinely understood and addressed their specific concern, since refusal often masks a fixable worry. If they still prefer the old way and it does not block the team, some minimal use can be acceptable. Keep the door open and check back: "Would you try again? Things might feel different now."
Should I make adoption a performance requirement? No. Tying it to performance reviews produces resentment and shallow, compliance-only usage. Encourage, support, and let evidence and peers do the persuading.
Why is adoption on my team so slow compared to the percentages here? Usually it is not the people. Check whether the benefits are clear, whether support is sufficient, whether you piled this change on top of others (change fatigue), and whether you are visibly using the tool yourself. Slow adoption is almost always a change-management gap, not a people problem.
Key Takeaways
- Resistance is feedback, not obstruction. It points to concerns that need addressing. Listen to it instead of overriding it, and you turn resisters into adopters.
- Different concerns need different responses. A job-security worry, a quality concern, an identity fear, and a learning-pace anxiety are not the same. Diagnose the real concern before responding.
- People adopt at different speeds, and that is healthy. Early adopters, early and late majority, and laggards are a normal mix. Know where each person sits and tailor your support.
- Use the six-step resistance conversation. Listen, clarify, validate, address, invite, support. It moves people without mandates, as it moved Roy from flat refusal to daily use.
- Plan for the dip. The change curve predicts a slump of frustration in the middle (Weeks 3 to 4 in a typical rollout). Support the team through it instead of abandoning the tool right before it would take off.
- Adoption takes time and rarely hits 100%. Plan for three to six months of active support; a small group of minimal users is an acceptable, normal outcome, not a failure.
- Your presence is the biggest accelerator. Your accessibility, coaching, and encouragement, plus visibly using the tool yourself, matter more than any feature. Celebrate trying, not just succeeding.
- Acknowledge what is being lost. Even a good change takes away something familiar. Naming that honestly helps people let go and move forward.
Skill.re