I'm not an AI expert; I'm learning alongside my team. What I know is teaching - and why moving an org forward starts with permission to play.
Before any of this, I taught. Years of it, full-time. Two kinds of people walked into my classroom. Some knew nothing about UX and left able to build a real practice. The others walked in certain they already knew most of what UX was, and were wrong in ways they couldn't see. The second group was always the harder one to teach.
It's the difference between learning a language from zero and learning Portuguese when you already speak Spanish. The beginner knows they're a beginner. The Spanish speaker is close enough to get by, and that's the trap: it feels familiar enough that they never do the hard work of changing their habits. They lean on what they already know and call it fluency.
Leading a design org into AI is the same split. The people I worry about least are the ones who know they're starting over. The hard ones are the experienced makers who treat AI as close enough to the tools they've always used. It does rhyme with the old work. But rhyming isn't fluency. So when my field collided with AI, the problem didn't feel new. It felt familiar. Same problem, different clothes.
So let me say the obvious part out loud: I'm not an AI expert. I'm still learning to build with it, same as everyone on my team, sometimes a step behind the youngest among them. What I know how to do is teach - to carry people through a hard new thing without pretending I've already mastered it. That turns out to be the more durable expertise, because the tools will keep changing and the learning won't.
It would be easy to say the fix is to throw structure out - run a loose hackathon, let everyone play, hope capability emerges. I don't believe that. Structure and curriculum are good. What matters is the kind. A curriculum that adapts to the individual and is built on play will beat one built on reading and listening to philosophy every time. What most AI rollouts get wrong isn't that they have a curriculum. It's the order they teach it in.
People leave a typical training knowing more about a subject without being able to do anything differently. The reason is sequence, not effort. If you come out of the gate and hand people the end state before they understand anything underneath it, it sails over their heads and they tune out.
The example I keep coming back to: telling soon-to-be parents to "sleep when the baby sleeps." It's true. It's the best advice there is. And it's useless to them, because they can't really hear it - not until they've gone a month without sleep. Then the exact same sentence lands like revelation. Scaffolding is just making sure each lesson arrives at the moment someone is finally ready to receive it.
So I don't throw structure out. I build it to scaffold: shaped to the person in front of me, grounded in play instead of philosophy, and sequenced so people run into the wall themselves before the lesson that gets them over it - a lesson I'm often working out at the same time they are. I gave the effort a name, Builder Lab, mostly so it had a door people could walk through. The name was never the point. The scaffolding was.
The whole method fits in three lines, and I mean them literally.
Play. The first encounter with a new tool should be unserious. Curiosity moves faster than instruction. Poke at it, break it, find out what it's bad at before anyone asks it to be useful.
Stay messy. Capability lives on the far side of a mess. The teams that wait for a clean process never start. I would rather have a room full of half-working experiments and public mistakes, mine first, than a polished plan no one has touched.
Share what you make, not what you think. Demos over decks. The fastest way to spread a practice is to put real artifacts in front of people, not philosophy about the practice. Someone sees a colleague's rough thing actually working and wants their own. That want is the entire engine.
Adoption moves through phases, and they refuse to compress on demand. First curiosity, which needs permission to play with no deliverable attached. Then friction, the messy middle where the tool fights back and most programs declare victory and quit. Then fluency, when building with it stops being an event and becomes simply how the work gets done.
My job through all of it is mostly to protect the messy middle long enough for people to come out the other side, and to keep my own hands in the work so I'm leading from inside it instead of narrating from above. A leader who has stopped making things cannot teach people to make things.
This was never about a tool, or about one year's technology. It's about whether a team can keep learning hard new things together, out loud, without waiting for permission or a perfect process. That is a teaching problem, and it's the part I actually know how to do. The AI itself I'm still learning, alongside everyone else - which is exactly why the first move is to play, stay messy, and make mistakes.
Stay curious. Keep working.