Everyone in the room nods. Nobody changes anything on Tuesday.
You have probably sat through the demo.
Someone opens a laptop and shows the thing doing in nine seconds what used to take a morning. There’s a small involuntary noise from around the table. Someone says okay, that’s actually impressive. Someone else asks about security. The meeting ends on time and everybody leaves genuinely excited.
Then nothing happens.
Not nothing, exactly. Two people try it. One uses it for a week and stops. Six months later you buy the license anyway, because it seemed like the responsible thing to do, and the usage dashboard shows four active seats out of forty.
I’ve watched this happen. I’ve also caused it, which is the more useful qualification.
The wrong diagnosis
When adoption stalls, organizations reach for one of three explanations. All three are wrong in the same way.
We picked the wrong tool. So you evaluate more tools. This is the most expensive form of procrastination available to a large organization.
People need training. So you run a session. Forty people attend a webinar, nod, and return to their inboxes. Attendance is recorded. Nothing transfers.
We need a policy. So you write one. A policy tells people what they may not do. It has never once told anyone what to do instead.
Each of these treats adoption as an information problem — as if the reason nobody’s using the tool is that they don’t know it exists, or don’t know the rules.
But everyone knows it exists. That was never the bottleneck.
The bottleneck is that using it requires a person to change how they do their actual job, under deadline, in front of colleagues, while being temporarily worse at it than they were last week.
That is not an information problem. That is a teaching problem.
What teaching actually is
I did a graduate degree in teaching within the creative field. For most of my career it read as an oddity on my résumé — the line people asked about politely and then moved past.
It doesn’t read that way anymore.
Here’s what that training gives you that a tooling background doesn’t.
You don’t teach a tool. You teach a judgment. Anyone can be shown which button to press. That takes an afternoon. What takes months is knowing when the output is wrong.
The valuable skill in an AI-assisted workflow isn’t generating. It’s rejecting. And rejection requires taste, standards, and the nerve to say this isn’t good enough about something that arrived fully formed and looked entirely plausible. You cannot demo that. You have to build it, in a person, over time.
Transfer is the whole game. In education, transfer is the gap between doing something in the classroom and doing it in the world. It’s where nearly all training fails — and it fails quietly, because the workshop itself went great.
Everything that happens in a demo environment is a lie about Tuesday. The only training that counts happens on real work, on a real deadline, with a real chance of being wrong in front of someone.
Nobody learns without feedback. Not encouragement. Feedback. Someone has to look at the output and say this is bad, and here’s why.
Organizations are already poor at this, and they’re worse at it with AI, because criticizing the output feels like criticizing the tool, and criticizing the tool feels like announcing you’re a Luddite. So nobody says anything, and the standard quietly drops to whatever the machine produced.
And you cannot teach a person who believes the lesson is about replacing them.
This is the one nobody says out loud. Every AI rollout in a knowledge organization is happening in a room where some people believe — correctly or not — that the project’s logical conclusion is their redundancy.
Fear does not produce learning. It produces compliance, quiet sabotage, and very convincing performances of enthusiasm in meetings.
If you haven’t addressed that directly, plainly, in words, more than once — nothing else you do will work. Everything built on top of it is theater.
The expert is usually the wrong teacher
Here’s the awkward part.
The person in your organization who is best with the tools is frequently the worst person to lead the adoption.
Not because they’re bad at their job. Because they’ve forgotten what it was like not to know. Educators call this the expert’s blind spot, and it’s why the most fluent person in the room reliably gives explanations that are technically complete and practically useless.
They skip the steps they no longer see. They answer a question the learner didn’t ask. They are, without meaning to be, faintly contemptuous.
The right person to lead adoption is usually someone competent but recent — close enough to their own confusion to still remember its shape.
So what do you actually do
Not a list of ten prompts.
Pick one workflow a real team does often and hates. Not a showcase. Something boring and load-bearing.
Do it with them. On live work. At deadline. Be wrong in front of them.
Define what “good enough to ship” means before anyone touches a tool — because the tool will cheerfully produce something that clears no bar at all, and if you haven’t set the bar in advance you’ll accept it out of politeness.
Say the quiet thing about jobs. Out loud. And be honest about what you don’t know, which is more than you’d like.
Then do it again, with the next workflow.
That’s the method. All of it. It’s slow, it doesn’t demo well, and it’s the only thing I’ve seen work.
The part that won’t fix itself
The tools will keep getting better whether or not you do anything. That’s the one part of this you can safely ignore. Next year’s model will be better than this year’s, and it will ask less of you, not more.
The teaching won’t improve on its own.
There is no version of the model that makes an organization braver, or gives a team the standards to reject bad work, or tells a frightened person the truth about their job.
That’s the work. It always was.
I write about creative leadership, AI adoption, and the parts of the job nobody puts in a keynote. One post every two weeks.