Most AI adoption failures I see aren’t technical. They’re change management failures wearing a technology costume.
This question is playing out every day in every organization – and the lack of answers is spilling over into Reddit and engineering forums pleading for help. This thread in r/EngineeringManagers is a perfect example: experienced engineering managers asking each other for AI adoption success stories, searching for something that actually works. The responses are genuine and well-intentioned. But they’re mostly individual tactics – what worked for one team, in one context, with one set of constraints. What’s missing is a diagnostic framework that tells you where a team is stuck before you prescribe a solution.
When teams aren’t adopting AI tools at the pace leadership expects, the default diagnosis is “resistance” or “skill gaps.” Sometimes that’s true. But more often, the team is stuck at a specific step in the change curve – and nobody’s named it yet.
I use a lightweight application of the ADKAR model to diagnose where each team actually is. ADKAR (Awareness, Desire, Knowledge, Ability, Reinforcement) was designed for organizational change, and AI adoption is one of the most complex change events most engineering teams have ever faced. It fits.
Here’s what I’ve found matters most at each step.
───
Awareness — and the rationale problem
Most leaders think they’ve covered Awareness because they sent an all-hands deck or announced a new AI tooling initiative. They haven’t. Awareness isn’t just knowing that AI adoption is happening – it’s understanding why, in a way that makes sense for you.
This is where most orgs fumble. The official rationale is usually something like “we need to achieve efficiency and productivity gains to stay competitive.” That’s true. It’s also the thing engineers hear as: we’re going to need fewer of you, or we’re going to freeze headcount and expect you to absorb more.
That’s not paranoia – it’s pattern recognition. Engineers have watched wave after wave of “productivity” initiatives result in exactly that. So when leadership announces AI as an efficiency play, a significant chunk of the team quietly decides not to engage. They’re protecting themselves.
If you want genuine Awareness, you have to be honest about what you’re actually asking for – and what you’re not. “We’re not trying to reduce headcount; we’re trying to stop losing to competitors who ship faster” lands differently than “efficiency and productivity.” So does “we want you to spend less time on the work you hate and more time on the work that actually requires your judgment.”
The teams that move fastest through A are the ones whose managers were given honest talking points – not spin – and were trusted to have real conversations.
───
Desire — compliance isn’t adoption
Desire is where you find out whether Awareness actually landed. If A was built on a shaky rationale, D collapses. People will comply – they’ll use the tools when someone’s watching – but they won’t internalize the change.
Genuine Desire comes from two places: belief that the change is good for the org, and belief that it’s not bad for them personally. You need both. One without the other produces performative adoption.
───
Knowledge and Ability — where most programs stall
Most AI adoption programs invest heavily here: lunch-and-learns, tool demos, access to licenses. That’s necessary but not sufficient. Knowledge is “I know how to use Copilot.” Ability is “I’ve actually integrated it into how I write code, review PRs, and debug at 11pm under pressure.”
The gap between K and A is where most teams quietly fall off. They had one training session and were left to figure out the rest. This is a manager problem, not an engineer problem – and it’s fixable with deliberate practice, not more demos.
───
Reinforcement — the step everyone forgets
Even teams that make it to Ability often revert without Reinforcement. Old habits are sticky. If the environment doesn’t reward the new behavior – through recognition, workflow integration, or just managers modeling it themselves – the change doesn’t stick.
───
What to do with this
You don’t need a six-month change management program. Run a quick diagnostic per team. Ask your managers: where is this team actually stuck? Is it A? D? K? The answer is almost never “everywhere” – it’s usually one or two steps, and they’re addressable with targeted support.
It’s equally important to create space for them to learn how to apply the tools you give them. Provide forgiveness for velocity dips as teams adapt to new approaches to their workflow. Carve out innovation sprints where failures are low-stakes learning, not performance events. Investing in those initial productivity dips will pay dividends in future sprints.
The teams that look like they’re “resisting AI” are usually just stuck at a specific step that nobody’s named yet.
───
Mike Schubert is a technology executive and host of CTO Unfiltered.