Long Live the Engineering Manager  🔗 **Source:** [Long Live the Engineering Manager](https://leaddev.com/management/long-live-the-engineering-manager) > [!note]+ Document Notes > --- > tags: [engineering-management, ai-and-engineering-work, team-alignment, engineer-coaching, org-flattening] > author: Liz de Moll > source: LeadDev > reference: https://leaddev.com/management/long-live-the-engineering-manager > date created: 2026-10-19 08:31 > --- > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > # 🏷️ Title: Long live the engineering manager > ## 🧭 Table of contents > - [📝 Summary](#-summary) > - [📖 Main content](#-main-content) > - [🗒️ Notes](#️-notes) > - [📚 References](#-references) > - [🗣️ Paraphrase](#️-paraphrase) > - [📰 Newsletter](#-newsletter) > - [✅ Action items](#-action-items) > - [🧪 Hypotheses](#-hypotheses) > - [📊 Methodology](#-methodology) > - [❓ Questions](#-questions) > - [🔮 Future research](#-future-research) > - [💡 Implications](#-implications) > - [🧠 Learning styles assessment](#-learning-styles-assessment) > - [📊 Accessibility assessment](#-accessibility-assessment) > - [🌍 DEIB assessment](#-deib-assessment) > - [✅ Logical validity](#-logical-validity) > - [🛡️ DARVO analysis](#️-darvo-analysis) > - [🎯 Conclusion](#-conclusion) > - [🔄 Refactor appendix](#-refactor-appendix--long-live-the-engineering-manager) > ## 📝 Summary > This is an opinion essay, not reporting or research. Liz de Moll wrote it for LeadDev (leaddev.com, management section) and argues that AI doesn't remove the need for engineering managers. The captured text carries no publication date, and the task metadata supplies none. The essay rests on one personal anecdote (two parental leaves) plus argument, and it cites no data of its own in the captured text. The paragraph numbers below (¶1 to ¶35) are the blank-line-separated blocks of the captured file, counted from the "Key takeaways:" line. > - **What happened.** The author pushes back on articles claiming engineering management is "on the way out" (¶5). Those articles say hierarchy is flattening and AI makes individual engineers capable enough that managers add overhead (¶6). The author agrees that status updates and progress tracking are work AI should take over (¶8), then argues the remaining work (expectation-setting, coaching, prioritization, alignment, translation) is interpretive and doesn't disappear (¶9). > - **The claim.** Three linked claims. First, removing the manager layer moves coordination onto engineers and distant leaders (¶11-¶15). Second, faster code generation raises the cost of misalignment and shrinks the time to fix it (¶17-¶21). Third, senior and junior engineers need coaching through AI-driven identity and judgment shifts, and someone has to translate business strategy into team-level decisions (¶23-¶32). The closing line states it as a rule: "Removing hierarchy doesn’t remove dependencies" (¶35). > - **Evidence offered.** One first-person account: during two parental leaves, "nothing major broke" but alignment slipped and expectations got fuzzier (¶12), engineers took on coordination (¶13), and leaders moved closer to execution detail (¶14). Returning, the author heard "people hadn’t realized how much invisible work I carry" (¶14). The rest is reasoning from how delivery works (¶18) and a hypothetical about five teams interpreting one strategy five ways (¶31). > - **What the author concedes.** Managers aren't the only people who can do this work, senior engineers may carry parts of it, and AI "will probably assist with the judgment parts" later (¶16, ¶33). The author allows that AI may change the number of managers, who does the work, or the role's name (¶34). > - **Key stakeholders.** Engineering managers, senior and junior engineers, engineering leadership and executives who set AI mandates, and the organizations deciding whether to flatten. > - **Risks and tradeoffs.** The anecdote is one manager's view of her own absence, and the essay doesn't say how long the leaves lasted beyond "weeks" (¶12). The author is an engineering manager arguing for the value of that role, which is an interest, not a disqualifier. The article gives no figures on flattening outcomes. The linked LeadDev pieces (see References) may carry data, but the captured text doesn't state any. > - **Bottom line.** A coherent, hedged argument that coordination and coaching work survives AI, supported by experience rather than measurement. It shows what breaks in one team without a manager. It doesn't show how often that happens, or that a different structure couldn't absorb the work at lower cost. > ## 📖 Main content > **The opposing argument, stated fairly (¶5-¶8).** The author describes the genre she disagrees with: hierarchy flattens, managers aren't needed, AI makes engineers self-sufficient. She grants the argument has logic. If managers were mostly overhead before, they'd be an early casualty of AI. She also agrees that status updates and progress tracking should go to AI, and adds that managers should never have been responsible for that work in the first place (¶8). > **What managers actually do (¶9).** Her list: expectation-setting, performance coaching, prioritization, ensuring alignment, and translation across teams and levels of leadership. She calls this "interpretive work requiring judgment," not mechanical toil, and places the weakness of the "managers are obsolete" articles in assuming it vanishes with AI. > **The leave anecdote (¶11-¶15).** The author took parental leave twice, with teams she calls highly functioning, with hand-off documents, knowledge transfer, and a coverage plan in place. Over the weeks without a full-time manager: alignment wasn't achieved, expectations blurred, engineers did coordination work "that wouldn’t normally be theirs," and nobody shielded them "from the noise of the business" (¶12-¶13). Leaders outside the day-to-day got pulled toward execution (¶14). The author's summary: the work "found a new home with coworkers whose focus was meant to be elsewhere" (¶15). > **Why AI raises the stakes (¶16-¶21).** The author separates code generation from shipping. Writing code is one part, alongside product decisions, architecture, testing, security, rollout, and customer needs, and those haven't sped up at the same rate (¶18). When teams move faster, misalignment costs more and there's less time to coordinate (¶19). The essay's image: AI removes the shallow coordination layer and exposes the deeper one (¶20). Managers keep engineers from being bogged down in work that doesn't belong to them, which protects the velocity gains that motivate AI use (¶21). > **Coaching (¶22-¶25).** Senior engineers face an identity shift, from authoring every line to being responsible for AI-assisted output (¶24). Junior engineers need help balancing experimentation against judgment (¶25). The author claims someone must own developing both the current seniors and "the next class of engineers" (¶25). > **Translation (¶26-¶32).** Executive messages like "invest in AI acceleration" get heard as "we’re telling you how to do your job" (¶27). Open questions the essay lists: who moves skeptics to effective use, what counts as meaningful adoption, where experimentation is welcome and where reliability comes first (¶28). AI adoption is presented as one visible example of a permanent category of managerial work (¶29). Without translation of strategy, five dependent teams can each make reasonable decisions from different readings, producing standards drift, inconsistent decisions, duplicate work, and dependencies found late (¶30-¶31). The author names that fragmentation "the real risk" (¶32). > **Close (¶33-¶35).** AI will probably help with judgment later, but interpreting expectations and coaching are "increasing faster than it’s being automated." The role's size, owner, or name may change, and the work doesn't (¶34). The last sentence repeats the thesis (¶35). > **Terms.** "Flattening" means removing management layers. "Shallow coordination" means status and progress reporting. "Deeper" coordination means alignment on strategy, standards, and dependencies. The essay doesn't define "engineering manager" beyond the duties listed in ¶9. > **Contested or unc [](https://leaddev.com/management/long-live-the-engineering-manager)[article hero – leadership](https://leaddev.com/management/long-live-the-engineering-manager) **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](https://leaddev.com/career-development/the-reality-of-being-an-engineering-manager) is on the way out. Their existence predates the current [AI era](https://leaddev.com/ai/best-ai-coding-assistants), 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](https://leaddev.com/ai/coinbase-flattens-management-and-trims-workforce-in-ai-driven-restructure), we don’t need [engineering managers](https://leaddev.com/management/how-engineering-managers-actually-get-rated), and AI makes individual engineers so capable that all a manager provides is additional overhead. I understand why the argument is appealing. First [AI](https://leaddev.com/ai/your-ai-coding-tools-buying-checklist-for-2026) 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](https://leaddev.com/culture/holding-effective-coaching-conversations), 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](https://leaddev.com/career-development/how-return-work-after-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](https://leaddev.com/career-development/how-return-work-after-parental-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](https://leaddev.com/career-development/the-reality-of-being-a-senior-engineer) 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](https://leaddev.com/ai/as-ai-helps-us-write-more-code-whos-catching-the-bugs) 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](https://leaddev.com/velocity/writing-code-was-never-the-bottleneck) 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](https://leaddev.com/ai/ai-generated-code-sparks-production-confidence-crisis) 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](https://leaddev.com/reporting/ai-productivity-gains-are-closer-to-10-than-10x), 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](https://leaddev.com/ai/managing-the-ai-driven-developer-identity-crisis). 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](https://leaddev.com/management/tactics-developing-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](https://leaddev.com/ai/ai-coding-tools-could-be-breaking-the-junior-engineer-pipeline) stepping up to one day take their place. #### Translation is the permanent work of engineering management Beyond development, someone needs to [own the communication](https://leaddev.com/communication/how-communicate-executive-audience) 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](https://leaddev.com/ai/ai-adoption-has-to-be-driven-from-the-top) 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](https://leaddev.com/software-quality/meta-turned-engineers-judgment-into-agent-skills) 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., Long Live the Engineering Manager, Liz de Moll, 01m5a1h107mxvka9ebg43a7de9.