AI resistance shows which part of the work system is still missing: purpose, role, skill, environment, accountability, or flow.

This guide begins where diagnosis ends. If an area is red, open the relevant section and choose 1–2 actions for the next sprint.

People’s positions are not personality types. The same person can be an advocate in one scenario, a productive skeptic in another, and an avoidant participant in a third. The source of resistance shows what needs to be fixed. A person’s position shows how to act.

Table of contents

Before starting, you can take the interactive diagnostic, open the resistance map, and check yourself against the AI adoption checklist.

1. Purpose and metrics

When to use

The team gives different answers to the question “why do we need AI?” Activity is rising in reports: logins, prompts, demos, enabled licenses. But the work outcome is not changing: delivery has not sped up, quality has not become more stable, support has not been relieved, and business hypotheses are not being tested faster.

What to assemble quickly

[short-term] Outcome contract for the pilot

Action: Before the pilot, define one work problem and the expected effect.

How to do it: Write on one page:

  • which scenario you are testing;
  • what pain exists now;
  • what result you expect;
  • which metric will show the effect;
  • which guardrail metric must not get worse;
  • when you will stop, change, or scale.

Result: The team stops discussing “whether we used AI” and starts discussing changes in the work.

Sources: Prosci ADKAR, DORA metrics, SPACE framework.

[short-term] Separate activity from impact

Action: Clearly separate adoption metrics from outcome metrics.

How to do it: Use activity only as an early signal: who tried it, where the first scenarios appeared, and where help is needed. Make the pilot’s goal a work outcome: lead time, review time, rework rate, operation cost, SLA, support load, or hypothesis-testing speed.

Result: Ritual use for the sake of reporting disappears.

Sources: DORA metrics, SPACE framework, BCG AI at Work.

[short-term] Choose 1–2 starting scenarios

Action: Narrow adoption to specific tasks.

How to do it: Choose scenarios with a clear input, quality criteria, and a fast validation cycle: tests, documentation, log analysis, boilerplate generation, PR-description drafting, or edge-case discovery.

Result: The team gets its first verifiable artifact, not a generic slogan to “use AI.”

Sources: Google PAIR Guidebook, Microsoft Human-AI Guidelines.

What to assemble over 1–2 months

[medium-term] AI fit / no-fit map

Action: Separate tasks where AI helps from tasks where it makes the result worse.

How to do it: After each attempt, record:

  • whether the task was inside a clear scenario;
  • what data and context were needed;
  • where AI made a mistake;
  • how a human checked the result;
  • whether the scenario is worth repeating.

Result: Both blind faith in AI and the premature conclusion that “AI does not work” decrease.

Sources: Jagged Technological Frontier, Google PAIR Guidebook.

[medium-term] Value review every 2–4 weeks

Action: Regularly review what has changed in the work.

How to do it: In a short meeting, go through four questions:

  • where AI genuinely helped;
  • where it created noise;
  • which metric moved;
  • what you will change in the next cycle.

Result: The pilot does not turn into an endless experiment without a decision.

Sources: Kotter 8-Step Change Model, DORA metrics.

What to build for a quarter or more

[long-term] A metrics layer from habit to business

Action: Connect metrics into a chain: activity → delivery → quality/constraints → business impact.

How to do it: For each scenario, specify:

  • early signal: people tried it and are repeating it;
  • delivery signal: the task moves faster or more predictably;
  • guardrail: quality, security, cost, and review load have not worsened;
  • business signal: SLA, support, conversion, time-to-market, operation cost, or hypothesis speed has changed.

Result: AI stops being a separate initiative and becomes part of the operating system.

Sources: SPACE framework, DORA metrics, McKinsey State of AI.

How to work with people’s positions

  • Advocate: Give them the role of guide for working scenarios. Ask them to show not only successes, but also limitations, checks, and the cost of errors.
  • Productive skeptic: Give them the right to formulate success criteria, risks, and conditions for stopping the pilot.
  • Avoidant participant: Give them a small task with personal value and a clear result. No public pressure.
  • Ritual user: Stop asking “did you use AI?” Ask what work artifact appeared and how quality was checked.
  • Active blocker: Set the expectation: argue through facts, risks, and testable hypotheses. Once there is a clear safe path, bad-faith disruption becomes a management boundary.

Mistakes

  • Turning the number of prompts or logins into a KPI.
  • Launching “AI for all tasks” without starting scenarios.
  • Treating a demo as proof that work has changed.
  • Scaling a pilot before the decision to “scale / change / stop.”

2. Fear for role and growth

When to use

People argue about how AI changes junior learning, expert status, the senior/lead role, and professional judgment. Some team members are afraid of looking weaker. Some experts defend the old growth model. A good quality check can be mistaken for resistance.

What to assemble quickly

[short-term] Role redesign canvas

Action: Talk through what changes in the human role.

How to do it: For each role, fill in four blocks:

  • what the person delegates to AI;
  • what they must check themselves;
  • which skills must not be lost;
  • what growth looks like now.

Result: Anxiety about replacement is translated into concrete expectations.

Sources: Prosci ADKAR, MIT Sloan / BCG Responsible AI.

[short-term] Safe first experience

Action: Give people a first experience without a public exam.

How to do it: Choose a real task, seat the participant next to a mentor, and keep the human “at the wheel.” AI suggests, the human decides and explains the check.

Result: The person gets an experience of control, not the feeling that they are being compared with a machine.

Sources: Edmondson psychological safety, Baldwin & Ford transfer of training.

[short-term] Agreement that “AI does not lower the bar for accountability”

Action: State separately that AI does not cancel professional judgment.

How to do it: Define a simple rule: a person may use AI, must understand the result, and is accountable for the outcome. If they cannot explain the decision, it is not ready.

Result: Quality-minded skepticism becomes the norm, not a sign of disloyalty.

Sources: Microsoft Human-AI Guidelines, NIST AI RMF.

What to assemble over 1–2 months

[medium-term] Growth ladder with AI

Action: Update level expectations.

How to do it: Describe what junior, middle, senior, and lead roles should be able to do with AI. For example: junior uses AI as an explanatory tool and learns to verify; middle accelerates routine tasks; senior designs checks and boundaries of applicability; lead changes the work flow and team rules.

Result: AI becomes part of growth, not a threat to growth.

Sources: Prosci AI adoption, Training transfer workplace factors.

[medium-term] Listening sessions by role

Action: Gather anxieties by role group, not through one general survey.

How to do it: Talk separately with juniors, middles, seniors, leads, QA, analysts, and managers. Record not complaints, but changes in accountability, status, learning, and decision-making.

Result: Concrete changes appear in rules, training, and expectations.

Sources: Oreg resistance to change, O’Donovan & McAuliffe review.

What to build for a quarter or more

[long-term] Updated competency model

Action: Include AI skills in role development.

How to do it: Add to the competency model:

  • task formulation for AI;
  • result checking;
  • understanding limitations;
  • the ability to explain a decision;
  • the ability to improve team scenarios;
  • mentoring others.

Result: AI stops being an optional trick and becomes part of the professional standard.

Sources: MIT Sloan / BCG Responsible AI, NIST AI RMF Core.

How to work with people’s positions

  • Advocate: Make them an example of practice, not a hero of “I replaced everyone.” Ask them to show their reasoning, checks, and mistakes.
  • Productive skeptic: Translate concern for the profession into a learning policy: which skills you preserve, what you check, and where AI must not be used as a crutch.
  • Avoidant participant: Give them private or paired practice. Allow them to say “I did not understand the AI answer” without sanction.
  • Ritual user: Ask what they learned, what they checked themselves, and where AI was wrong. Do not accept “I used AI” as a growth result.
  • Active blocker: If a person mocks newcomers or blocks others’ learning, state the role expectation: develop the team, not hold knowledge as power.

Mistakes

  • Selling AI as “now we do not need juniors.”
  • Calling every anxiety reactionary.
  • Providing training without changing role expectations.
  • Running public competitions for “who prompts better.”

3. Skill and Tool

When to use

The team tried AI, got a weak result, and decided that “AI doesn’t work.” The cause was not examined: maybe the skill was missing, the scenario was a poor fit, the tool could not see the context, the rules prevented people from providing the right data, or the task was outside AI’s useful range.

What to assemble quickly

[short-term] Skill / tool / task review after a weak attempt

Action: break every weak result down into three possible causes.

How to do it: after an unsuccessful attempt, ask whether:

  • the person knew how to frame the task and check the answer;
  • the tool had the necessary context;
  • the task itself was suitable for AI.

Result: the team does not draw a sweeping conclusion from one bad experience.

Sources: Jagged Technological Frontier, Algorithm aversion.

[short-term] Hands-on lab: the participant drives

Action: replace the webinar with a working session.

How to do it: the participant solves their own task with AI while a mentor sits nearby. The mentor does not take over the keyboard; they help formulate the request, add context, and check the result.

Result: knowledge transfers into real work.

Sources: Baldwin & Ford transfer of training, Training transfer workplace factors.

[short-term] Failure examples

Action: show not only successful prompts, but also mistakes.

How to do it: collect 5–10 examples where AI confidently made an error, lost context, invented an API, broke tests, or suggested an unsafe solution. For each one, state how a person detected the error.

Result: trust becomes calibrated: neither blind faith nor total rejection.

Sources: Microsoft Human-AI Guidelines, Google PAIR Guidebook.

What to assemble in 1–2 months

[medium-term] Scenario library based on real tasks

Action: package repeatable ways of working.

How to do it: for each scenario, describe:

  • when to apply it;
  • input data;
  • an example request;
  • quality criteria;
  • typical mistakes;
  • how to check the result.

Result: supporters’ experience stops living only in their heads.

Sources: Google PAIR Guidebook, Prosci AI adoption.

[medium-term] Backlog of AI environment improvements

Action: record what prevents the tool from working well.

How to do it: collect problems: no access to the repository, IDE, CI, internal documents, logs, safe context, fast models, or approved tools. Separate what the team fixes, what the platform team fixes, what security fixes, and what procurement fixes.

Result: “people don’t know how” does not mask a weak tool and a poor environment.

Sources: NIST AI RMF, IBM AI adoption challenges.

What to build for the next quarter+

[long-term] Evaluation harness for repeatable scenarios

Action: check the quality of AI output with more than an enthusiast’s eye.

How to do it: for important scenarios, assemble a set of test tasks, reference answers, quality criteria, and a regular run whenever the model or tool changes.

Result: the team can see where the tool has genuinely become better or worse.

Sources: Google PAIR Guidebook, NIST AI RMF Core.

How to work with people’s positions

  • Supporter: ask them to turn successful scenarios into reproducible playbooks with failure modes. Do not make them the only AI wizard.
  • Productive skeptic: give them the reviewer role: quality criteria, failure cases, thresholds of applicability.
  • Avoidant participant: give them a small safe scenario, a template, and a mentor nearby. The goal is the first working artifact.
  • Ritual user: require a checked artifact, not a screenshot of a chat with AI.
  • Active blocker: ask for facts: task, result, criteria, repeatability. If the tool is weak, fix it. If the facts are distorted after a clear request, set a management boundary.

Mistakes

  • Declaring that “AI doesn’t work” after the first weak attempt.
  • Teaching prompts without real tasks.
  • Showing only polished demos.
  • Treating the problem as a skill issue when the official tool cannot see the context.

4. Environment and Rules

When to use

The official path for working with AI is inconvenient or unclear. People bypass it, are afraid to use the tool, or use prohibited services. The rules exist in a slide deck, but the real path is slow, confusing, and not embedded into the work.

What to assemble quickly

[short-term] One-page AI use policy

Action: make the rules short and applicable.

How to do it: describe on one page:

  • what is allowed;
  • what is not allowed;
  • what requires approval;
  • which services are approved;
  • what data may be shared;
  • where to go with a non-standard case.

Result: people stop guessing and inventing their own rules.

Sources: NIST AI RMF, MIT Sloan / responsible AI.

[short-term] The official path must be easier than the workaround

Action: check the user path from idea to first result.

How to do it: walk through it manually: get access, open the tool, connect work context, understand the data rules, and get help. Measure the time and the waiting points.

Result: it becomes clear why people bypass the rules.

Sources: Sociotechnical systems, IBM AI adoption challenges.

[short-term] Exception lane

Action: provide a path for disputed cases.

How to do it: instead of “not allowed,” add a short escalation path: who is responsible, what data is needed, how many days it will take to get an answer, and how the decision is recorded.

Result: people do not hide complex scenarios or drift into shadow AI.

Sources: NIST AI RMF Core, MIT CISR / AI governance.

What to assemble in 1–2 months

[medium-term] Safe context packaging

Action: teach the team how to give AI context safely.

How to do it: prepare templates: how to anonymize data, how to provide a code fragment, how to describe constraints, and how to refer to internal documentation without leaking it.

Result: AI quality improves without violating data rules.

Sources: Google PAIR Guidebook, NIST AI RMF.

[medium-term] RACI for AI decisions

Action: define who makes decisions about tools, data, exceptions, and risks.

How to do it: specify the roles: team, platform, security, legal, procurement, engineering leadership. For each type of decision, name the owner and the response time.

Result: the rules stop being abstract and start working.

Sources: NIST AI RMF Core, Deloitte State of AI.

What to build for the next quarter+

[long-term] Amnesty / discovery for shadow AI

Action: first understand real usage, then build consequences.

How to do it: run a safe fact-gathering process: which services people use, why the official path does not work for them, what data leaves the organization, and what tasks they solve. Do not hunt for culprits in the first pass. After a convenient, safe path exists, define consequences for bypassing it.

Result: the organization gets a real picture of the risk and a chance to make the official path workable.

Sources: Oreg resistance to change, NIST AI RMF.

How to work with people’s positions

  • Supporter: make them a guide for the safe official path. Put limits on speed hacking.
  • Productive skeptic: give them the threat model reviewer role. Let them collect disputed cases and help translate the rules into the team’s language.
  • Avoidant participant: walk them through the official path in a pair. Give them a “allowed / not allowed / ask first” cheat sheet.
  • Ritual user: check whether the ritual is caused by fear of breaking the rules. Give them an approved scenario with real value.
  • Active blocker: if the person uses the rules as a weapon — “nothing is allowed” — require a specific risk and a path to resolution. If they bypass the safe official path after it appears, apply management consequences.

Mistakes

  • Writing a long policy and not checking the user path.
  • Banning everything and getting shadow AI.
  • Handing the rules to security alone without team participation.
  • Punishing workarounds before a workable official path exists.

5. Accountability

When to use

Use this when the team is unclear about who is accountable for the result if AI was involved. The author says, “AI wrote this.” The reviewer does not know what to check. The manager wants speed, while the engineer is afraid of being accountable for someone else’s output.

What to assemble quickly

[short-term] Human ownership of the result

Action: define a simple accountability rule.

How to do it: whoever assigned the task to AI and accepted the result owns the outcome. AI is not the author, reviewer, or party accountable for quality.

Result: the grey zone of “it wasn’t me, it was AI” disappears.

Sources: NIST AI RMF Core, Microsoft Human-AI Guidelines.

[short-term] AI-assisted PR template

Action: add a short PR template for work where AI was involved.

How to do it: in the PR description, specify:

  • where AI helped;
  • what the human checked;
  • which tests passed;
  • which risks remain;
  • what the reviewer should inspect more carefully.

Result: the reviewer gets context, and the author demonstrates ownership of the result.

Sources: NIST AI RMF, AI-generated PR review evidence.

[short-term] Right to reject AI-output

Action: allow people not to accept an AI result.

How to do it: use this rule: if a person cannot explain the result, verify it, or safely integrate it into the work, the result is not used.

Result: this reduces the fear of “I’ll be forced to be accountable for code I don’t understand.”

Sources: Google PAIR Guidebook, Microsoft Human-AI Guidelines.

What to assemble in 1–2 months

[medium-term] Risk-tiered review

Action: separate checks by risk level.

How to do it: low-risk changes go through a lightweight checklist. High-risk changes require additional tests, security/privacy review, pair review, or a decision from the architecture owner.

Result: the team does not slow everything down equally and does not let risky changes pass without proper attention.

Sources: NIST AI RMF, DORA metrics.

[medium-term] Reviewer enablement

Action: teach reviewers how to review AI-assisted work.

How to do it: provide examples of common errors: hallucinated APIs, missed edge cases, hidden complexity, weak tests, incompatibility with the architecture, and security/privacy risk.

Result: review stops being a moral argument and becomes a verifiable practice.

Sources: AI-generated PR review evidence, SPACE framework.

What to build for a quarter+

[long-term] Incident learning loop

Action: analyze mistakes in AI-assisted work without hunting for someone to blame.

How to do it: if an AI result led to a defect, examine:

  • where a human trusted without checking;
  • what context was missing;
  • which test should have caught the error;
  • which rule or template needs to be updated.

Result: accountability is strengthened through learning, not fear.

Sources: Edmondson psychological safety, NIST AI RMF.

[long-term] Decision log for agentic processes

Action: record key decisions for more autonomous AI processes.

How to do it: log the goal, input constraints, important agent actions, human control points, the decision made, and the owner of the result.

Result: the team gets traceability without requiring everyone to store the entire chat as legal clutter.

Sources: NIST AI RMF Core, Microsoft Human-AI Guidelines.

How to work with people’s positions

  • Supporter: ask them to create a model AI-assisted PR. Make sure speed does not bypass review.
  • Productive skeptic: give them ownership of the risk checklist and review rubric. Translate “I won’t be accountable for this” into a list of proofs after which accountability is reasonable.
  • Avoidant participant: give them a paired task and a small verification checklist. Allow them to reject AI-output if they cannot explain it.
  • Ritual user: remove the “AI used” checkbox. In review, ask: what did you check, which tests passed, and what risk remains?
  • Active blocker: if they demand an impossible level of proof for low-risk changes, agree on risk levels. If they hide AI involvement after a clear disclosure rule has been set, apply management consequences.

Mistakes

  • Shifting accountability onto AI.
  • Requiring a full transcript instead of short evidence/context.
  • Checking every change with the same heavyweight process.
  • Treating disclosure as a substitute for tests and review.

6. Flow

When to use

Use this when AI has accelerated coding, but end-to-end delivery has not changed. The queue has moved to review, QA, security, release, business validation, or support. Developers feel faster, while the delivery system shows waiting.

What to assemble quickly

[short-term] AI work-flow map

Action: draw the path of a task from idea to result.

How to do it: mark the stages: task definition, development, review, tests, security, release, and business validation. For each stage, specify work time, waiting time, queue, and AI’s role.

Result: the team sees where AI accelerated the work and where the bottleneck moved.

Sources: DORA metrics, Sociotechnical systems.

[short-term] Protective review constraint

Action: do not let AI generate more work than the system can check.

How to do it: introduce a WIP-limit for open PRs, a PR size limit, or an explicit policy of small changes. Watch the review queue separately.

Result: local acceleration does not become overload at the neighboring stage.

Sources: DORA metrics, AI-generated PR review evidence.

[short-term] Flow observation board

Action: look beyond coding speed.

How to do it: choose 4–6 signals: lead time / time to market, review time, PR size, share of rework, change failure, number of tasks in the queue, and time to business validation.

Result: the discussion returns to how the task moves through the whole system.

Sources: DORA metrics, SPACE framework.

What to assemble in 1–2 months

[medium-term] Start with bottleneck role

Action: implement AI where the bottleneck is, not only among developers.

How to do it: if the queue is in analysis, help analysts. If it is in QA, help with test design and automated tests. If it is in review, improve PR size, descriptions, and pre-checks.

Result: AI starts changing the end-to-end flow, not just local busyness.

Sources: DORA metrics, McKinsey State of AI.

[medium-term] Reduce batch size

Action: use AI for smaller and more frequently reviewed changes.

How to do it: ask AI to help split tasks, prepare small PRs, write tests, update documentation, and create a clear description of the change.

Result: review and release become more stable.

Sources: DORA metrics, SPACE framework.

What to build for a quarter+

[long-term] Adoption package for the next team

Action: scale a working package, not a slogan.

How to do it: after the pilot, assemble:

  • scenarios that worked;
  • constraints;
  • before/after metrics;
  • review rules;
  • WIP-limits;
  • templates;
  • mistakes;
  • conditions where the approach should not be repeated.

Result: the next team gets a ready way of working, not an inspirational presentation.

Sources: Kotter 8-Step Change Model, Prosci ADKAR.

How to work with people’s positions

  • Supporter: give them the task of showing system-level impact, not only personal wins. Limit the role of “PR generator.”
  • Productive skeptic: ask them to find where the queue moved, where rework increased, and where quality losses appeared.
  • Avoidant participant: check for overload. Reduce WIP, give protected learning time, and choose a scenario that reduces pain at the bottleneck stage.
  • Ritual user: remove activity reports. Watch the movement of work: stage time, queue, quality, and rework.
  • Active blocker: separate an honest overload signal from deliberate blocking. Fix overload through capacity and WIP. Deliberate disruption of agreements after an explicit agreement has been made is a management boundary.

Mistakes

  • Measuring code-writing speed while ignoring delivery.
  • Accelerating development when review is overloaded.
  • Scaling before the pilot is stable.
  • Excluding QA, security, analysis, DevOps, and business validation.

Quick 30–60–90 plan

First 30 days

  • Run the diagnostic and choose one red zone.
  • Define an outcome contract for one pilot.
  • Choose 1–2 scenarios on real tasks.
  • Run a hands-on session: the participant is at the keyboard.
  • Introduce the rule: a human owns the result of AI-assisted work.
  • Map the current task flow and find the queue.

Days 31–60

  • Build a library of scenarios and failure examples.
  • Update the rules: allowed / not allowed / ask first.
  • Add an AI-assisted PR template.
  • Introduce risk-tiered review.
  • Run a value review and decide whether to scale, change, or stop.
  • Separate AI activity from outcome metrics.

Days 61–90

  • Update expectations for roles and growth.
  • Build a backlog of improvements to the AI environment.
  • Set up a flow observation board.
  • Package the adoption kit for the next team.
  • Review governance: roles, exceptions, accountability, and escalation.
  • Decide on scaling only after validating the outcome and guardrail metrics.

Sources