On turning a design organization into AI-native builders - and why leading that change means coaching two opposite instincts at the very same time.
I lead a large design organization, and I'm in the middle of turning it into a team of AI-native builders. The hard part isn't the tools. Tools are learnable in weeks. The hard part is that I have to push my team in two contradictory directions at the same time, and the coaching depends entirely on who is in front of me.
My younger designers are fast. AI made them faster. They can produce twenty directions before lunch, prototype three of them by end of day, and have something clickable in front of a PM by morning.
What they can't always tell you is what problem any of it solves.
Speed without problem framing is just expensive thrashing. They get deep into the mess and can't find their way out, because they never built the muscle of stopping to ask the boring questions. What are we actually trying to solve? Whose problem is it? Which data source is authoritative? What would change our mind?
For them, my coaching sounds almost old-fashioned. Slow down. Diagnose before you prescribe. Write the problem statement before the prompt. Frame first, then sprint. The traditional methods they skipped are exactly what would let their speed compound instead of churn.
My seasoned principals have the opposite gap. They know process cold because they earned it across fifteen years of shipping. They can frame a problem in their sleep. And when the ground shifts under them, process is exactly what they reach for. Workshop it. Brief it. Align on it. Schedule the readout.
Here's what changed: most of that process was designed for a world where execution was expensive. When building a prototype took an engineer and three weeks, it made sense to spend two weeks making sure you were building the right thing. When the prototype takes an afternoon, that same rigor becomes overhead. The cheapest way to answer most questions now is to build the thing and look at it.
For them, the coaching is the reverse. Throw half of it out. Build before the brief. Trust the gut you spent a career tuning, because that gut is now the scarcest asset in the room. Get into the mess on purpose. It's uncomfortable, and the discomfort is the point.
The paradox resolves when you see what I'm actually asking of each group. I'm not telling the juniors to become process people or the principals to become hackers. I'm telling each group to develop the thing the other has natively.
The juniors have speed and need judgment. The principals have judgment and need to reattach it to speed. The destination is the same builder: someone who can frame a problem sharply in the morning and have a working answer by evening, knowing exactly which corners they cut and why.
I wrote recently about building a clinical research tool in a weekend and getting important things wrong along the way. I lived both failure modes in that one project. I moved so fast I trusted a bad data source and got fooled by a hospital name. And the moment that saved the project was a slow one: stopping, staring at a map that looked too green, and refusing to ship past my own doubt. Speed got me to the insight. Judgment is what recognized it.
The bottleneck in product organizations has moved. For my whole career, execution was the constraint. Headcount, sprint capacity, engineering queues. Every process we built was a way of rationing expensive execution.
Execution is no longer scarce. Judgment is. Knowing which problem matters, which anomaly is a bug versus a finding, when to ship and when to freeze. AI didn't create that skill gap. It exposed it, by stripping away all the execution work that used to hide it.
So I coach one designer to slow down in the morning and push a principal to speed up in the afternoon, sometimes in the same crit. It's the trickiest needle I've had to thread as a leader. It's also the clearest signal I can give my team about what the next version of this discipline looks like: not faster designers or more rigorous ones, but people who can hold both and know which one the moment calls for.
This piece pairs with "I'm not a stroke expert," a case study in living both failure modes inside one project.