Why Your Team Won't Use It

Eighteen licences. Four people logged in last month.

You ran the training. Ninety minutes, a decent trainer, everyone nodded, and a couple of people looked properly excited. Now the billing page says eighteen seats, the usage report says four, and three of those four are you, your ops manager, and the one person who was already using it before you paid for anything.

Nobody lied to you. They were polite about it for a month, the way people are, and then they quietly went back to the way that works.

I think the instinct at this point is to call it resistance. But before we do, it’s worth asking what the new way was asking them to give up, learn or do differently. Resistance is information. It usually tells you something about the rollout, not the people.

The reason they give you usually isn’t the reason

Ask why and you’ll probably hear “I haven’t had a chance yet”. That’s a true sentence about a false problem. Underneath it, there are usually six real reasons, and not one of them is really about the software.

They don’t want to look stupid in front of you. Your senior people have spent years being the ones who know. Being visibly clumsy at something in front of the team costs them something real. So say it out loud, in a meeting: “Everyone in this room is going to be bad at this for a few weeks, including me. That’s expected, not a problem.”

They think it’s here to replace them. This is often the biggest one, and it’s almost never said out loud, so you have to answer a question nobody asked. Be specific, or it sounds like a vague reassurance, and vague reassurance doesn’t last. Something like: “No role here is going because of this. What changes is that the Friday reporting stops eating your afternoon, and that time goes back to client work, not to more volume.” If you can’t honestly say that, don’t run the rollout yet. Work out what the honest version is first.

They have no room to be bad at something. Someone running at 95 per cent capacity has nothing left to learn with. Learning is slower than the old way for a while, and everybody knows it. So make the time explicit: two hours blocked in the calendar, not billable, not optional, for six weeks.

Nobody told them what’s allowed. This one is quiet and enormous. A careful person who isn’t sure whether client names can go into a chatbot will simply not use the chatbot, and won’t raise it either, because asking can feel like admitting you wanted to do something dodgy. Silence reads as no.

Nobody showed them what good looks like. People won’t send work they can’t judge. Without a shared standard, every output feels like a risk, so it gets rewritten by hand, and the tool ends up saving nothing.

The training showed features, not their Wednesday. Watching someone summarise a sample article doesn’t teach anybody how to summarise the nine-page scope document that landed in their inbox this morning. If the training didn’t touch the real work in front of them, not much transferred.

Adoption is behaviour change, and behaviour change has a known shape

A one-off training session is basically a lecture. Lectures are efficient at delivering information and not very good at changing what someone does next week.

What does change behaviour has three parts, and good teachers use all three constantly. Modelling: someone competent does the thing in front of you, out loud, including the parts that go wrong. Practice: you do it yourself, on real work, badly at first, with enough time to be bad. Feedback: someone looks at what you made and tells you specifically what to change.

Done in that order, with the support easing off at each stage, it’s what teachers call gradual release. Get It Out of Your Head uses the same approach to hand over a process, and The Course Nobody Finishes uses it to get people past module two.

If your rollout had a demo, no protected practice time and no feedback, it was always going to struggle to hold. Nobody on your team failed. The design did, and design is fixable.

The rollout that holds, in five stages

1. Permission, in writing, before anything else. Not a policy document. One page, from you, specific, naming what’s allowed and what isn’t. Send it before the training, not after.

AI at [Company]: what you're allowed to do
Updated [date]. Owner: [your name].

Approved tools: [tool, plan]. Nothing else without asking me first.

You can, without asking anyone:
- Draft any internal document, email, agenda or summary.
- Rewrite, shorten or restructure something you already wrote.
- Summarise a transcript from [approved recorder].
- Think out loud with it: plan an approach, list options, argue
  against your own draft before you send it.

You cannot, yet:
- Paste client names, contact details, contract terms or financials
  into anything other than [approved tool].
- Send a client anything you have not read end to end and edited.
- Use it to make a decision about a person: hiring, performance, pay.
- Upload files from [named system or folder].

If you're unsure, ask me. Asking is never the wrong move and it is
never held against you.

How much you use this is not part of anyone's performance review.
The point is to take the dull parts of the job off your plate. Time
it saves goes back to [specific thing: client work, the backlog,
finishing on time].

2. One real job, not a tool tour. Pick a single task the team does every week, that they all dislike, and where the stakes are low if it comes out wrong. First drafts of the monthly report. Meeting notes into actions. Rewriting the same four proposal sections. One job, everyone, the same job. Trying to cover everything at once is often what sank the first attempt.

3. A leader who’s publicly bad at it first. You, or whoever runs that team, in a shared session, doing the real job live. Including the prompt that comes back useless, and including saying “that’s not right, watch what I change”. People are unlikely to risk looking clumsy until someone senior has gone first. That’s modelling, and there isn’t really a substitute for it.

4. A shared standard. Three real examples up on the wall: one good, one nearly right, one bad, each with a note on why. The nearly-right one does the heavy lifting, because the skill you’re really teaching is spotting the difference. Then add one rule: nothing goes out unread. If the standard only exists in your head, the AI Foundations Checklist has a pass/fail template for writing it down.

5. Check-ins with a real question. Not “how’s it going?”, which always gets “yeah, good”.

When	Ask exactly this	What a worrying answer sounds like
2 weeks	“What did you try that didn’t work?”	“Haven’t had a chance.” Nobody has started. Go back to protected time.
6 weeks	“Show me the last thing you used it for.”	Anything they have to search for. It isn’t part of the work yet.
3 months	“If I took it away tomorrow, what would you go back to doing by hand?”	A shrug. It never became something they rely on.

The best sign you’ll get isn’t a login number. It’s that the team are using it and asking questions, because they’re actually using it.

When not to bother

Don’t roll anything out during a restructure or redundancy consultation. People will read it exactly the way you’d expect, and you’ll spend trust you need later. Wait.

Don’t roll it out on top of a broken process, either. Your team will just produce the document nobody reads, faster. Fix the process first.

Don’t bother if leadership won’t use it. A tool the boss never touches is optional, and optional things lose to Tuesday.

And skip it where the task is tiny. If it takes four minutes a week, leave it alone and go and find the thing that takes four hours.

What you’ve got now

The six real reasons a team stalls, and words to answer each one. A permission note you can send before your next team meeting. A five-stage rollout with modelling, protected practice and feedback built in, and three check-in questions that tell you the truth early enough to do something about it.

Write the permission page before you book any more training. It takes about twenty minutes, and it clears the blocker nobody mentions.