Organisational psychology
Resistance to AI change: understand the objection
Understand resistance to AI at work: separate valid risks from missing skills, clarify responsibilities and design a pilot people can evaluate.
You introduce an AI tool, run a demonstration and make access available. A few people experiment; others continue with the previous workflow. Calling the second group resistant gives the situation a name, but gives you little guidance about what to do next.
An objection can contain several different problems: the output is unreliable, the task is poorly chosen, the learning effort is unplanned, or people do not understand what happens to their responsibilities. Each needs a different response. A message about embracing innovation cannot resolve all of them.
The useful first step is to identify what the person is protecting or questioning. Then make the change specific enough to evaluate: a defined task, an accountable owner, a quality standard and a route back when the tool is unsuitable.
Stop treating resistance as a personality trait
A person may welcome automation in one task and reject it in another. That is not necessarily inconsistency. Drafting an internal outline and sending a contractual answer to a customer carry different consequences.
Ask about the work rather than the person’s attitude. Which step becomes easier? Which responsibility becomes less clear? What happens when the answer is wrong? Who has time to review it? What current practice must disappear to make room for the new one?
Keep the answers distinct. “I do not know how to use it” is a skills issue. “It misses an important exception” is a quality issue. “My manager expects the old and new process simultaneously” is a capacity issue. “I do not know whether this changes my role” concerns the employment relationship and requires an honest organisational response.
Do not use a workshop to manufacture agreement on an unresolved decision. Say which parts are open to influence and which have already been decided.
Define usefulness at the level of a task
Fred Davis’s technology acceptance research examined perceived usefulness and ease of use. It predates contemporary generative AI; it is a lens for asking questions, not evidence that your deployment will succeed.
Instead of promising that AI improves productivity, describe the proposed work change. For example: the tool drafts a summary from an approved set of meeting notes; the project owner checks decisions and actions before sharing it. Name the source material and the review obligation.
Then compare that process with the existing one. Include preparation, correction and approval time, not just generation time. If producing a draft is quick but checking it requires more effort than writing the original, a colleague’s reluctance may be a reasonable assessment of the task.
Use team cognitive load to examine additional checking and information handling. The new tool should not be judged only by how quickly it produces something.
Take quality and responsibility objections seriously
AI output can look plausible while requiring verification. People need to know what they may rely on, what they must check and when they should stop.
The NIST AI Risk Management Framework provides a voluntary framework for managing AI risks. Its relevance here is the need to connect the intended use with responsibility, measurement and response; it is not a certificate for a tool or a deployment.
For the chosen task, specify permitted inputs, excluded use cases, quality criteria, human review and the escalation route. Use real organisational policies where they exist. If a question depends on security, privacy or legal approval, route it to the appropriate owner rather than answering with reassuring copy.
A responsible pilot can reveal that the tool should not be used for a task. Make that a legitimate outcome. Otherwise participation becomes an exercise in validating the sponsor’s preferred decision.
Make learning time part of the change
A training invitation does not create spare capacity. If people still owe the same delivery commitments, they may postpone learning even when they are interested.
Agree what time and support the pilot needs. Give participants examples of acceptable and unacceptable outputs. Practise on material that the organisation permits for that purpose. Start with a task they understand, so they can judge the result instead of learning the domain and the tool simultaneously.
Offer a place to ask basic questions without public comparison. Different starting points are normal; a leaderboard of prompt counts rewards activity rather than competence.
Also decide what support looks like after training. A colleague who understands the tool may help with a difficult case, but should not become an unpaid permanent helpdesk alongside a full workload. Assign the support role, its capacity and the route for issues it cannot solve.
Explain the role implications without false reassurance
People may ask whether AI changes their work, their development path or the number of roles needed. Do not dismiss these concerns as an emotional barrier to adoption.
Separate what is known from what has not been decided. Explain the current scope and who can answer employment questions. Avoid promising that nobody’s job will change if you cannot substantiate that promise. Equally, avoid threatening people with replacement to obtain participation.
A manager can discuss how the immediate task changes: what judgement remains with the person, what the tool drafts, and which new responsibility appears. Longer-term staffing or contractual issues belong in the organisation’s relevant decision and consultation processes.
The motivation and autonomy guide helps distinguish meaningful choice from a request to endorse a decision already made.
A hypothetical pilot with a reasonable objection
Imagine a marketing team testing AI-generated campaign briefs. This is a hypothetical example. The sponsor expects faster drafts. A strategist objects because the draft frequently omits campaign exclusions and confuses audiences.
Rather than framing the objection as reluctance to change, the team documents examples. It limits the pilot to briefs prepared from an approved input sheet and keeps audience selection with the strategist. An explicit review checks exclusions before the brief reaches production.
The comparison includes time spent creating the input, reviewing the draft and correcting misunderstandings. Participants can also record when the previous method was preferable. The tool is not used on a live brief until the team understands the failure modes.
At the review, the sponsor assesses the evidence against the agreed task criteria. A faster first draft would not by itself justify rollout. The team might narrow the use case, improve the input or stop. The example demonstrates a decision process, not an achieved result or a client experience.
Classify objections with this worksheet
Use the table in individual conversations and then combine issues that genuinely share a cause. Ask the participant to confirm the description before you assign a response.
Swipe or use the arrow keys to see every column.
| Objection | Question to investigate | Possible response | Evidence to review |
|---|---|---|---|
| Quality | Which case fails, and how? | Narrow the use case or improve verification | Documented errors and correction effort |
| Skills | Which step is unfamiliar? | Task-specific practice and support | Completion with appropriate help |
| Capacity | What work competes with learning? | Allocate time or reduce simultaneous demands | Actual review and learning effort |
| Responsibility | Who answers for the output? | Clarify approval and escalation | Decisions made without ambiguity |
| Role impact | What change is known or undecided? | Give an honest organisational answer | Clear scope and named decision owners |
| Fit | What benefit does this task need? | Compare the whole workflow or stop | Task quality and total effort |
The table is not a survey scale or an employee classification system. A person can raise more than one type of issue. Do not record a private concern in a public “resistance register” that follows the employee beyond the pilot.
Measure adoption without confusing it with value
Logins, prompt counts and training attendance show activity. They do not show that the work improved. Forced use can increase all three while increasing correction effort or reducing trust.
Choose task-level evidence: output quality, time including review, relevant errors, and the work that must be repeated. Add feedback about responsibilities and workload. Specify which cases the evidence represents and which remain outside the pilot.
A before-and-after comparison is useful operationally, but other changes may explain the difference. A different campaign, a more experienced reviewer or lighter workload can affect the result. Describe the limits instead of presenting the observation as a causal proof.
Avoid ranking individual employees by AI usage. Their tasks and risks may differ. Study whether the chosen workflow fits the work, then decide where expansion is justified.
Keep disagreement available after rollout
A successful pilot does not remove the need to report problems. Inputs, models, policies and tasks can change. Name the owner who reviews those changes and the person who can suspend an unsuitable use case.
The psychological safety guide explains how to respond when somebody raises inconvenient information. If reporting a problem is treated as opposition to innovation, your adoption programme loses a valuable source of quality evidence.
For the wider organisational setting, use the organisational psychology guide. The customer-facing equivalent is the distinction between observed behaviour and interpretation in consumer psychology.
Start with one objection that you can examine this week. Obtain an example, identify the accountable owner and decide what evidence would resolve the issue. Sometimes the most useful adoption decision is changing the task before asking more people to use the tool.
If your AI pilot has activity but little agreement on value, tell me which workflow you are changing. We can define the task, the review responsibilities and a pilot decision that the team can evaluate.
Apply this to your project
Tell me the decision you are facing, the constraints and what you have already tried.
Keep exploring
Organisational psychology: a practical team guide
A practical guide to organisational psychology for digital teams: understand friction, clarify decisions and improve how people work together.
Motivation at work: give autonomy a clear shape
Understand motivation and autonomy at work: clarify choices, support competence and design responsibilities people can exercise in practice.
Organisational culture: look at everyday behaviour
Understand organisational culture through decisions, rewards and everyday responses, then turn stated values into working practices you can review.