Long live the engineering manager

Estimated reading time: 6 minutes

Key takeaways:

• AI removes status updates but not the judgment work of coaching, prioritization, and alignment.
• Faster code generation raises the cost of misalignment, leaving less time to coordinate well.
• Removing engineering managers doesn’t remove dependencies as the work shifts to engineers who should be building.

I’ve lost count of how many times I’ve read articles boldly claiming engineering management is on the way out. Their existence predates the current AI era, but their prevalence has only increased over the past three years as AI has taken the software engineering world by storm. 

These articles all tend to follow similar themes: the hierarchy is flattening, we don’t need engineering managers, and AI makes individual engineers so capable that all a manager provides is additional overhead.

I understand why the argument is appealing. First AI increases capability, then engineering teams ship code faster, so naturally the org chart flattens. There’s a logic to it. If managers were mostly overhead before, why wouldn’t they be an early casualty in this AI revolution?

Many of the tasks people associate with engineering managers, like status updates and progress tracking, are exactly the types of work AI should take over. I would even take the argument a step further and say it’s the kind of work managers should never have been responsible for in the first place.

It’s the other work managers do like expectation-setting, performance coaching, prioritization, ensuring alignment, and translation across teams and levels of leadership that is where the real value of managers lies. That work isn’t about mechanical toil. It’s interpretive work requiring judgment. The assumption that this critical work disappears now that we have AI is where these articles’ arguments tend to break down. 

What happens when the engineering manager leaves

I’ve seen what it can look like when the layer provided by managers disappears. Both times I went on parental leave, my engineering teams were highly functioning and empowered. Extensive hand-off documentation and knowledge transfers happened ahead of time, a plan for coverage was put in place, and I left.

For weeks the teams who reported to me experienced work without a full-time manager. While I was gone, nothing major broke, but it was clear even in the limited time I was absent that alignment was never quite achieved and that expectations had gotten fuzzier. Everything felt a bit taped together.

On the team, engineers got pulled out of the code and into coordination work that wouldn’t normally be theirs to handle. No one was shielding them from the noise of the business.

Above the team, leaders normally outside the day-to-day got pulled closer to execution details. When I returned from leave, the consistent feedback was that people hadn’t realized how much invisible work I carry as an engineering manager until I wasn’t around to do it.

While I was gone, the work I had been responsible for didn’t disappear. It found a new home with coworkers whose focus was meant to be elsewhere. 

That doesn’t mean managers are the only people capable of doing this work. Senior engineers may carry parts of it. Organizations may distribute it across teams differently as hierarchies flatten. In the AI era, however, redistribution of responsibilities becomes more consequential, not less, as AI accelerates implementation. 

AI generates code faster than humans alone and expectations have become that shipping the features based on that code should also happen faster. What hasn’t changed? Shipping quality product features customers want has not magically become more straightforward as a result. 

Writing code is only one part of delivering product features. Product decisions, architecture, testing, security, rollout, and customer needs are all part of shipping code out the door. Those aspects haven’t necessarily accelerated at the same rate as code generation.

When teams start to move faster, the cost of misalignment rises just as quickly. The result isn’t less need for coordination but less time to do that coordination well. No one wants to see the speed gained from AI in code generation slowed down by messy, human-in-the-loop sense-making.

Unless someone is paying attention to how work is connecting across teams or how messaging is being translated from higher-level strategy into day-to-day tactics, AI is removing the shallow coordination layer and exposing the deeper one.

Managers ensure that when we want our engineers to move fast, we’re not bogging them down in work that doesn’t belong to them. Taking them away from building the features we need would only undo the velocity gains of AI, which is the very reason so many use AI in the first place.

Your senior engineers need a coach now

Taking on more managerial work as org charts flatten is not the only impact on engineers. Our most senior engineers are often the ones feeling the most like they don’t recognize the job they were hired to do.

AI is not only changing how engineers are expected to work, but it’s also redefining what being good at that work even looks like. I’ve had to coach senior engineers through the shift from authoring every line of code to being responsible for what gets produced with AI assistance. That’s not a tooling change so much as an identity shift, and it’s making many engineers reflect on where their value comes from at work.

I’ve also had to coach more junior engineers to find the right balance between experimentation and responsible engineering judgment. AI has created an intense coaching problem among our engineers, but coaching isn’t valuable just because AI happened. Someone needs to be responsible for the development of our engineers, not just the talented senior engineers we have now but the next class of engineers stepping up to one day take their place.

Translation is the permanent work of engineering management

Beyond development, someone needs to own the communication between those in charge of the business and those responsible for execution. Leadership can tell their organizations to “invest in AI acceleration,” but engineers hear “we’re telling you how to do your job.”

Engineers rarely appreciate being told which IDE to use, let alone industry-wide mandates about changes to how they work. Who is investing time getting engineers past the hurdle of skepticism to effective AI use? What counts as meaningful adoption? Where is experimentation with new tooling encouraged, and where is reliability still paramount? Those questions don’t answer themselves simply because new tooling exists.

The speed of AI implementation puts a premium on resolving those types of questions, and AI adoption is only one highly visible and topical example of a permanent category of managerial work.

Strategic intent has to be translated across an organization because without that translation layer, teams can make what seem like totally reasonable decisions that don’t unify into a single engineering strategy. Everyone on those teams can do their best work and make genuinely good decisions based on how they interpret a strategy.

The problem arises when five dependent teams all have their own interpretation of that strategy. The organization ends up in a state of deep confusion even though no one individually messed up. Different strategy interpretations can lead to standards drift between teams, inconsistent decisions, duplicate work, and dependencies discovered late in the game.

That’s the real risk: fragmentation across an engineering org that’s invisible until things stop working as they should and are expensive and time-consuming to put right. 

It feels necessary to acknowledge that AI will probably assist with the judgment parts of the work in the future too. However, right now, the need to interpret expectations and coach our engineers through the most significant industry change of their careers is increasing faster than it’s being automated.

AI may change the number of managers organizations need, who does this layer of work, or what we call that role. It doesn’t eliminate the work that the manager role evolved to handle.

Removing hierarchy doesn’t remove dependencies. It just removes the people whose job it is to manage them.