In my experience, the biggest reason is that nobody has shown people, on their own work, that the new tool is worth changing for. Your experienced people have ways of working that already get the job done, and AI has to prove it’s better than those, while being clumsier and less predictable at first. Licenses and training decks don’t prove that. Working sessions on real tasks can, as long as you’re also willing to find out that for some jobs the old way is better.
Helping companies adopt AI is part of what I do, and it’s something I’ve been working on inside my own company for about three years.
What happened when I rolled it out the wrong way
I built an AI system in my own company, showed the team, and essentially said: all you have to do now is go do this thing, and it’ll spit out that. It didn’t get adopted.
What did get adopted were the uses where someone had the light bulb go off in their own head: they saw for themselves what it could do for a part of their job they disliked. That meant working out, person by person, what was tedious about each person’s day and whether AI could make it a little better.
A presentation about how much better everything is going to be can’t create that moment. It asks people to take your word for it.
Why experienced people hold back
Picture a carpenter who has built hundreds of houses with a hammer. Hand them a nail gun. Over a whole job it’s faster and easier on the body, but it needs a compressor and a hose, and it’s heavier and less nimble. Until they’ve felt the difference on real work, there’s no reason to give up the tool they’re great with. AI is harder still, because its output has to be checked, and checking can eat the time it saved.
That shows up in the numbers. WalkMe’s 2026 survey of about 2,000 US workers who use AI on the job found that only about a quarter say it works on the first try, and half say they’ve spent more time trying to get AI to do a task than the task would have taken by hand. WalkMe sells software for getting employees to adopt tools, so weigh it with that in mind. One finding matches what I’ve seen: a third of the people surveyed said they’d pretended to be more skilled with AI than they are. These were all people already using AI at work, so the survey says more about where use goes wrong than why people never start.
Not all resistance is about the tool. People also watch what happens to the time AI saves them. In the same survey, 51% said AI had led their manager or team to expect more output in the same time. And in Duke research published in 2025, people who used AI at work were judged as lazier for it, which I’ve written about in how to judge work your team made with AI. If trying AI openly leads to more work, blame for its mistakes, or a worry that they’re automating themselves out of a job, holding back is a rational choice.
Find out why it isn’t being used
Before you fix anything, look at who is actually using the licenses, by role and team rather than by person, and talk to a handful of people in different roles. Some jobs may simply not need the tool, which is a licensing question, not an adoption one. Low adoption usually has one of a few causes, and each needs a different answer:
- They don’t know what it could do for their job. Working sessions fix this.
- They tried it and the results were unreliable or slow. Find out whether that’s a skill problem or a real limit of the tool for that task.
- They want to use it but lack time, permission or clear rules. That’s a leadership problem, not a training one.
- The tool you bought is worse than what they’re using on their own. That’s a purchasing problem.
What works: working sessions on real work
The biggest breakthroughs with my teams have come from one-on-one or very small working sessions where I was willing to get messy. Instead of a deck, open up a real task, something the person has to do this week, and work on it together.
One example: I sat down with one of my account managers to build an AI tool that writes up the follow-up after a client meeting, using his own meeting transcripts. The first run went wrong twice. It put the output somewhere we didn’t intend, and it misattributed the speakers from the transcript. We fixed both right there in the meeting, then adjusted the tone and the order of the sections based on what he wanted. After he’d worked on it through a few more rounds, it became a skill the whole company now uses.
Show the struggle on purpose. Let them see where the result wasn’t what you expected, what you changed, and how you worked through it. It shows the tool doing something useful on their actual work, and it shows that someone who’s supposed to be good at this still has to wrestle with it. In my experience, people are much less afraid to try once they’ve seen you get it wrong and fix it.
A few things help:
- Start with a task the person would like to get rid of, ideally one that comes up often, isn’t high-risk and is easy to judge.
- Use their real material, within your rules on what can go into which tools.
- Include the skeptics. They ask useful questions.
- Leave them with it for a week or two, then come back and fix what didn’t work.
Check that it’s actually better
Don’t assume AI improves a task because a session went well. Judge it on the whole job: time including prompting, checking and fixing; the quality of the finished work; whether the person can repeat it without help; and whether they choose to use it again.
Say someone spends 45 minutes on a weekly report. AI drafts it in 15, but checking and correcting takes another 40. That isn’t an improvement. If you refine the approach until the report reliably takes 25 minutes with the same accuracy, you have a real reason to switch. What the 20 minutes go to is a separate question (see how to measure whether AI is paying off). And if you can’t get there, keep the old way for that job. Saying so out loud builds more trust than pushing a tool where it doesn’t fit.
How one person’s win becomes the team’s habit
One-on-one sessions don’t scale to a few hundred people on their own, and they don’t need to. Start with a few people in different departments. When someone finds a way of using AI that genuinely works, write it down as a simple, repeatable process and have them show their colleagues. A peer who does the same job is often more convincing than a vendor or a leader. Then make each department’s leader responsible for adoption on their team, and change the work itself where it makes sense: the template, the checklist, the review step. If the manager still expects the report done the old way, nobody will switch.
The people higher up in the company should have real hands-on experience, so that when they encourage it, nobody thinks it’s hype. Your best champions may also come from anywhere in the company. A leader’s job is to use it visibly, give people the time to learn, and make it safe to experiment and get it wrong. I’ve written about implementing AI one expensive problem at a time, including how to pick where to start.
Should you just mandate it?
You can, and some companies do. A mandate works best when you’ve already shown that a particular way of working is better, trained people on it and retired the old way. Security or compliance rules are different: those can be required from day one. What a mandate can’t do is fix a tool that doesn’t fit the job or a process nobody has proven. With experienced people, a bare instruction to “use AI” tends to get the tool opened while the real work carries on the old way.
Set the rules first
Before people put real work into AI tools, decide which tools are approved and what information can go into each. People who aren’t sure what’s allowed either avoid the tools or use whatever they like on their own.
How long does it take?
A first useful result can come in a single session. Repeated, voluntary use on someone’s own work takes longer, in my experience weeks. Making it how a whole team works takes longer again, and some tasks never justify the switch.
Getting a team past the licenses-and-a-webinar stage is what my AI implementation consulting is for. Start a conversation here.
