I’m sending this link to a friend, who called me today to discuss this issue. Jim isn’t the name, but the problem is real.
Jim,
Remember when we used to walk the streets of Detroit talking about the buildings?
You’d point up at the Guardian Building and go on about the Aztec tile work, how Rowland convinced the bankers to let him use color when everyone else was building gray boxes. What strikes me now is that nobody asked Rowland to run workshops teaching other architects to be less afraid of orange. They let him build. And Detroit got something that still stops people in their tracks a hundred years later.
I’ve been thinking about our last conversation. There’s something I didn’t say clearly enough.
Sarah Is a Gift. Stop Returning Her.
You told me about Sarah. The engineer who actually gets it. Goes home and builds things with AI. Ships side projects on weekends. Sees what’s possible and can’t stop talking about it.
She’s rare, Jim. She sees what everyone else will only recognize in hindsight. She’s your Rowland.
So naturally, you made her the “AI Champion” and put her in charge of training everyone else.
I understand the logic. She’s good at AI, she’s enthusiastic, she explains things clearly—who better to bring the rest of the team along?
Here’s the problem: you’ve sentenced your highest-potential engineer to full-time enablement duty.
Sarah doesn’t get to refactor that authentication service you’ve been deferring for three years. She doesn’t get to build the internal tooling that would save fifteen hours a week. She gets to explain prompt engineering to people still deciding whether they’re interested.
That’s not a reward for excellence. That’s a punishment wrapped in a promotion.
The Sisyphus Promotion
Think about what you’ve actually done.
The engineer who shows up hungry, learns on her own time, already operates at a level most of your team won’t reach for eighteen months—you’ve handed her a cart full of reluctant learners and told her to push it up the hill. Forever.
Every hour Sarah spends on enablement is an hour she’s not compounding her own capabilities. An hour she’s not demonstrating what AI-assisted development actually looks like. An hour your organization isn’t learning what’s possible.
Worse: Sarah probably can’t move people who don’t want to move. That’s not a skills gap. That’s a motivation gap. And motivation isn’t something she can fix with better documentation or another lunch-and-learn.
You’ve given her an impossible job and called it leadership development.
This Is Your Job, Jim
The upskilling problem is real. Some percentage of your team isn’t ready for AI-assisted development, and that gap will cause friction.
But that’s a leadership problem, not an engineering problem.
Sarah can’t restructure teams. Sarah can’t have hard conversations about career trajectories. Sarah can’t decide whether resistance is a training issue or a fit issue. Sarah can’t allocate budget for outside help.
You can.
Free Sarah. Let her solve the hard technical problems you’ve been deferring. Let her demonstrate what one engineer with AI fluency can actually ship. That demonstration will do more for buy-in than a hundred enablement sessions.
Own the upskilling problem yourself. Bring in external training. Create learning paths with real accountability. Have honest conversations with engineers who aren’t progressing. That’s leadership work. That’s your work.
Let champions champion through building. The best way to show your organization what AI can do is let your best people do it. Visibly. On real problems. That creates pull. That creates curiosity. That creates motivation Sarah can’t manufacture in a conference room.
The Upside Is Enormous
Jim, look at what you actually have here.
You have engineers with AI skills you desperately need. Engineers you can afford. Engineers who already understand your domain, your codebase, your customers. You didn’t have to hire them. You didn’t have to onboard them. You didn’t have to wait eighteen months for them to learn where the bodies are buried.
They’re already on your payroll. They’re already bought in. They’re ready to build.
And you have hard problems languishing on the backlog. An organization that needs to see what’s possible before they’ll believe it.
The only thing standing between you and that future is a staffing decision you made with good intentions.
Here’s the moral, plain as I can make it: don’t make your high-performing engineers train your low-performing engineers. That’s not their job. That’s yours.
Turn Sarah loose on building things with AI. Or risk losing her to a company that will.
Sarah wants to build, Jim. Let her.
You bring everyone else along. That’s what leaders do.
—Joe
P.S. — That taco place on Michigan Avenue is still there. The Guardian Building still catches the light the same way. Some things shouldn’t change. Your best engineer pushing a cart uphill isn’t one of them.
Engineering leader who still writes code every day. I work with executives across healthcare, finance, retail, and tech to navigate the shift to AI-native software development. After two decades building and leading engineering teams, I focus on the human side of AI transformation: how leaders adapt, how teams evolve, and how companies avoid the common pitfalls of AI adoption. All opinions expressed here are my own.