Make it safe to be bad at AI at first.

Ask a team whether they use AI at work and you will get a short, careful answer. Ask the same people over coffee and the stories come out: the proposal someone drafted with it last week, the spreadsheet formula it fixed, the reply to an angry customer it helped soften. Most of that use stays private, and so does most of what people learn from it.
Why people keep it to themselves.
The reasons are ordinary. Someone who tries AI on a report and gets a clumsy draft worries that it makes them look slow. Someone who gets a good draft worries that it makes them look lazy, as if the work no longer counts because a tool helped. And some people suspect that if they show how much the tool can do, someone will decide their job can be smaller.
So people do one of two things. They use AI in private and say nothing, or they avoid it and hope nobody asks. Either way the organization loses the thing it most needs early on, which is a shared picture of what works on its own documents and its own customers.
A clinic front desk and a ten-person engineering firm have the same problem here. The tool is new to almost everyone at once, and nobody wants to be the first person seen fumbling with it.
The first tries are supposed to be bad.
Getting useful work out of AI is a skill, and it develops the way most office skills do: badly, then less badly. The first prompt for a meeting summary misses the decisions. The second one gets the decisions but loses who owns them. By the fifth or sixth try, the person has learned what to ask for, what to check and where the tool tends to drift.
Nobody learns what a tool is good for on their own work without first watching it get that work wrong.
Those bad early results are the useful part. They show where a tool guesses, where it needs the source document instead of a description of it, and which tasks are not worth handing over at all. When people hide the misses, every colleague has to rediscover the same ones alone.

Keep mistakes cheap.
It is easier to let people be bad at something when being bad costs little. That means giving them somewhere to practice where a weak result hurts nobody. Old meeting notes, last year's newsletter, a public policy document or a made-up client file are all fine material. A live payroll run or a reply to an upset parent is not the place for a first attempt.
It also means saying plainly what never goes into a tool: client records, health information, passwords, anything covered by a confidentiality agreement. People experiment more freely when the edges are clear. Vague warnings make the careful people stop entirely and leave the careless ones unchanged.
The last part is review. If every AI-assisted draft passes through a person before it leaves the building, a bad draft is just a bad draft. Say that out loud. People relax when they know the checking step is the safety net and that a rough first output is expected.
Watch what gets rewarded.
Teams learn the real rules from what happens after someone admits something. If a staff member mentions that AI helped with a grant application and the first response is "did you check every line?", the lesson everyone takes away is to stop mentioning it. The question is fair. Asked first, in front of others, it reads as suspicion.
A better first response is curiosity. What did you ask it? What did it get wrong? Would you use it for that again? Those questions treat the attempt as information the team can use, and they still get to the checking question, a minute later and in a friendlier way.
It helps to praise a good report of a failure as much as a clean success. Someone who says "it invented two citations, so don't use it for that" has saved everyone else an hour, and that deserves the same thanks as a time-saving trick.
Three team rituals that reward trying.
None of these needs a budget or a new tool. Each one fits inside a meeting or a channel the team already has.
1. The two-minute miss
Add one standing item to an existing weekly meeting: one person describes an AI attempt that went badly. They say what they tried, what came back and what they would do differently. Rotate the slot so everyone takes a turn, and let the manager go first in the opening week. Keep it to two minutes and don't discuss fixes at length; the point is that misses get said out loud as a normal part of the week.
2. The practice hour
Once a month, block an hour where people try AI on a real but low-stakes task from their own job, using material that is safe to share. A front desk might try rewriting the appointment reminder text. An operations lead might try turning a messy vendor list into a clean table. Nobody has to produce anything usable. At the end, each person writes one line in a shared document: the task, and whether they would try it again.
3. The "AI helped" note
Agree that anyone may add a short line to a draft or a handoff saying that AI helped and how, with no penalty attached. For example: "First draft from AI, figures checked against the April ledger." This makes the use visible, tells the reviewer where to look hardest and removes the incentive to hide. Over a few months, those notes also become a record of which tasks the team now trusts the tool with and which ones it gave up on.


