What your power users are telling you

The amnesty tells you what's in use. A short conversation with the people furthest ahead tells you why. What someone builds for themselves is a map of where their work gets stuck, drawn by the person who knows that work best.

Every workaround points at a queue

Nobody builds a workaround for work that flows. A saved prompt that drafts the weekly status report exists because collecting everyone's status takes hours. A spreadsheet that scores incoming leads exists because leads sit unread until someone gets to them. An assistant that checks contracts against a clause list exists because contracts queue for legal.

So when you find something a power user made, the useful question isn't which tool it runs on. It's what was happening before. Where did the work wait, pile up or get redone? That answer is friction, and friction is what module 4 turns into a bottleneck.

Two things stand out. Power users experiment: they try things on their own work until something sticks, which is exactly the habit the framework wants to spread. And they're far more likely to have heard from the top that it matters. What leaders say changes who comes forward.

MIT found that the organisations getting real value sourced their AI work from frontline managers and power users rather than a central lab, and that this bottom-up sourcing, paired with accountability at the top, sped adoption up. Your power users have already run the pilot. The conversation is how you collect the results.

How to have the conversation

Power users are easy to find after the amnesty: the people whose answers mention something others rely on, and the ones who said they'd show what they built. Ask the custodian to pass on the invitation, so nobody is singled out by a manager. Then spend thirty minutes, one to one, on the five questions below.

Record the work, never the person. “Refund replies wait two days for a policy check” is friction. “The supervisor is slow” is blame, and it's the fastest way to end these conversations for good.

What to listen for

Most of what matters comes out in passing. Four phrases are worth writing down when you hear them.

• “I do this every week.” Recurring friction, not a one-off. It belongs on the friction list.
• “I check it before it goes to…” A quality step someone has quietly added. It tells you where errors arrive from, and where rework is hiding.
• “People keep asking me for it.” It has become shared, or is about to. It needs to go on the AI list today.
• “Strictly, we're not supposed to…” The workaround is routing round a rule, not a queue. That's friction too, and module 4 has a name for it: a policy bottleneck, where the limit is a rule rather than anyone's capacity.

And two things not to do. Don't ask for a demonstration in front of their manager, which turns a conversation into an inspection. And don't promise money or a build on the spot. The front door gives its first answer within 10 working days; the conversation only has to give the default one.

Adopt it, and the maker gets credit

When someone has already made something that works, the front door's default answer is to adopt it, and the maker gets credit. That default does three jobs.

• It keeps the second promise: no one is punished for improving their own work.
• It's the cheapest option you have. The thing already exists, and someone already knows how it behaves.
• It's the signal everyone else is watching. If the first person who shows you a workaround is thanked and their work spreads, the next ten come forward. If it's taken away, or they get a harder target, nobody else will.

Adopting isn't rubber-stamping. An adopted item still goes on the AI list and still gets the two questions in the next lesson. Adopt the work; if it runs on a personal account, move it onto an approved tool.

The moment it becomes shared

Most of what power users build starts personal: one person's prompt, for one person's work. It becomes shared the moment any of these is true:

• someone else depends on it
• it acts beyond its maker's own work
• it writes into a shared system or a system of record
• outsiders use it directly, with no person in between

Anything shared needs an owner: someone who answers for it, with a backup who can stop it. That often isn't the maker. The maker gets the credit; the owner is named by the leader of the function it serves, in module 7. Until then it goes on the AI list marked shared, so nothing others rely on is running without anyone knowing.