Catalogue › Change and Communications › resistance-management

Resistance management

Understands and responds to resistance, fear and scepticism about AI as information about the change - listening at group level, diagnosing causes such as job fear, monitoring worries, quality doubts, ethical objection, workload and change fatigue, separating legitimate risks from misunderstanding, and choosing a fitting response with an owner. Use when a group pushes back, when fear or rumour spreads, or when scepticism stalls adoption.

Department

Change and Communications

Lifecycle

Enable, Launch, Measure, Improve

Maturity

explorer, adopter, builder, scaler, ai-enterprise

Risk tiers

0, 1, 2, 3

Platforms

platform-neutral

Editions

starter, scale, enterprise

Reviewers

none

Status

draft

Copilot Cowork

Change and Communications plugin for Copilot Cowork, or this skill on its own: Download SKILL.md

Licence

CC BY 4.0, by Simon Foote

Purpose

Resistance to AI is rarely irrational. People worry about their jobs, about being watched, about being blamed for an AI mistake, about professional standards, about ethics, and about finding time to learn yet another thing. Some of those worries point to real risks the programme has not handled. This skill treats resistance as information: it listens at group level, diagnoses causes, separates legitimate risks from misunderstandings, and chooses a response that fits the cause. It usually goes wrong when programmes label people as "resistors", answer every concern with more enthusiasm, or push harder on adoption when the honest answer was to fix something.

When to use

• A team, function or professional group is pushing back on an AI change, openly or by quietly not engaging.
• Fear or rumour about AI (job cuts, monitoring, data leaks) is spreading.
• Experienced professionals are sceptical about AI quality and their scepticism is discouraging others.
• Employee representatives or a staff network have raised formal concerns.
• Adoption has stalled in a group despite access, onboarding and support being in place.

When not to use

• Mapping all stakeholders and their influence before the change - use change-and-communications:ai-stakeholder-mapping.
• Assessing how roles and work will change - use change-and-communications:people-change-impact.
• Diagnosing low use caused by access, onboarding or support gaps - use copilot-adoption:adoption-readiness.
• Formal decisions on whether a specific AI use should be allowed - use responsible-ai:prohibited-use-review.
• Building the overall communication strategy - use change-and-communications:ai-communication-strategy.

Questions to ask first

1. Which group is resisting, what exactly are they saying or doing, and since when?
2. What have they been told about the change, by whom, and what did they hear?
3. Is any part of the concern a real risk, gap or unanswered question that the programme should fix?
4. What has already been tried, and how did the group respond?
5. Does the group have a formal voice (employee representatives, professional body) that must be engaged through its own route?

Required inputs

• The concern register from change-and-communications:ai-stakeholder-mapping.
• Group-level impact for the group from change-and-communications:people-change-impact.
• Listening data at group level: pulse comments, questions from sessions, manager and change network themes, support themes.
• The agreed answers on jobs, monitoring and data from change-and-communications:ai-communication-strategy.
• Any formal representations, handled through HR.

If listening data is thin, gather it before acting: a short facilitated session or a few conversations through managers and the change network. Do not diagnose a group from one loud voice or from the programme's assumptions.

Decision framework

Diagnose the cause, then choose the response that fits it. Several causes often apply at once.

Classify each concern before responding: a legitimate risk to fix, a gap to close (time, guidance, access), an unanswered question to answer, or a misunderstanding to correct. Legitimate risks are fixed first, not communicated around.

Practitioner approach

Start by listening, not persuading. Arrange a session with the group, facilitated by someone they trust, and ask what worries them about the change, what would need to be true for them to be comfortable, and what they have heard. Record themes, not names. Make it clear that raising concerns is welcome and has no consequences.

Diagnose before responding. Use the cause table and look for the root. A team that says "it gets things wrong" may have been given an unsuitable scenario, may have a genuine quality issue with an agent's knowledge, or may be voicing a deeper fear about their role. Check impact ratings, support themes and what their managers have said. Test the diagnosis with the group's manager and change agent.

Take legitimate concerns seriously and visibly. When resistance reveals a real problem - an overshared site, a scenario that does not work, an agent drawing on stale content, a use that troubles people ethically - fix it or route it to the owner, and tell the group what changed because they spoke up. Nothing reduces resistance faster than seeing concerns acted on. Ethical objections go to the responsible AI process; they are not a communications problem.

Answer fears with agreed facts. On jobs, the sponsor and HR must give the honest position, including what has not been decided. On monitoring, the DPO must confirm what usage information exists, who sees it and for what purpose, and the statement must match the configuration. Vague reassurance makes fear worse.

Use credible voices. Sceptical professionals listen to peers in their profession, not to programme enthusiasm. Involve sceptics in testing scenarios; they are often the best at finding the limits, and when they find a valuable use their endorsement carries weight. Never use them as targets for persuasion.

Respect choice where it exists. Where policy allows people to choose whether to use an AI experience for a task, say so plainly. Pressure to adopt in those cases produces the shallow, unverified use the programme least wants.

Track themes over time at group level. Resistance that persists after the root cause is fixed often signals another cause, such as fatigue or a manager who is not on board. Feed what you learn into the communications strategy, manager enablement and the impact assessment, and report themes to the sponsor in the monthly change update.

Outputs

• A resistance diagnosis by group: concerns in the group's words, classified causes, evidence and the agreed response with owner and date.
• A "you said, we did" summary for each group showing concerns acted on.
• Referrals to owners for legitimate risks: security, data protection, responsible AI, knowledge owners, HR.
• Updated concern answers for the questions-and-answers section of the ai-communications-plan.

Microsoft platform considerations

Many fears concern what Microsoft AI experiences can access, store or reveal. Answer them from the organisation's configuration and the current source records in references/sources.md, especially the privacy records, and involve the security lead when a concern reveals a real permissions or oversharing issue.

Adoption considerations

Resistance is often the first sign that onboarding, scenarios or support do not fit a group. Share diagnoses with the adoption lead so the group's journey can be adjusted rather than repeated louder.

Knowledge considerations

Quality scepticism frequently traces to poor knowledge: outdated pages, conflicting documents or content an agent should not use. Pass these findings to knowledge-management:knowledge-gap-analysis and tell the group what was fixed.

Security and privacy considerations

Listening data is collected and reported by theme and group, above the minimum group size, with no attribution to individuals. Concerns that reveal a possible data exposure follow the security route immediately. Questions about employee monitoring and data end with the DPO and HR.

Responsible AI considerations

Ethical objections and concerns about fairness are routed to the responsible-ai department and may stop or change a use. Never treat a principled objection as a barrier to be overcome by communications.

Evaluation requirements

Not applicable as solution evaluation. The response is checked by whether the group's concern themes change after the action, through a follow-up conversation or pulse at group level.

Value measures

Owned by the change lead: concerns with an agreed response, time from concern raised to response, share of legitimate risks fixed, and group-level pulse items on confidence and willingness to raise concerns, against the first listening baseline. Never reported for individuals.

Scale notes

Starter

A facilitated conversation with each concerned group, a short concern log and a "you said, we did" note, led by the adoption lead and HR.

Scale

A standing concern log fed by the change network and managers, monthly theme review, and agreed answers maintained centrally.

Enterprise

Common cause categories across divisions, formal engagement with employee representative bodies through HR, and theme reporting to the enterprise sponsor forum.

Hand-offs

• To change-and-communications:ai-communication-strategy to update answers and messages.
• To change-and-communications:manager-enablement when managers need support to handle concerns.
• To responsible-ai:ai-impact-assessment for concerns about how a solution affects people.
• To copilot-adoption:role-based-adoption when a group's journey needs redesign.

Reviewer gates

Not applicable as a formal gate, because resistance management does not release a solution. Concerns that point to risk in a solution at tier 2 or above are passed to its responsible-ai and security-privacy reviewers.

Failure modes

• People who raise concerns are labelled resistors, and others stop speaking up.
• Legitimate risks are treated as communication problems and remain unfixed.
• Vague reassurance on jobs or monitoring increases fear rather than reducing it.
• More pressure is applied to a fatigued group, producing token use and resentment.

Sources

references/sources.md in this skill lists the source records behind this skill, what each is authoritative for, how volatile it is and what you may do with it. Product availability, licensing, limits and preview status change often, so check the current source before stating them, and cite what you used.

Never

• Label, list or report named individuals as resistant.
• Penalise anyone, formally or informally, for raising a concern about AI.
• Argue away an ethical objection instead of routing it to the responsible AI process.
• Offer reassurance on jobs, monitoring or data that has not been agreed and is not true.