Why teams resist AI

Every month, one question about AI in teams: how roles change, where processes break, and what to do about it. This is The Human Loop.

The first issue: why teams resist AI — and what to do about it. Inside: a map of six sources of resistance, five positions people take, an E2E-team case, the diagnostic, the AI adoption checklist, and the AI Resistance Map as a working template.

AI has already entered team work. There are very few people left who have never opened an assistant, tried code generation, or met AI somewhere in their workflow.

So the useful question has changed. Why does one team turn AI into a habit, another into shadow practice, a third into reporting theater, and a fourth into a conflict about responsibility?

What looks like resistance on the surface can point to an unclear goal, fear about the role, a weak tool, implicit responsibility, or an overloaded flow of work. Training alone will not fix those problems.

Over the last year I have seen this pattern across several dozen engineering teams. First, a company gives people access, runs training, and starts measuring simple adoption signals: who opened the tool, who completed a course, who marked a task as done with AI. Activity grows in the reports. Delivery metrics — Lead Time, Throughput, and the broader Time to Market — move much more slowly, and often do not move at all.

From the outside, all of this looks like AI adoption. From the inside, I see four different scenarios:

1. Habit: the assistant becomes part of the normal day: sketching code, writing tests, understanding legacy.
2. Shortcut: people quietly use personal subscriptions because the official tools at work are slower and less useful.
3. Reporting ritual: people open AI tools before demos so the usage report looks better.
4. Conflict about roles and responsibility: who owns the change if an agent suggested it, a human accepted it, the release failed, and the customer came back angry?

For people leading AI adoption, the important part is the work itself: where AI becomes a useful habit, and where it exposes old disagreements about quality, responsibility, and flow. The same signal appears in recent reports from BCG (AI at Work — 2026), Microsoft (Work Trend Index — 2026), and LexisNexis (Future of Work Report — 2026).

AI adoption progress matters. It is not the goal

When a company invests in AI, leadership wants to see an effect. The logic is understandable: infrastructure is built, subscriptions are paid for, training budgets are approved. People want to see a result and, at some point, a return.

The easiest way to show progress is to count:

• who received access;
• who completed training;
• who opened the tool;
• who marked a task as completed with AI;
• who showed a demo.

Prosci makes a useful distinction: activity around a tool is not the same as a change in work. Licenses, access, training completion, and usage frequency show that people have touched AI. Adoption starts when behavior changes: the tool is embedded in the workflow, people trust the result, understand the rules, and can connect the practice to business effect.

When usage frequency becomes the target, the system quickly learns to show activity. Goodhart’s law kicks in: when a measure becomes a target, it stops being a good measure.

People open the tool more often, add “done with AI” labels to tasks, show a few successful demos — and the adoption statistics look better.

In a large fintech context where I work, this is visible across an engineering contour of roughly a thousand people, split between IT and line-of-business roles.

• Simple habit signals grow as expected: more tool logins, more training participants, more demos in meetings.
• Delivery metrics such as Lead Time and Throughput either do not move or move insignificantly.

At the same time, hidden work grows. CodeRabbit has reported that errors in PRs from agents are found more often, rollbacks increase, and service availability suffers. Harness (State of Engineering Excellence — 2026) describes a similar pattern: AI accelerates part of development, while queues, validation time, review load, hidden work, cognitive load, and fear of metric misuse also grow.

In short: adoption metrics can grow faster than the organization’s ability to work with AI safely.

That is why I prefer to look at several layers of metrics:

1. AI tools becoming a working habit.
2. Agents entering the SDLC.
3. Flow metrics moving in the intended direction.
4. Quality and balancing metrics, so speed does not create production damage.
5. AI costs.

In habit metrics, two numbers matter to me: Monthly Active Users and the share of people who use AI on more than half of their working days. In flow, I look at Lead Time, Throughput, and Defect Rate. In AI penetration across the SDLC, I look at how many tickets agents handle end-to-end and how many tickets they touch at least at one stage. A habit of using AI without a change in flow metrics is adoption theater.

“Resistance to AI” is a facade

“Resistance to AI adoption” is a facade that hides different causes. Prosci (Why Your AI Rollout Stalled — 2026) lists several of the main ones:

• people do not understand which working goal AI is supposed to improve;
• they fear losing autonomy, status, or their profession;
• they do not have enough practice to embed the tool into a real day;
• they try the official assistant and get a slow product that is blind to context;
• they are ready to work with AI if review and responsibility rules are clear.

I would put it more simply: people resist AI when they do not see why it matters to their work, fear looking incompetent, do not know how to use the tool on a real task, or feel that the decision was made without them.

A large share of AI implementation difficulties is connected to human factors rather than technical limitations. The biggest block is user proficiency: lack of knowledge, unclear value, and too little practice in real work.

If we respond to all of these cases in the same way — “let’s run training” — the problem will remain. Each source needs its own action.

Training helps when the missing piece is skill and practice. It does not fix a bad tool, unclear responsibility, or too much extra work in review and validation. Prosci (Why Your AI Rollout Stalled — 2026) and Harness (State of Engineering Excellence — 2026) converge on the same point: AI adoption often breaks at the level of the work system around the tool.

Resistance is more useful as diagnosis than as a refusal to use a new tool. It shows which part of the work system is not ready for AI yet.

If we look only at adoption reports, the four teams from the opening can look almost identical: the tool exists, activity exists, movement exists. In real work, they are four different management problems. That is why resistance needs to be mapped as a set of causes.

The tool: AI Resistance Map

The AI Resistance Map is a working template for one team or several teams. In this issue it helps stop arguing with the symptom and see what the symptom points to in the work system.

The logic is simple:

1. identify the source of resistance;
2. understand the position of the person or group;
3. choose an action that fixes the real cause.

The same symptom can point to different problems

The full template has six sources. The route is simple: first understand the source of resistance, then the person’s position, then choose the action. Below are three layers where this logic is especially useful: people behavior, engineering responsibility, and work flow.

The six sources are:

• purpose and metrics;
• role and growth anxiety;
• capability and tool quality;
• environment and rules;
• responsibility;
• flow.

The point is to see the problem behind the symptom:

• “AI writes garbage” is a signal to check tool quality, context, prompting skill, and rules for checking the result.
• “I won’t be responsible for code written by an agent” points to ownership: who owns the result, what evidence of validation is needed, and where the human makes the final decision.
• “We don’t have time to figure this out” points to flow: whether the team has the time and space for first experience, or whether AI adds another layer of work to an already overloaded system.
• “We are just being forced to use it” points to purpose and involvement: people see an adoption campaign, not an improvement in their work.

This brings us back to the four opening stories. The first team has a working habit. The second has a tool-quality and environment problem. The third has metrics and ritual usage. The fourth has responsibility questions and productive skepticism.

It is important to distinguish a skeptic, a ritual adopter, and a saboteur

The source of resistance and the person’s behavior are different things. The same source requires different actions depending on the person’s position.

Take the absence of rules. A skeptic raises responsibility and quality concerns. A ritual adopter formally opens the tool for the report. A supporter of AI can create risk by bypassing security rules with good intentions.

For the map, it helps to distinguish five positions:

• supporter — experiments and helps others;
• productive skeptic — raises real risks and testable questions;
• avoider — quietly avoids use and returns to the old process;
• ritual adopter — uses AI formally to look compliant;
• active blocker or saboteur — breaks agreements, hides information, blocks experiments, or discredits the change in bad faith.

The most important boundary is between productive skepticism and sabotage.

A skeptic can protect quality, security, ownership, and the team’s development path. When a person asks for review rules, quality criteria, and responsibility boundaries, they often protect the system from accidental damage. BCG (When Everyone Uses AI — 2026) writes about the risk that mass AI usage, driven by adoption metrics, can weaken critical skills and reduce the stability of maintained systems. California Management Review (Upskilling to Accountability — 2026) argues that stable AI adoption needs engineered accountability: critical review of agent outputs and at least two approvals before production.

That kind of skepticism should be translated into criteria, rules, and experiments.

Sabotage needs a different conversation: explicit expectations, a management boundary, and consequences. It should not be hidden under the word “resistance” and treated with another training session.

Engineering layer: who owns the result

On the map, this is the responsibility zone: who owns the result and who is accountable for consequences. In software development, this question appears very quickly.

AI assistants can make routine work easier. People can complete their part faster while steering an agent.

Because of that, more changes appear. At the same time, people may not check agent-written code and related artifacts deeply enough. The human still owns the result.

In those cases, code review turns into an investigation of someone else’s conversation with an assistant. The reviewer has to understand the change itself and reconstruct the agent’s context: what constraints it received, which files it did not see, and what assumptions it made.

Qodo (AI Coding Paradox Report — 2026) reports incidents caused by AI-generated code, subtle bugs, and guardrail failures. Harness (State of Engineering Excellence — 2026) adds review load and validation time to the picture. So when developers say, “I would rather write it properly myself than give it to an agent,” it is often not fear or stubbornness.

Often it is a request for a working agreement:

• which types of tasks can be delegated to AI;
• where a human must check and decide;
• what validation evidence should be present in a pull request;
• who owns the result after release;
• which checks are mandatory before merge;
• which data and contexts must not be given to the tool.

Without these rules, AI speeds up code generation while increasing anxiety about responsibility for the final result.

Even when one team builds a rule system for AI work, problems downstream or upstream can wipe out local gains. This is where we zoom out from one team’s local work to the whole end-to-end value-delivery chain.

Flow of work: local speed hits the system

Flow is the layer that is almost invisible in adoption numbers.

AI can accelerate a local part of the work while overall Time to Market stays almost the same.

I have a concrete example. A small E2E team had two engineers with broad responsibility and one business expert. Inside that contour, work really did get faster: the team shipped more changes, and the time from starting work to a ready change shrank by roughly 1.5x. That was local acceleration inside one part of the flow, not acceleration of the whole path.

End-to-end delivery did not speed up proportionally.

Neighboring teams, departments, and line units kept working at the old pace. The small contour finished its part faster and then waited while adjacent groups carried the change through their own parts of the system.

For me, this example matters because AI worked inside the contour. The team became faster. The constraint was not inside the team; it moved to the next turn of the development cycle: adjacent teams, checks, release rules, and business validation still operated at the old pace.

This is not a team failure. It is a system property. In that situation, resistance from neighboring teams can be a reaction to the pressure that local acceleration creates elsewhere in the flow.

AI and agentic engineering can radically accelerate generation, tests, and change preparation. Then the work passes through review, architecture, security, legal checks, release, support, business validation, user training, and management decisions.

If those boundaries are not redesigned, local speed becomes a queue at the next stage.

BCG (AI at Work — 2026) puts it directly: strategy matters more than tools. Value appears when companies redesign work around AI, not when they simply hand out access. Microsoft (Work Trend Index — 2026) describes a similar shift: work is rebuilt around people and agents, and roles move toward Author, Editor, Director, and Orchestrator. In its Transformation Paradox section, Microsoft also shows how pressure from current goals competes with the redesign of work.

Without flow redesign, AI often accelerates the place where work is created and leaves unchanged the place where work becomes a result.

When there is more than one team, resistance stops being a question of personal habit and becomes a question of operating model.

Organizational layer

At the organizational level, everything becomes harder. One team can make an agreement. With multiple teams, politics, security, budgets, job-loss fear, and KPI conflict appear at the same time.

Larger organizations need conditions for AI work:

• a clear goal and a link to work outcomes;
• role-specific training on real tasks;
• a DevEx / platform backlog to remove tool barriers;
• rules for data, secrets, security policies, and logging;
• criteria for evaluating the tool so a weak tool does not become the standard;
• team agreements for working with AI — an AI Working Agreement;
• review and ownership rules;
• effect metrics rather than activity metrics: Lead Time, review time, defect cost, support load, time to confident use, business result.

LexisNexis (Future of Work Report — 2026) captures the governance problem: AI usage grows faster than internal policies, training, and understanding of agentic processes. Shadow AI appears where teams lack accessible tools, clear rules, and a working governance loop.

People often bypass process because the official path is inconvenient, not because they are trying to cause harm.

If the official tool is worse — access is harder, rules are unclear, results are not good enough, and the task is urgent — the team will find a shorter route.

As managers, we should ask: which piece of a comfortable and safe environment have we not built yet, if people find it more useful to go around us?

What to do with resistance

The first step is to run the diagnostic and see which problems repeat: unclear purpose, role and growth anxiety, missing capability, weak tool quality, unclear responsibility, or local acceleration that hits the flow.

In the diagnostic, each question is connected to one of the six sources of resistance. If a team often chooses “Often” or “This is our norm” on a primary question, or “Not us” on a control question, that is a signal to examine the zone further.

After the diagnostic, use the AI Adoption Checklist to choose the first action for the adoption stage you are actually in. Then move one to three red zones into the AI Resistance Map and turn them into a concrete team agreement or experiment.

In my People Sense talk about AI, I came to a simple working link: behind each form of resistance is a missing type of support.

• No “why” → show personal work value. Not the company’s general strategy, but a specific gain in a person’s work: understanding legacy faster, preparing test cases, drafting a document, or removing routine from a recurring task.
• Fear of looking incompetent → start with a small safe group. Large webinars create awareness, but they rarely help with the first uncomfortable step.
• People do not know how → give them a real task and an expert nearby. The best format was a 1.5-hour session: environment setup, a task from the real backlog, the participant driving, and the expert as navigator.
• “Nobody asked us” → let people participate in designing the practice. QA, analysts, developers, and DevOps use AI differently and check quality differently. When a role helps design the workshop, reusable artifacts appear: templates, safe-use rules, task examples, quality criteria, prompts for agents.

In short: resistance often decreases after the first safe experience on a real task, not after another round of persuasion.

After diagnosis, choose the action. The source shows which part of the system to fix. Use it as a working sheet for the team: pick a recurring pattern and turn it into a concrete agreement or experiment.

In practice, the first move should be as close to work as possible. In my teams, small working formats worked best: mini-groups, real tasks, an expert nearby, a tech lead who shows the first example, and regular experience exchange every sprint. This turns resistance from abstract “people don’t want it” into a concrete question: which piece of the system needs to be built?

What does not work in adoption?

From the last year of experience, I would separate out the things that look logical but weakly change behavior:

• email campaigns and large webinars create awareness, but rarely create a habit;
• a tool registry does not make people use the tools;
• demos of “look how the agent moves a ticket and pushes to git” create interest, but do not remove the blank-page problem;
• a mandate to “use AI” quickly turns adoption into a reporting ritual;
• training without leaders does not become a team norm.

The working scenario was different: first a safe first experience, then repeatable team events, then a leader as an example, then metrics that look at activity, delivery, quality, and return together.

A person’s position changes the conversation and their role in the change.

Use the AI Adoption Checklist to choose the stage-level action, then put the intersection logic into the AI Resistance Map: it shows how the source of resistance and the person’s position change the next working move.

Practical artifact

In practice, the route is: first the diagnostic highlights recurring problems, then the AI Adoption Checklist helps choose the next action, and then the AI Resistance Map turns one to three red zones into team agreements for working with AI — an AI Working Agreement. The map is an entry point into those agreements: first the team sees recurring problems in the work system, then it translates them into rules and experiments. In the minimal version, the team chooses two or three recurring zones and drafts rules:

• what can be delegated to AI;
• where a human must stay in the loop;
• how review works;
• who owns the result;
• which data and contexts are allowed;
• which checks are needed before production;
• which metrics show delivery effect rather than usage theater.

The point of the workshop is to make the hidden parts of the work system explicit: where the human must remain the owner of meaning, validation, and responsibility.

Final

AI quickly reveals how work is actually organized inside a team.

A goal that is hard to translate into concrete steps creates arguments about meaning. An inconvenient tool pushes people into shadow practice. Unclear responsibility makes engineers resist adoption and refuse to guarantee quality. Pressure on activity metrics creates a beautiful AI-adoption dashboard with little real change.

In that sense, resistance to AI is useful. It shows the place where the team has not yet made an agreement.

A practical first step for the next sprint:

1. Choose one recurring problem in AI work: goal, skill, tool, rules, responsibility, or flow.
2. Describe where it appears in a real task: what slows the work, what risk it creates, who it affects.
3. Turn the problem into one testable agreement or experiment.
4. Run a mini-workshop on a real task: participant driving, expert nearby.
5. In a few weeks, check four layers: whether a habit appeared, whether delivery metrics changed, whether quality suffered, and whether there is a link to the result.

AI does not make an organization faster by itself. It quickly exposes the places where work used to depend on habit, heroism, and silent agreements.