Fear Is a Rollout Problem, Not a People Problem
Most resistance to AI at work is rational. Here is how to run a rollout your team trusts, from the first use case to the ninety-day review.
Most AI rollouts stall in the same place. The tool works, the pilot looked good, and six weeks later three people use it. Leadership reads that as resistance to change. It usually is not. It is a rational response to an unclear deal.
When you hand someone a system that does part of their job and say nothing else, they will fill the silence themselves. They will assume the worst version, wait, and keep doing the work the old way in case the new way gets them measured badly. That behaviour is cheap for them and expensive for you.
Answer the job question before anyone asks it
The first thing your team wants to know is whether this replaces them. If you do not say it, they will decide the answer without you.
So say it, specifically, in a way you can be held to. "Nobody loses a job because of this system in the next twelve months" is a sentence a director can commit to. "AI augments rather than replaces" is not — people have heard it and they know it means nothing.
If headcount will change, say that too, and say what happens to the people affected. A hard answer given early costs you less than a vague one that leaks over six months. And if you cannot commit to anything, you are not ready to roll out; you are ready to have a different conversation with your board.
Start with work people already resent
The instinct is to pick the highest-value process. Pick the most annoying one instead.
Reconciling two spreadsheets that never match. Rewriting the same proposal boilerplate. Reading forty support tickets to find the three that matter. Nobody defends that work, nobody's professional identity depends on it, and everybody notices when it goes away. You get your first advocates for free.
The high-value process is still there in month four, and by then you have a team that has seen the thing work and has opinions about where it goes next.
Write down the rules, on one page
Ambiguity is what makes people cautious. Most of it clears up with a short document that answers, in plain language:
- What you may put into the system, and what you may not — customer names, contracts, salary data, source code
- Which outputs need a human review before anyone outside the company sees them
- Who to tell when it gets something wrong, and what happens next
- Whether using it, or not using it, affects how your work is judged
That last line matters more than the other three. If people suspect that AI usage is being tracked and scored, they will use it defensively and badly. Say plainly how it factors into evaluation, even if the answer is "it doesn't."
Recruit the skeptic, not the enthusiast
Your enthusiasts will adopt anything and convince nobody. The person you want in the pilot is the experienced, well-respected one who thinks this is probably overhyped.
They will find the real failure modes in a week, because they know what correct output looks like. And if they end up saying "this saves me an afternoon," that carries weight nothing from leadership can buy. Give them a genuine channel to report problems, then fix the problems fast enough that reporting feels worth it.
Make it easy to say the system was wrong
Every AI system produces confident errors. A rollout succeeds or fails on what happens next.
If flagging a bad output requires an email to IT, nobody flags anything, errors accumulate quietly, and trust drains. Put the report button in the tool. Have a named person who reads the reports. Publish what you changed. Teams forgive systems that are wrong sometimes; they do not forgive being ignored when they say so.
Judge the rollout, not the technology
At ninety days, the useful questions are about behaviour. How many people used it in the last two weeks, not since launch. Which teams dropped it, and what did they say when you asked why. How long does a flagged error take to get a response. Where has someone quietly gone back to the old process, and were they right to.
Those numbers tell you whether the change landed. Model benchmarks do not.
Carrying that weight — the policy, the pilot design, the awkward first conversation — is most of the work, and it is the part that gets skipped. It is also the part we spend most of our time on with clients.
Handled well, adoption stops looking like a mandate and starts looking like a tool people asked for.