There is a standard failure story in workplace AI, and it goes like this: leadership buys licenses for everyone, sends an announcement with the word 'transformation' in it, runs a lunch-and-learn, and six months later the dashboards show that a fifth of the seats have been opened twice. The tool was fine. The rollout assumed that access creates usage, and it never does. Usage comes from seeing someone like you save an hour on work like yours.

That sentence is most of the playbook. The rest of this guide is the mechanics of making it happen on purpose.

Start with volunteers, not a org chart

Every team already contains people who are curious about AI — usually they are [already using it](/work/bringing-ai-to-work/) unofficially. A pilot of eight to fifteen volunteers beats any selection you could design, because volunteers supply the two things a pilot actually needs: motivation to push through early awkwardness, and honesty about what did not work. Give them the sanctioned tools, the [one-page policy](/work/ai-use-policy/), a shared channel for discoveries, and four to six weeks. The channel is not decoration — a place where 'I got it to do the quarterly report formatting' gets posted is the single highest-leverage piece of infrastructure in the whole rollout.

Train on real work or do not bother

Generic AI training bounces off, and it deserves to. A session about 'effective prompting' in the abstract asks people to hold technique with nothing to attach it to. The version that sticks inverts it:

  • Bring your actual task. Sessions where each person arrives with a real piece of this week's work and leaves with it done are the ones that convert skeptics — because the value is not hypothetical; it already happened, to them, today.
  • Demonstrate on the team's own material. Ten minutes of watching a colleague draft, summarize, and revise on a document everyone recognizes teaches more than an hour of slides about capabilities.
  • Teach the fix for the first failure. Everyone's first bad output is a fork: some conclude the tool is overhyped and leave; some learn that a vague request produced a vague answer and iterate. Training exists to make the second path the default — the craft of it is covered in [prompting that works](/guides/prompting-that-works/).

Champions carry this further than any curriculum. One person per team who is visibly good with the tools, has time carved out to help colleagues, and gets recognized for it will outperform any training vendor, because they translate: they know what the work actually is.

Measure honestly or not at all

AI rollouts attract measurement theater — adoption dashboards, message counts, 'AI maturity' scores — that measure activity, not value. Opened chats say nothing about whether work got better. The honest toolkit is smaller and plainer:

  • Ask, regularly and specifically. A monthly three-question pulse — did AI save you real time this month, on what, and what did it make worse — outperforms any instrumented metric, because time saved on real tasks is self-reported by nature.
  • Before-and-after on specific workflows. Pick the two or three processes the pilot targeted — first-response drafts, report assembly, code review turnaround — and compare cycle times over a quarter. Small n, real signal.
  • Watch quality where speed shows up. If drafting got faster and error rates or rework climbed, you have automated the production of problems: speed that survives review is the thing being measured, not speed alone.
  • Count the failures too. Track where AI was tried and abandoned, and why. A use case that did not work, understood, is worth more than three vanity wins — it tells you where the next hour of training should go, and where the tools genuinely are not ready.

What you are looking for at the end of a quarter is not a percentage on a slide. It is a handful of named workflows that are measurably faster or better, a list of things that did not work, and volunteers from teams outside the pilot asking when they get access. That last one is the real adoption metric.

Expand along demand

When the pilot produces results, expansion is mostly repetition with better evidence: the next circle of teams gets the tools, the policy, a champion, and — this is the part that compounds — the pilot's accumulated discoveries as their starting point, not a blank page. Expand where teams are asking, celebrate specific wins with named workflows rather than announcing initiatives, and let the mandate stay where it belongs: not 'use AI,' but 'here is what your colleagues built with it, and here is your access.'

The failure modes, named

  • Mandate without training — licenses plus expectation, minus investment. Produces resentment and empty seats.
  • Tool sprawl — five overlapping products sanctioned at once, so nobody develops depth in any and [the bill](/work/business-ai-plans/) quietly triples. One primary tool, mastered, beats a portfolio sampled.
  • No feedback channel — discoveries and failures both die in individual heads, and the organization learns nothing from its own experiment.
  • Ignoring the resisters' information. Some resistance is fear, and training addresses it. Some resistance is a person telling you the tool is genuinely wrong for their work — and they are frequently correct. A rollout that cannot hear the difference deploys AI where it does not belong and erodes trust where it does.

None of this is exotic management science. It is the ordinary discipline of any tool change — volunteers first, train on real work, measure what matters, expand along demand — applied to a tool that happens to be moving faster than most. The companies getting durable value from AI are not the ones that announced it loudest. They are the ones where, eighteen months in, nobody calls it a rollout anymore.