Put people in a room with a real problem, some parameters, and room to experiment. Then get out of the way.
The problem most plans skip
When an AI rollout stalls, the first instinct is usually "we need more training" or "we picked the wrong tool." Both can be true, and neither usually explains what is happening. People are not a fixed asset you train once and deploy. They change their behavior when the work itself gives them a reason to.
There is a newer version of this problem, and it is getting sharper. AI makes it easy for a small group to ship an idea on their own, before the rest of the organization catches up. I keep seeing it: this one person, or these three people, had a really cool idea, so they just shipped it. The result is not just siloed code. It is siloed understanding. Communication does not scale with shipping speed, and the organization ends up working backward to reconstruct what happened and who did it.
That is the problem I start from. Not "how do we get people to use the tool." It is "how do we keep a group of fast, increasingly capable people pointed at the same thing."
Name the real barrier
Before I pick a tactic, I try to name what is actually stuck. I break adoption into five places, because each one needs a different response:
- Educate. People do not yet see what AI means for their job.
- Enable. They see it, but they lack the skill or the access to act on it.
- Engage. They can act, but they have not taken a first step.
- Empower. They will run a prompt, but they do not trust themselves to go further on their own.
- Transform. None of the above, because the workflow itself never changed.
Most plans pour everything into the first two, treating a confidence problem with another training. That is expensive and it barely moves anyone. The leverage is usually in the middle three: getting someone to try, then to keep going, then to solve their own problems instead of waiting for a template.
What I've seen work
The approach I keep returning to is almost embarrassing in its simplicity. I have seen it work at SoundCloud and Honeycomb, and it comes down to focused, "let's solve this problem" hackathons. If you want the full playbook, I wrote up how to run an AI transformation hackathon end to end: choosing the workflow, setting parameters, working the phases, and judging it without a demo contest.
The format matters, because the format is the point.
You bring product, design, and engineering into the same room around one problem. You give them parameters, not a task list. Then you give them dedicated time to experiment with new tools and new ways of thinking, and you let them figure it out. The leader's job is to set the problem and the boundary, then hold the space. It is the opposite of a directive.
The reason it works is not mysterious. It is education that happens through doing. A person who is AI-curious but has not crossed over becomes an AI user the moment they use AI to solve something they actually care about, alongside people whose work they understand. They are not sitting through a demo. They are not trying to keep up with a dozen agents and subagents. They are inside the problem, and the tool earns its place.
That distinction matters more than it looks. Managing bots is a chore. Solving a problem is a career. When I have seen this done well, I see better outcomes, better collaboration, and better communication, because people built the thing together and the shared context is still warm.
We even stopped calling the output a prototype at SoundCloud. We called them vision types. A visiontype is not a demo of something that works. It is a prototype of a vision, a way to help people imagine a future that could be, and what it would take to make it real. A prototype answers "does this work?" A visiontype answers "what could this become?" That is a different conversation, and it is the one adoption actually needs.
Why the role earns its seat
This is where the case for an AI transformation role actually lives, and I think it is where leaders get it wrong.
The role is too often scoped as "deploy tools and run enablement." That makes it a cost the business tolerates until a budget cycle shows up. The role earns its seat when it is understood as owning how the organization works and behaves. That only becomes visible when you put people with a problem and watch what they do when they have room to move.
The people you want in this seat are not the ones who launch the most pilots. They are the ones who can name a real problem worth a cross-functional room, set parameters tight enough to keep the work pointed at value and loose enough to let people explore, and protect the time for experimentation. That time is always the first thing a busy team trades away.
Adoption does not follow from a roadmap. It follows from moments where people feel the work get better, together, and can point to something they would never have built without the room and the permission. That is the evidence that justifies a dedicated role. It is the kind of evidence a mandate never produces.
The signal that matters
If I had to pick one measure, it would not be the number of seats or the number of prompts. It would be whether the people who walked in AI-curious walked out able to ask for the thing they actually want. The real output of a good problem-solving session is not a demo. It is people who understand what the tool can do against their own work, and who will come back to it without being told.
Start small. Pick one cross-functional problem that matters and is not on fire. Set the parameters. Protect the time. Then watch whether the problem gets solved, and whether the people who solved it start on the next one on their own.
That is adoption. The rest is rollout.