Getting a Team to Adopt AI Without the Eye Rolls
I have now introduced AI workflows to several teams: paid staff, part-timers, and volunteers, across organizations with very different cultures. Some rollouts caught fire. Some died in a week. The difference was never the technology. The same tools, sometimes the exact same templates, thrived in one room and flatlined in another, which means the interesting variable was always the people and how the thing was brought to them.
That should be encouraging, actually. It means you do not need better tools to get a better outcome. You need a better introduction. Here is what I have learned about making one, mostly by getting it wrong first.
Start with a pain, not a tool
The rollouts that flopped all started the same way: a meeting about AI. Capabilities, demos, possibilities. I gave one of those presentations myself, early on, and it went great by every measure that does not matter. People were engaged. Questions were asked. Everyone nodded, nobody changed anything. Two weeks later the workflows I had demoed had exactly one user, and it was me.
The problem with the capabilities meeting is that it hands people homework. Here is a powerful general thing, now go figure out what it means for your job. Almost nobody does that translation on their own, not because they are lazy but because they are busy, and busy people do not adopt possibilities. They adopt relief.
The rollouts that worked started with a specific chore somebody hated. The weekly summary nobody wanted to write. The meeting notes that never got distributed, so decisions evaporated by Friday. The social captions that ate a volunteer's whole evening every single week. In each case I did not announce anything. I just fixed the one chore, showed the person it belonged to, and let them react.
The meeting notes case is worth a beat more detail, because it shows the shape of a good first target. This team held a solid weekly meeting, made real decisions, and then watched those decisions dissolve because nobody had time to write up and distribute notes. The pain was not exotic. It was a gap between what the team decided and what the team remembered. Turning a recorded meeting into distributed, formatted notes within the hour did not impress anyone technically. It just quietly ended a problem they had stopped believing could end, and that is precisely the reaction you want: not "wow" but "wait, that's just handled now?"
The reaction is the engine. Fix one hated chore visibly and people line up to ask what else this can do. The volunteer who got her evening back becomes a better evangelist than I could ever be, because she is not selling anything. She is just visibly no longer suffering. Their pull always beats your push, and the entire art is engineering the first pull.
Show drafts, not magic
Demos create two bad reactions, and I have watched both happen in the same room.
The first is fear. When the machine produces in eight seconds a version of what someone spends every Thursday afternoon doing, some fraction of the room does not hear "helpful tool." They hear "we found your replacement." They rarely say it out loud. It comes out later, sideways, as skepticism about accuracy or worries about the technology, and if you treat those surface objections at face value you will lose, because the real objection was never spoken.
The second is disappointment, and it arrives on a delay. The demo was polished. Then the person tries it themselves, and the real output needs editing, because real output always needs editing, and the gap between the magic they were shown and the draft they received reads as a broken promise. Nothing kills adoption faster than a tool that seemed to overpromise, even when the tool is genuinely good.
So I never present AI as magic. I present it as a fast first draft that still needs their judgment. That framing does three jobs at once. It is honest, so there is no disappointment cliff waiting. It keeps quality expectations high, because a draft is by definition unfinished and everyone knows what you do to drafts. And it answers the unspoken fear directly, because it puts the human in the position of editor, which is a promotion, not a threat. The person who used to write the summary now reviews the summary. Editors outrank typists. People feel that instinctively, and the fear drains out of the room.
Lower the floor before raising the ceiling
Give people finished templates, not a blank chat box. This lesson cost me a rollout to learn.
A blank box is intimidating in a way that experienced users forget completely. It offers infinite possibility and zero guidance, and it quietly transfers all responsibility for the outcome onto the person typing. When their vague first attempt produces mush, they do not conclude the prompt was underspecified. They conclude they are bad at this, or that the tool is overhyped, and either conclusion ends the experiment. A blank box also produces wildly uneven results across a team, and unevenness is poison for adoption, because the people who got mush assume the people who got gold are simply smarter, and quietly bow out.
A template inverts every part of that. Paste the transcript here and get the summary in our format. The instructions, the tone, the structure, the output format: all decided in advance by someone who has already made the mistakes. The newcomer contributes the one thing only they have, their content, and gets a win on the first try. First tries are sacred. A person whose first attempt succeeds will forgive the tool a dozen later stumbles. A person whose first attempt fails will never really return, whatever they say in the meeting.
Confidence first, creativity later. Once someone has run the summary template twenty times, they start editing it, then start writing their own, and now you have a power user you never had to train. The ceiling takes care of itself. Your job is the floor.
Volunteers make this doubly true. I have led volunteer production teams for two decades, and the iron law of volunteers is that they give you their margin, not their prime hours. A tool that demands experimentation is asking for hours they do not have, so they will decline it politely and permanently. A template that works in ninety seconds fits inside a Tuesday evening. If your team includes anyone whose participation is a gift rather than a job description, the floor is not just where you start. It is most of the building.
The rule that changed everything
Nothing public goes out without a human approving it.
Saying this early, loudly, and in writing did more for adoption than any feature. I have opened every rollout with it since, and the change in the room is physical. Shoulders come down. Because the fear underneath every objection, underneath the accuracy questions and the "what about mistakes" questions, is really one fear: this thing might embarrass us, and my name is on it. People will not embrace a system they think might embarrass them, no matter how many hours it saves. Nor should they.
The review gate answers the fear structurally instead of rhetorically. The machine drafts. A person approves. Nothing reaches the public, the congregation, the mailing list, the feed, without human eyes and a human yes. In months of running things this way across multiple organizations, the gate has caught real problems, which means I get to say it is not theater, and everyone who has ever caught something at the gate becomes a co-owner of the system rather than a bystander to it.
The review gate is not a limitation on the AI. It is the reason people trust it. I would keep the gate even if the models became flawless, because the gate is not really about the error rate. It is about whose judgment the audience is receiving, and the answer has to stay: ours.
What I would do on day one, in order
If you are about to bring AI to a team, my sequence is now boringly consistent.
Find the most hated recurring chore. Ask around; people will tell you instantly, usually with feeling. Build the fix for that one chore, privately, and make sure it works on real examples before anyone sees it.
Announce the human-approval rule before you show anything. In writing. It is the foundation everything else stands on.
Show the fix to the person who owns the chore, framed as a draft machine that needs their editing. Let them use it for two weeks. Resist the urge to present it to the whole team.
Then let the pull happen. When the second and third person come asking, hand them templates, not a blank box, and repeat.
Adoption is pastoral work, honestly. I spent years as a pastor before I ran communications teams, and the skills transfer with almost no modification. You are shepherding people through a change they did not ask for, at the pace of their trust rather than the pace of your roadmap, and trust moves one person at a time. Go one chore at a time, keep the human hand on everything public, and let the saved hours make the argument. They argue better than you do.