es
A manager and team sit in a circle while one person voices concerns and the others listen carefully.
Real use by the teamCommon mistakes

How to guide a team that resists AI: 7 steps without forcing it

Mandating use gets compliance, not change. Seven practices for building real capability with a team that pushes back, plus four questions to check your progress at quarter end.

Author
VegasiO Team
Date published

How to guide a team that resists AI: 7 steps without forcing it

How do you guide a team that resists AI, without forcing it on them? With seven moves, in order: listening to what that resistance is made of, separating fear from criticism that is right, showing a small case with numbers, training with the company's real work, giving people room where a mistake does not cost much, measuring the effect before scaling up, and leaning on whoever is already using it well. These are practices to adapt, not a recipe.

Why does the team split over this topic?

Because each person is hearing a different conversation. Some try tools out of their own interest, some fear their job will shrink, some see the quality drop in something that took them years to learn to do well, and some simply do not see what they gain. A general instruction to "use AI" does not tell those four things apart, and that is why it resolves none of them.

This is for owners and managers who already pushed adoption and ran into resistance. The goal is not to defeat it: it is to understand what it is made of and build real capability from there.

Why does mandating use not work?

Because mandatory use gets complied with without anything changing. People open the tool, do the minimum and keep working the way they always did, so neither the workflow changes nor the number you were watching moves.

There is evidence behind this. BCG estimates that around 70% of the value of an AI transformation comes from the human and organizational component, and Cisco's AI Readiness Index 2025 shows that 91% of the organizations it calls Pacesetters had a formal plan to support the change, against 35% of the general sample. Cisco surveyed organizations of more than 500 employees, so the figure marks a practice, not a direct reference point for an SMB.

A route of seven connected stages moves from listening to concerns through testing, measuring, and reviewing a change.

Seven concrete moves help turn initial resistance into learning and participation.


What are the seven steps?

1. Listen to what the resistance is made of

Do not assume it is fear of change. Ask directly: what worries you about starting to use this. The answers vary more than you would expect, from the fear of being replaced to offended professional judgment, and including the very reasonable suspicion that this is extra work with nothing taken off the plate. What has to be done next depends on which one it is.

2. Separate fear from criticism that is right

Part of the resistance is emotional and comes apart with a conversation and a concrete example. Another part is technical and correct: there are workflows where the tool does not apply, and there are tasks where quality drops. Those are handled by adjusting the scope, not by insisting. Sometimes the team is seeing something that is not visible from management.

3. Show a small, real case

Before asking anyone to adopt anything, show a result on a case from the team itself. Not a product demo: an example with a starting point and a measurement. This task used to take this long, in the test it took this long, and these were the corrections that had to be made by hand.

4. Train with the company's work, not with tutorials

Generic courses on how to use ChatGPT leave general understanding and close to zero application. Training that moves something uses real cases from the firm as the exercise, and each person leaves the session with one of their own pending items resolved. That difference shows up the following week.

5. Leave room for mistakes

The first results are going to be uneven. You need narrowly scoped tests, human review before anything goes out, and a channel for reporting errors without that carrying a personal cost. Learning from failure does not mean letting something unreviewed reach a client or a sensitive decision.

6. Measure before scaling up

Measure the benefit in the task and in the operation: time, quality, rework or risk. Someone feeling that their day goes further is useful information for understanding adoption, but it does not replace the number from the process, which is the one that supports the decision to scale up.

7. Lean on whoever already uses it well

Identify someone on the team who is using it with judgment and who can show both what worked for them and what did not. A colleague convinces differently than management does. Direction and resources remain the owner's responsibility, but the demonstration does not have to come from the owner's mouth.

How do you know at the end of the quarter whether you are on track?

With four questions you can answer from memory, without opening a report. The first is whether resistance went down, held steady or went up. If it went down, you are on track and it is worth continuing the way you were going. If it went up, review how much you are mandating, because that is usually where the cause is.

Next, look at whether there is someone on the team using AI with judgment and in view of everyone else. If there is, sustain it: give that person time and occasions to show how they work. If nobody turns up, finding that person is next quarter's task.

The third question is about the training: was it built with cases from the company or with generic material? If it was the second, rework it before repeating it. Repeating the same format produces the same result.

The last one is whether you are measuring the time saved in the tasks where it is already being used. If you are not measuring it, start there, because without that number there is no way to defend the decision to scale up.

What is worth looking at in the end is not what percentage of the team is using AI, but what percentage changed the way they work because of it. They are two very different numbers and only one of them is any use for deciding.

A composition contrasts emotional fears with evidence-based risks while a manager facilitates the conversation.

Distinguishing fear from valid criticism supports an empathetic response without ignoring real risks.


What does supporting the team not mean?

It does not mean waiting until the team is ready, because waiting with no date is another way of not deciding. It is not putting it to a vote either: the owner sets the direction, the team sets the pace and the form. It does not mean hiring someone to preach the virtues of AI, which usually raises resistance instead of lowering it. And of course it does not mean buying more tools, because a bigger catalog does not convince a skeptic.

The companies where this does catch on look alike in three ways: management listens to the resistance with curiosity and not with impatience, the first training is built with their own cases and not with the vendor's material, and the person they hold up as an example is not the most technical one but the one who changed the way they work the most. On why more tools do not amount to more capacity, there is "Why more AI tools do not mean more operating capacity".

Is your team resisting?

VegasiO's Discovery web takes 5 minutes and helps place what kind of resistance you are dealing with in your case. At the end it tells you whether the next step is Capacitación IA para ti y tu equipo, a Diagnóstico de Adopción IA, or an adjustment in how the topic is being led before moving ahead.

Next step

Turn this into a clear next step

If this sounds like your operation, take the Discovery: five minutes and you leave with a read on your case, not a generic recommendation.