Why Your Team's AI Push Stalled, and What's Actually Blocking It

You told your team to use AI. They said yes. Most of them quietly didn't, and no amount of training is going to change that.

If you've mandated AI, run sessions, shared the tools, and watched almost nothing change, this is for you. The problem is real, it's common, and it's almost never the one founders think it is.

The thing an engineer once told me

One engineer put it to me plainly: "I tried AI, it made a mistake, it's stupid, I'm not using it."

This was at a company running an internal AI session every single week. He'd sat through all of them. He hadn't given the tools a fair go and then formed a view. He'd decided in advance it wouldn't work, found one mistake, and used that mistake as proof he'd been right all along.

That's worth sitting with, because the pattern is everywhere once you see it. The objection sounds technical. "It makes mistakes." "It's not reliable." "It doesn't understand our codebase." Each of those can be true. But the speed and the certainty give it away. Someone who's genuinely tested a tool talks about where it helps and where it doesn't. Someone who's decided against it in advance reaches for the first failure and stops looking.

It was never a knowledge problem

Here's what he was really saying, underneath the words: he was scared AI was coming for his job. "It's stupid" was the safest thing to say out loud, because it puts the blame on the tool rather than admitting the fear.

This matters, because it explains why the usual fixes do nothing.

More training assumes people aren't adopting AI because they don't know how. So you run another session, share another guide, bring in another demo. And it doesn't move the needle, because knowledge was never the blocker. He knew what the tools did. He didn't want them to work.

You're solving a knowledge problem. The real one is fear. And fear doesn't respond to a presentation.

Why pressure backfires

The natural next move, when the sessions don't work, is to push harder. Mandate it more firmly. Track who's using it. Make the gap visible so the holdouts feel it.

Don't. This is the one instinct that actively makes things worse.

Pressure feeds the exact fear that's driving the resistance. If someone is quietly worried that AI makes them replaceable, leaning on them to adopt it faster confirms the worry. You get compliance, not adoption. People will tell you they're using AI. They'll have it open in a tab during standup. And the real work will carry on exactly as before, because you've given them a reason to perform adoption rather than a reason to want it.

What actually works

The shift that moves adoption is counterintuitive. You stop trying to push AI onto people and start making good AI use something they move towards on their own.

Two things do most of the work.

First, put it where the whole team already is. Most AI enablement happens in optional sessions, and optional sessions are attended by the people who were already keen. The person you actually need to reach, the quiet resister, never shows up. So take AI out of the side room and put it into the meetings that already happen with everyone present. Planning. Retros. Design discussions. Make good AI use visible in the rooms that matter, not the ones people can skip.

Second, let your most respected engineer show what it does. Not a manager, not an external trainer, and not the office enthusiast. The person whose technical judgement the team already trusts. When that person walks through how they used AI to ship a real feature in half the time, it lands in a way no mandate ever will. It reframes AI from "a thing management is pushing" to "a thing good engineers use." People move toward what looks good, not what they're told to do.

The deeper fix

Visibility gets you moving. The deeper work is about ownership.

The fear underneath all of this is loss of control, the sense that AI is being done to engineers rather than chosen by them. That fear drops when people get to decide how AI fits their own work: where it helps, where they don't trust it, what stays firmly in human hands. When an engineer owns how the tool fits their craft, it stops feeling like a replacement and starts feeling like leverage. That's a harder thing to engineer than a good retro demo, and it's usually where outside help earns its keep. But it's the part that makes adoption stick rather than spike.

The point

The tool is rarely the problem. When an AI push stalls, the reflex is to question the tooling, the training, or the team's ability. It's almost always fear that nobody named.

Name it, take the pressure off, make good use visible, and give people ownership over how they work. Adoption follows. Not because you mandated it, but because you made it the thing people wanted to move toward.