Surf explains why teams sabotage AI adoption in product development

Surf executives have described a typical pattern by which teams come to accept AI in development, from sharp denial to a working equilibrium. The central point: failed rollouts are more often about how managers handle people's resistance than about the quality of Copilot, ChatGPT or Claude.

It's not the technology

The authors suggest treating AI adoption as a management problem, not only a technical one. In their observation, the same model brings speed and savings in one company, while in another it causes quiet sabotage, token usage and irritation.

The difference appears when an experienced developer stops being merely an executor and has to learn a new role: setting tasks for a machine, checking the result and making a decision, even if that decision looks different from what they would have done themselves.

This change of role hits professional identity. For some specialists, value has long been built around personal skill: writing code by hand, holding context in their head, making quick local decisions. When AI starts doing part of that work, the reaction is often perceived not as interest in a new tool but as a threat to accumulated expertise. It is especially painful for strong individual performers who are used to proving their worth through the quality of their own craft and are not ready to switch immediately into an orchestrator or reviewer mode.

Five stages of acceptance

Surf links a team's reaction to the logic of the stages of accepting change, familiar from the Kübler-Ross model. The authors do not claim an academic typology, but consider it a convenient practical framework for managers and leads. It helps tell ordinary adaptation from sabotage and understand when a person needs not another call about the benefits of AI, but concrete support, error review and a safer format for learning the new tool.

• Denial. The developer tries AI expecting to quickly prove it useless and, after the first failure, draws a conclusion about the technology rather than about their own approach.
• Anger. If colleagues succeed at something, the urge appears to discount their result and argue it is not real work but a dangerous imitation of quality.
• Bargaining. For the first time the thought arises that the problem may lie not in the tool but in how the person uses it; this is the best point for mentoring.
• Euphoria. After the first successes the pendulum swings the other way: it seems almost everything can now be automated, and people take on excess promises.
• Equilibrium. AI stops being either a threat or magic and becomes simply a working tool with understandable limits.

"This doesn't work, and I'm going to prove it to you."

The authors also single out an intermediate state in which a specialist already sees others' successes but, instead of adjusting the process, begins to doubt themselves. This mode does not always look like direct resistance, but it also slows adoption: the person fears making mistakes, loses energy and drifts into imitating use instead of real practice. For a manager this is an important signal: not every weak result means hostility; sometimes the team simply lacks safe feedback and a clear way to learn from missteps.

How to adopt carefully

The main practical takeaway for managers is not to launch AI on the whole team at once. A mass rollout amplifies denial, anger and euphoria simultaneously, and a manager physically cannot walk everyone through this cycle. Instead, Surf advises piloting not the technology but the people: choose those already open to experiments, give them suitable tasks and support them at the points where mistakes, missed expectations or overestimation of capabilities usually occur.

The authors also remind that without a safe environment, learning will not take off. If a team punishes or publicly mocks any rough result, employees will not honestly learn the new tool. They will hide mistakes, feign progress or sabotage the process silently. So a healthy working environment here is not an HR slogan but a direct condition for the first working cases, on which internal expertise can be built and the attitude of the rest of the team gradually changed.

Another important point concerns internal leaders. A few visible examples are enough for the rest of the team to start seeing AI not as a fad handed down from above but as a real way to work faster or better. Such an example reduces resistance better than mandatory policies, presentations and license purchases without a clear use case. When success is visible nearby, the technology stops being abstract and becomes a working argument inside the team.

What this means

For companies this is a useful reminder: adopting AI in development is not buying one more tool but restructuring roles, habits and criteria of value inside the team. The winners are not those who sign licenses fastest, but those who manage to guide people through resistance, avoid breaking their motivation and turn interest in AI into a lasting working practice.