Rolling AI Out to People Who Have Seen Ten Rollouts

What this is for

You have been asked to get AI adopted across a team, a department, or a whole organization, and a meaningful share of the people involved have been doing their jobs for fifteen years or more. You have watched the standard approach fail: everyone attends the webinar, everyone says it was interesting, and six weeks later usage is concentrated in the same four enthusiasts who were already using it.

This is why that happens with experienced staff specifically, and a 90-minute session you can run without buying anything. It is written for whoever owns the rollout, whether that is learning and development, a function head, or the VP who got handed it.

Before you start

The premise everything below rests on: your experienced people are not resistant, they are unconvinced, and those need opposite responses. Resistance gets handled with mandates and change management. Being unconvinced gets handled with evidence. Treating the second as the first is the single most reliable way to lose the room, because it tells a twenty-year veteran that you think their skepticism is an emotional problem rather than a professional judgment.

They have also sat through a lot of these. The people you are training have survived several rounds of technology that was going to change everything. Some of it did. Some of it cost them a year of pain for nothing. Their pattern-matching is doing its job. Skepticism here is experience, not obstruction.

Why the generic version fails

Four specific failures, each with a fix built into the session below.

The examples are beneath them. Generic training demonstrates summarizing an article or drafting a birthday message. A senior person watches this and correctly concludes the tool is for tasks they do not have. The demonstration has to use work that is recognizably theirs and hard.

It teaches the tool instead of the judgment. A tour of the interface is not the hard part and never was. The hard part is knowing which work to hand over and how much to trust what comes back. Experienced people know this is the real question and notice when training avoids it.

It has no answer for accuracy. Somebody always asks what happens when it is confidently wrong. If the answer is a reassuring deflection, you have confirmed that the program is selling rather than teaching, and you will not get that person back.

Nobody says what it means for their job. The unasked question in the room is whether this is an efficiency initiative with headcount attached. If you do not address it, people will answer it themselves, usually less generously than the truth. You do not need good news; you need a straight answer.

The 90-minute session

Built for eight to fifteen people who know their work well. No slides about what a large language model is.

Before the session: one piece of homework

Every attendee brings one real task from their own work that they dislike and that is not confidential. A report they rewrite monthly, a set of notes they turn into something readable, a form of analysis they repeat. Tell them the session will use their thing rather than a demo.

This single step does more for the outcome than anything in the 90 minutes. It also gives you a useful signal in advance: the tasks people volunteer tell you where the real friction is.

Collect the tasks a few days early and run this on the list. It picks the one to demo live, which is the single decision the session turns on.

ROLE: You are helping me choose which task to demonstrate live in a
90-minute AI session for experienced professionals who are skeptical
and have sat through many rollouts.

CONTEXT: My attendees are [ROLES AND SENIORITY, e.g. 8 clinical
managers, 12 to 25 years each]. Below are the tasks they submitted.

TASKS: [PASTE THE LIST]

CONSTRAINTS:
- Pick ONE task to demo live and say plainly why the others are worse
  choices for a demo.
- The best demo task is recognizable to the whole room, is genuinely
  tedious, and is one where current tools produce something good but
  not perfect, because the correction is the lesson.
- Reject any task that would need confidential material to demo.
- Reject anything so easy that the room concludes the tool is a toy.
- Then group the remaining tasks into the two or three patterns they
  share, so I can speak to the whole list rather than to one person.
- Do not recommend tools or write a training agenda.

OUTPUT FORMAT: The chosen task in one line with a two-sentence
rationale, then a short list of rejected tasks with a few words each
on why, then the patterns with the names of the tasks under each.

Minutes 0 to 10: The straight answer

Open with the job question, before anyone asks it. Say what is actually true in your organization: whether this is tied to headcount plans, what happens to the time saved, whether anyone's role is under review. If you do not know, say you do not know and that you will find out.

Whatever the answer is, giving it first buys you the next eighty minutes. Avoiding it means half the room spends those eighty minutes running their own analysis instead of listening.

Minutes 10 to 25: One honest demonstration

Take one attendee's real task and do it live, in front of everyone, without rehearsing it first.

Unrehearsed is the whole point. They will watch you write a prompt, get something mediocre, and fix it. That is the actual skill and it is invisible in a polished demo. A session where everything works perfectly teaches people that it works perfectly for you, which is not a transferable lesson.

If the output is wrong, say so out loud and show the correction. You are demonstrating the working relationship with the tool, not the tool.

Minutes 25 to 55: They do their own

Everyone works on their own task. You circulate. Thirty minutes, which feels long in the plan and is barely enough in the room.

Two rules to state up front. Nothing confidential, and be specific about what that means in your organization rather than saying it vaguely. If you have an AI policy, this is the moment it becomes real; if you do not have one, you have a gap to close before this rollout, and The One-Page AI Policy is the shortest route to it.

Second: the goal is one usable output, not exploration. People who poke around leave having learned that it is interesting. People who finish something leave having learned that it works.

Minutes 55 to 75: The accuracy conversation

Do this after they have used it, not before. Now they have all seen something plausible and wrong, which makes this concrete rather than theoretical.

Cover three things. Where it is confidently wrong in your field specifically, with an example from the room if you can get one. What checking actually looks like for the work they just did. And the line between work you can hand over and work you have to own, which is a judgment they already have from managing people and can transfer directly.

Minutes 75 to 90: One commitment each

Everyone names one task they will use this for in the next two weeks. Written down, specific, theirs.

Not a goal. One task. The gap between "I will explore AI" and "I will draft the Thursday ops summary with it" is the entire difference between a session that changes behavior and one that changes opinions.

The four objections, and straight answers

These come up every time. Have real answers ready, because the deflecting version costs you the person asking.

"It gets things wrong in my field." Correct, and they know their field better than you do. The answer is not that it is improving; it is that this makes it a drafting tool and not a deciding tool, and that they are exactly the person able to tell the difference. Their expertise is what makes the tool safe to use, which is a better and truer answer than reassurance.

"I can do this faster myself." Often true today, especially for a task they have done a thousand times. The honest response is that this is true for their strongest work and much less true for the work they do occasionally, and that the second category is where to start rather than the first.

"Is this about reducing headcount?" Answer it honestly or do not raise the topic at all. A vague answer here is read as a yes, and correctly so.

"We tried this already and it did not stick." Ask what happened. You will usually learn that the pilot lacked a real use case or that the tool was not licensed properly. This objection, taken seriously, is the most useful thing said in the session.

What to check at week three

Not a survey. Surveys measure enthusiasm, which peaks the week after training and tells you nothing.

Go back to the commitments. For each person, did the task they named actually get done that way, once? That is the entire measurement.

• More than half did it. The program is working; run the next cohort and ask this group for their examples to use in it.
• Under a quarter did it. Something blocked them after the room emptied. It is usually access, a license that never arrived, or a policy nobody could get a clear answer on. That is a logistics problem wearing an adoption problem's clothes, and more training will not fix it.
• Between a quarter and a half did it. Normal for a first cohort, and not a reason to change the program. Go to the ones who did not, one at a time, and ask what stopped them before you book another session.
• They did it once and stopped. The task was wrong, not the person. It was probably something they only do monthly, so the habit had nothing to attach to. Help them pick a weekly task instead.

Where this goes wrong

• You run a demo that works perfectly. It teaches the room that you are good at this, which they already assumed. Show the mediocre first attempt and the fix.
• You dodge the headcount question. Every person in the room has already asked it silently. Your silence is an answer.
• You use generic examples to save preparation time. This is the one shortcut that guarantees failure with experienced staff. Their own work, or do not bother.
• You measure with a satisfaction survey. People are polite about training. Check whether the named task got done.
• You train before the policy exists. Thirty people now have a tool and no clear rule about client data. Write the one-pager first.
• You treat the enthusiasts as proof it is working. They would have adopted it anyway. The program exists for everyone who was not already using it, and their numbers are the only ones that mean anything.

The 2-minute version

Ask everyone to bring one real task from their own work. Open by answering the headcount question honestly. Demonstrate live on somebody's actual task without rehearsing, including the part where the first attempt is mediocre. Give them thirty minutes on their own task with one rule, which is no confidential material. Have the accuracy conversation after they have used it, not before. Close with one specific named commitment each. At week three, check whether that one task got done, and ignore the survey.

---

More where this came from. The resource library has 23 free guides like this one, written for people with real careers rather than developers.

Weekly, on Tuesdays. The GenXcelerate newsletter: practical AI intelligence for people who already know how to do the job. Subscribe free.

Experience Is the API. GenXcelerate