Show-and-tell beats training slides.
Most AI training follows the same script. Someone shares a deck, walks through what the tools can do, shows a polished example or two, and the room nods along. A week later almost nobody has changed how they work. Then a colleague mentions, over coffee, that she now drafts the monthly board report in twenty minutes, and three people ask her to show them how.
That second moment is the one worth building on. When someone your team already knows shows a task they do every week, using the tools they already have, it answers questions that a training deck never reaches. Will this work on our kind of documents? How much fixing does the output need? Is it worth the bother for someone like me?
Why slides don't stick.
Generic training is built for everyone, so it fits nobody in particular. The examples are clean, the prompts are rehearsed, and the result always comes out right on the first try. People in the room can tell. They know their own intake forms are messier, their invoices come in four formats, and their manager wants the report a certain way.
There's also a distance problem. A trainer showing what AI can do is describing a possibility. A coworker showing what she did on Tuesday is describing a fact, about this organization, with these files and these constraints. People act on facts about their own workplace much more readily than on possibilities.
Slides also ask people to translate. Someone in accounts payable watches a demo about marketing copy and has to work out, alone, what the equivalent would be for vendor reconciliations. Most people never do that translation. They file the session under "interesting" and go back to the inbox.
What a good demo looks like.
The best show-and-tell is small and a little unglamorous. A scheduler shows how she turns a messy email thread into a clean list of open appointments. A program coordinator at a nonprofit shows how he drafts the first version of a grant report from last year's report and this year's numbers. A clerk in a town office shows how she summarizes a long public comment file before a meeting.
None of these would impress anyone in the abstract. They work because the audience recognizes the task, can picture doing it next week and can see exactly where the person still had to check or correct the output. A demo that includes the correction is more useful than one that hides it, because it shows people what judgment the work still needs.
People act on a fact about their own workplace far more readily than on a possibility from someone else's.
Keep it from becoming a talent show.
Show-and-tell can go wrong in a predictable way. The same two enthusiasts present every time, each demo gets more elaborate than the last, and the rest of the team concludes that AI is for a certain kind of person. The meeting turns into a performance, and the people who most need a way in stop showing up.
A few habits prevent that. Cap each demo at five minutes and one task. Ask presenters to show their actual screen and their actual prompt, mistakes included, with sensitive details scrubbed. Rotate who presents so that, over a quarter, someone from every function has a turn, including people who would describe themselves as skeptics. A skeptic who found one narrow use is often the most persuasive presenter in the room.
It also helps to praise the ordinary. When a manager thanks someone for showing how they cleaned up a meeting agenda, the message to everyone else is that small uses count. When only the clever automation gets applause, people with modest wins keep them to themselves.
Put it on the calendar for good.
A single show-and-tell session helps a little. A recurring one changes the culture of a team, because it creates a steady supply of examples and a standing reason for people to try something they can report back on. Fifteen minutes every two weeks is enough. Folding it into an existing staff meeting works better than adding a new one to the calendar.
Keep a simple running log of what was shown: who presented, the task, the tool, and a link to the prompt or a short write-up. After a few months that log is a library of use cases written by your own people, about your own work. New hires can read it in their first week, and it tells you which teams have found their footing and which haven't presented yet.
The log also surfaces patterns worth acting on. If three people in different roles all show variations on summarizing long documents, that may be worth turning into a shared prompt or a short written guide. If one department never appears, that's a conversation to have with its manager.
A 15-minute show-and-tell format.
The recurring meeting
- Two minutes: the host names the presenters for today and the one for next time, so everyone knows who is up and nobody is surprised.
- Five minutes, first demo: the presenter says what the task is and how long it used to take, then shows it live on their own screen, with the real prompt and the real output.
- Five minutes, second demo, same shape. Pick presenters from different roles where you can.
- Two minutes: questions, with one rule: keep them on the task. "What did you have to fix?" helps the room more than "Which model is that?"
- One minute: the host adds both demos to the running log and asks each presenter to share their prompt in the team's usual channel that day.
Prompts for presenters
- What task did you pick, and why that one?
- What did the first output get wrong, and how did you fix it?
- What do you still always check by hand?
- Would you suggest this to someone in a different role? Who?
