Managing Engineers Through the Age of AI
I want to write about AI. Not what tools to use or how to optimize velocity. I don’t have the next “hot take,” and besides, the landscape is changing so fast it will all be different by the time I hit publish on this post anyway. I think we all already acknowledge the awesome power of AI and its impact on engineering velocity. I’m deeply optimistic about what AI is making possible for engineering teams. But transitions like this don’t just change what we build. They change how engineers experience the work itself. I don’t worry about what AI is doing to our delivery timelines. I do worry about what it’s doing to our engineers. Even more specifically, what it’s doing to our most senior engineers.
From what I’ve seen so far, lower to mid level engineers seem more open to adopting AI in their day to day workflows. As junior engineers, they’re still forming their engineering identities. They’re flexible. As senior engineers, they’re pragmatic and outcome-focused which aligns nicely with using AI to achieve greater outcomes.
I’ve seen something different with staff engineers. The engineers most unsettled by AI aren’t the least capable. They are often the ones who have spent the longest learning how to be excellent. As staff engineers, identity tends to be anchored in how systems get built. Staff engineers often optimize around architecture clarity, technical taste, solution-path efficiency, and authorship depth. AI shifts the value surface away from those signals. A lot of staff engineers were initially reluctant because we trained them for years if not decades to find the most efficient path to a solution. Then we introduced AI as a new tool. Like any other new tool, there’s friction to learning to use it. When that friction shows up, staff engineers often want to just write the code themselves because historically that was the most efficient solution. But as managers, we need them to get through the friction of adopting AI because the other side is actually faster. That’s destabilizing in a very specific way.
For these engineers, the hardest adjustment isn’t technical. It’s emotional. They didn’t fall in love with reviewing generated code. They fell in love with writing it. There’s a real, often unspoken, grief there because the way they’ve excelled at working is no longer what’s being asked of them. Part of the loss is stylistic too. What happens if the thing you fell in love with was writing code itself? Making dumb variable names. Refactoring. Trying to get code to compile. The dopamine hit when it finally does. When the test passes. When the div is centered on the page. Some of that is starting to go away now. So when we see that not all engineers are racing to adopt AI, maybe some of those engineers aren’t resisting AI. They’re adjusting to the realization that the work they spent years learning to do well is no longer the work being asked of them.
That’s not resistance. That’s coherence.
It’s also organizational whiplash. And managers are the translators of that whiplash.
The hardest part of managing engineers through AI isn’t choosing tools. It’s helping people navigate the moment when the way they learned to be excellent stops being the way they’re asked to work. My job isn’t to convince engineers AI is good. My job is to help them move through the transition without losing their sense of competence along the way. And once they get through that transition, I’ve seen those same engineers become some of the strongest adopters. When they start using AI at the level of systems and architecture instead of just code generation, the hesitation usually disappears.
Transitions like this don’t just change workflows. They change how engineers measure themselves. Managers have a responsibility to recognize that shift, name it when it’s happening, and help people move through it without treating hesitation like failure. The engineers who learn to work this way won’t be the ones who abandon craft. They’ll be the ones who redefine it.
