Helping a hesitant teammate start using AI

Every team that starts using AI ends up with a split. A few people use it daily, most dabble, and one or two haven't touched it. The usual response is another training session or a reminder in the team channel, and the people who weren't using it still aren't.

Hesitation usually has a specific reason behind it, and a general nudge doesn't reach a specific reason. This playbook is for a manager or a colleague who wants to help one person start. It takes one conversation, one task from their own week and one paired session, spread over about two weeks.

Before you start

Check three things, so you don't ask someone to do something the business hasn't settled:

• Which tools are approved, and that this person has an account on one. Asking someone to start while they still need to request access is a quick way to lose them.
• What data they're allowed to put in. If your team has an acceptable use policy, reread the data section. If it doesn't, settle that first.
• Whether using AI is expected in their role or optional. Be honest with yourself about this. It changes the conversation.

Step 1: the first conversation (15 minutes)

Have it one to one, not in a team meeting, and not by message. Open by saying why you're asking: you've noticed they haven't used the team's AI tool much, and you want to know whether it's useful for their work or not. Then ask, and mostly listen.

1. What have you tried so far, if anything? What happened?
2. Which parts of your week feel most repetitive or slow?
3. Is there anything about using it that makes you uneasy?
4. If it could take one task off your plate, which would you pick?
5. What would you need to see before you'd trust its output on that task?

Write down their answers in their words. You'll use them in step 2.

Step 2: match the reason to the response

Most of what you hear will fit one of the rows below. The response that works is different for each.

What you hear	What's usually behind it	What helps
"I tried it and it was wrong."	One bad result on a hard task, often with a short prompt	Pick an easier task where they can check the output in a minute. Show what a fuller prompt looks like.
"I'm not sure what I'm allowed to put in it."	Unclear rules, and a reasonable fear of getting it wrong	Show them the data rules in writing. Give two examples of what's fine and one that isn't, from their own work.
"I don't have time to learn it."	The learning cost is visible now, and the payoff isn't	Offer the 30-minute paired session in step 4 on a task they already have to do this week, so the time isn't extra.
"I don't want people to think I can't do my job."	Worry about being judged for using it, or for being slow to learn	Tell them how you use it and what you check. Keep the paired session private.
"Is this going to replace me?"	A real question about their job	Answer only what you actually know. If the business hasn't decided anything, say that plainly. Don't make promises you can't keep.
"I don't think it's right to use it for this."	A view about quality, customers or ethics	Take it seriously. Ask which tasks they'd be comfortable with. Some objections are correct, and the task should stay manual.

The "replace me" row deserves care. A vague reassurance that later turns out to be wrong does more damage than an honest "I don't know yet, and I'll tell you when I do."

Step 3: pick one task from their week

The first task decides whether they keep going. Pick it with them, using their answer to question 4, and check it against these four tests:

• They do it at least weekly, so there's a second and third chance to use it soon after.
• They can judge the output fast. A draft email they'd write anyway is good. A summary of a 40-page contract they haven't read is bad, because they can't tell if it's right.
• A mistake is cheap and caught before it leaves the building. Internal notes, first drafts and reformatting are good starters. Anything that goes straight to a customer, a regulator or a payment run is not.
• The inputs are allowed under your data rules without redaction gymnastics.

Good first tasks for most office roles: turning rough meeting notes into a tidy summary with actions, drafting a reply to a routine internal request, rewriting a long email to be shorter, turning a list of points into a first draft of a procedure, or reformatting a messy list into a table.

Step 4: the paired session (30 minutes)

Book it within a few days of the conversation, on a real instance of the task they picked. Sit beside them or share a screen. They drive. You don't take the keyboard.

Minutes 0 to 5: set it up. Open the approved tool. Agree on the input they'll use (the real meeting notes, the real request). Remove anything the data rules exclude.

Minutes 5 to 15: first attempt. Ask them to write the request the way they'd explain the task to a new colleague: what it's for, who reads it, what good looks like, what to leave out. If they write one short line, let them run it and see the result, then help them add the missing context and run it again. Seeing the difference between the two outputs teaches more than any explanation.

Minutes 15 to 25: check and fix. Have them read the output against the source. Ask: is anything here that wasn't in the notes? Is anything missing that matters? Would you send this as it is? They edit it until they would. Point out that the checking is their job and always will be.

Minutes 25 to 30: save it. Have them save the request that worked somewhere they'll find it next week: a note, a document, or your team's prompt library if you have one. Agree on when they'll use it next.

Step 5: the next two weeks

• Day 3 or 4: a two-line message asking how the second attempt went. Don't ask "have you used it?", ask "how did the notes summary go on Thursday?"
• End of week 1: if it went well, ask what the next task should be. If it didn't, ask what went wrong and look at the output together. A bad output with a fixable cause is useful.
• End of week 2: a five-minute check-in. Are they using it on the first task without help? Is there a second task? Is there anything they've decided it shouldn't be used for? Write that last one down; it's often a good rule for the whole team.

What not to do

• Don't count prompts or logins as a measure of progress. People will learn to produce the number.
• Don't demo something impressive that has nothing to do with their work. It widens the gap.
• Don't promise time savings you haven't seen on their task. Let them find out.
• Don't raise it in front of the team. Keep it between you until they choose to share.
• Don't push past a reasoned no. If someone has thought about a task and concluded AI makes it worse, ask them to explain why. They may be right.

If it's a role expectation

Sometimes using AI is part of the job, written into the role or agreed with the team. In that case the hesitation is still worth understanding, but the conversation has to be clear: what's expected, by when, what support is on offer, and how it'll be judged. Judge the quality of the work, not the amount of AI used. That's a normal management conversation, with the same fairness and notice as any other, and it belongs with the person's manager rather than a helpful colleague.

A worked example

Ferncliff Dental (a fictional practice) has seven people at the front desk and in admin. Five use the practice's approved AI tool for patient-facing letters and internal notes. Rosa, who handles supplier orders and the rota, hasn't used it.

Her manager asks her the five questions. Rosa says she tried it once to write a staff rota and it produced shifts for a person who had left. She also isn't sure whether staff names count as personal data under the practice's rules.

The manager checks the policy: staff first names are allowed in the approved tool, patient details aren't. She shows Rosa that line. They agree the rota is a poor first task, because a mistake costs a missed shift and Rosa can't check a full rota at a glance. Rosa picks something else: the weekly supplier order email, which she rewrites from a scribbled list every Monday.

In the paired session, Rosa's first request is "write supplier order email." The result is generic. Her second version says who the supplier is, that the list is the order, that quantities must match exactly and that the tone is brief and friendly. The output is close. She checks every quantity against her list, fixes one product name and saves the request in a note.

Two weeks later she has sent two orders with it and says it takes her about half the time. She has also decided, on her own, that the rota stays manual. Her manager adds that to the team's notes as a rule: AI doesn't draft rotas.

Do it with Merit AC: the AI Skills Academy course at /academy/course gives a hesitant teammate a private, step-by-step way to build the same habits after the paired session.