Long Live the Engineering Manager - CourtneyR.dev's 2nd Brain

Long Live the Engineering Manager ![rw-book-cover](https://res.cloudinary.com/leaddev/image/upload/f_auto/q_auto/dpr_auto/c_limit,w_1920,h_1080/next/2024/10/article-hero-leadership.png) 🔗 **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 uncertain.** The central empirical claims (misalignment cost rises with speed, flattened orgs push coordination onto engineers) are asserted from one experience and reasoning. The captured text cites no study. Several anchor links point to other LeadDev articles that may support them (see References). ## 🗒️ Notes #### 📄 ¶1-¶4 Key takeaways box - Three bullets summarize the thesis: AI removes status updates but not judgment work; faster code generation raises the cost of misalignment; removing managers shifts dependency work to engineers. - The box is part of the captured text, so it is a LeadDev house format rather than a separate abstract by the author, as far as the capture shows. - The third bullet previews the closing line in ¶35. #### 📄 ¶5-¶7 The argument being answered - The author says she has "lost count" of articles claiming management is on the way out, and that they predate AI but have grown more common over three years. - The common pattern: hierarchy flattens, managers aren't needed, AI makes engineers capable enough that managers are overhead. - She calls the argument appealing and logical: more capability, faster shipping, flatter org chart. #### 📄 ¶8-¶9 What goes and what stays - Status updates and progress tracking should move to AI, and the author says managers shouldn't have owned them. - The work she says remains: expectation-setting, performance coaching, prioritization, alignment, translation up and down the leadership chain. - Her distinction is mechanical toil versus interpretive work that needs judgment. #### 📄 ¶10-¶15 What happened during two leaves - Setup: strong teams, hand-off documentation, knowledge transfer, a coverage plan. - Result after weeks: nothing major broke, alignment slipped, expectations got fuzzy, "everything felt a bit taped together." - Engineers absorbed coordination and business noise. Outside leaders drifted toward execution detail. Colleagues told her afterward they hadn't seen her invisible work until it stopped. #### 📄 ¶16-¶21 Faster code, same delivery problems - The author allows that senior engineers or a redistributed org could carry parts of the work, but says redistribution matters more when AI speeds implementation. - Product decisions, architecture, testing, security, rollout, and customer needs haven't sped up at the rate of code generation. - Misalignment cost rises with speed. Managers protect engineers from non-building work, which protects AI's velocity gain. #### 📄 ¶22-¶25 Coaching engineers through AI - Senior engineers: the shift from writing every line to answering for AI-assisted output is described as an identity change. - Junior engineers: balance experimentation with engineering judgment. - Coaching matters beyond AI. Someone has to develop today's seniors and the next cohort. #### 📄 ¶26-¶29 Translation as permanent work - Leadership's "invest in AI acceleration" lands as an instruction about how engineers do their jobs. - The essay lists unanswered adoption questions: skepticism, what counts as adoption, where experiments fit versus reliability. - AI adoption is one example of a standing category of manager work. #### 📄 ¶30-¶35 Fragmentation and the closing claim - Five dependent teams reading one strategy five ways produce standards drift, inconsistent decisions, duplicate work, and late-found dependencies, with no one making an individual mistake. - The author concedes AI will likely help with judgment later, but says need is rising faster than automation. - The closing line: removing hierarchy removes the people whose job it is to manage dependencies. ## 📚 References The link list has 21 entries: the article's own URL (twice, one with empty anchor text and one with the hero image alt), plus 19 links to other LeadDev pages. All are LeadDev's own articles. No link in the capture points to a study, dataset, or external primary source. Anchor text is the article's. I haven't opened any of these pages, so what each contains is unknown beyond its URL slug. **Article** - [Long live the engineering manager](https://leaddev.com/management/long-live-the-engineering-manager), Liz de Moll, LeadDev. Publication date not in the captured text. - Hero image alt text: "article hero – leadership" (same URL). **Links in the body, grouped by the claim they sit under** - ¶5 "engineering management" and "AI era": [the reality of being an engineering manager](https://leaddev.com/career-development/the-reality-of-being-an-engineering-manager), [best AI coding assistants](https://leaddev.com/ai/best-ai-coding-assistants) - ¶6 "flattening": [Coinbase flattens management and trims workforce in AI-driven restructure](https://leaddev.com/ai/coinbase-flattens-management-and-trims-workforce-in-ai-driven-restructure) - "engineering managers" (appears in ¶4, ¶6, ¶8; the capture doesn't show which one carries the link): [how engineering managers actually get rated](https://leaddev.com/management/how-engineering-managers-actually-get-rated) - "AI" (the capture doesn't show which paragraph): [your AI coding tools buying checklist for 2026](https://leaddev.com/ai/your-ai-coding-tools-buying-checklist-for-2026) - "coaching" (appears in ¶2, ¶9, ¶25; the capture doesn't show which): [holding effective coaching conversations](https://leaddev.com/culture/holding-effective-coaching-conversations) - ¶11 "parental leave" and ¶14 "When I returned from leave": [how to return to work after parental leave](https://leaddev.com/career-development/how-return-work-after-parental-leave) (same URL both times) - ¶16 "Senior engineers": [the reality of being a senior engineer](https://leaddev.com/career-development/the-reality-of-being-a-senior-engineer) - ¶17 "AI generates code faster": [as AI helps us write more code, who's catching the bugs](https://leaddev.com/ai/as-ai-helps-us-write-more-code-whos-catching-the-bugs) - ¶18 "Writing code": [writing code was never the bottleneck](https://leaddev.com/velocity/writing-code-was-never-the-bottleneck) - "cost of misalignment" (appears in ¶3 and ¶19): [AI-generated code sparks production confidence crisis](https://leaddev.com/ai/ai-generated-code-sparks-production-confidence-crisis) - ¶21 "velocity gains of AI": [AI productivity gains are closer to 10% than 10x](https://leaddev.com/reporting/ai-productivity-gains-are-closer-to-10-than-10x) - ¶23 "don’t recognize the job they were hired to do": [managing the AI-driven developer identity crisis](https://leaddev.com/ai/managing-the-ai-driven-developer-identity-crisis) - ¶25 "coach more junior engineers": [tactics for developing junior engineers](https://leaddev.com/management/tactics-developing-junior-engineers); "next class of engineers": [AI coding tools could be breaking the junior engineer pipeline](https://leaddev.com/ai/ai-coding-tools-could-be-breaking-the-junior-engineer-pipeline) - ¶27 "own the communication": [how to communicate to an executive audience](https://leaddev.com/communication/how-communicate-executive-audience) - ¶29 "AI adoption": [AI adoption has to be driven from the top](https://leaddev.com/ai/ai-adoption-has-to-be-driven-from-the-top) - ¶33 "assist with the judgment": [Meta turned engineers' judgment into agent skills](https://leaddev.com/software-quality/meta-turned-engineers-judgment-into-agent-skills) **What the links mean for the claims.** The headline-level claims about speed, misalignment cost, and productivity gains each sit next to a LeadDev link whose slug suggests supporting or related coverage (for example the "10 not 10x" slug under ¶21). The slugs are the only evidence in the capture of what those pages say. The leave anecdote (¶11-¶15) and the five-team scenario (¶31) have no source link beyond the parental-leave how-to. Those two carry no link in the captured markup to any evidence. The author is not reported as citing a study for any claim. ## 🗣️ Paraphrase Liz de Moll opens by saying she keeps seeing articles that declare engineering management finished, on the theory that AI makes engineers capable enough that managers are overhead. She sees why that's tempting and agrees that status updates and progress tracking should go to AI. Her objection is that managers also set expectations, coach, prioritize, keep teams aligned, and translate between levels, and those tasks take judgment, which AI hasn't replaced. She supports this with two parental leaves. Her teams were strong and well prepared, and nothing major broke, but alignment slipped, expectations blurred, engineers did coordination they wouldn't normally handle, and senior leaders slid toward day-to-day detail. When she returned, colleagues told her they hadn't noticed how much invisible work she did until it stopped. She then argues that AI raises the stakes. Code arrives faster, but product decisions, testing, security, and rollout haven't sped up, so misalignment costs more and there's less time to fix it. Engineers also need coaching: seniors are moving from writing code to answering for AI-assisted output, and juniors need guidance on judgment. And someone has to translate leadership's strategy into team decisions, or five dependent teams will each interpret it differently and produce drift, duplicate work, and late-found dependencies. She allows that AI may take on more of the judgment work and may change how many managers there are, but says it doesn't remove the work. Flattening removes the people whose job is to manage dependencies, not the dependencies. ## 📰 Newsletter **Does AI make the engineering manager redundant? One manager says the work just moves.** Liz de Moll's LeadDev essay answers the "managers are overhead" argument with an experience: during two parental leaves, her well-prepared teams kept shipping, but alignment loosened, expectations blurred, and engineers picked up coordination work that wasn't theirs. Her argument, in three points: AI should take status updates, but not coaching, prioritization, or alignment. Faster code generation makes misalignment cost more because the rest of delivery (decisions, testing, security, rollout) hasn't sped up as much. And leadership's AI mandates need someone to translate them, or teams drift into different readings of one strategy. It's an opinion piece from an engineering manager, built on one anecdote plus reasoning, with many links to related LeadDev coverage. Worth reading with that in mind, and worth taking the three questions it raises to your own org: who owns coaching through AI change, who translates strategy, and who notices when five teams read the same plan five ways. Read the original: [Long live the engineering manager](https://leaddev.com/management/long-live-the-engineering-manager). ## ✅ Action items These items concern a reader's own team structure and practices. They don't assess whether engineering managers are needed in any specific org. #### DevRel - Developer advocacy: if you cite this essay, label it as an opinion piece from an engineering manager and name the anecdote as its main evidence. - Education: build a workshop on "AI adoption questions" using the list in ¶28 (skepticism, what counts as adoption, where reliability beats experimentation) and let teams answer them for their own context. - Developer experience: if DevRel runs developer surveys, add a question on who translates leadership's AI direction into team-level guidance. - Developer marketing: avoid framing "AI replaces managers" or "managers survive AI" as settled. Cite the essay's hedges in ¶16 and ¶33-¶34. - Community management: for communities with many engineering managers, host a discussion on what coordination work moves to engineers when a manager leaves, using ¶12-¶14 as a prompt. - Internal/external: align DevRel's own strategy messages so each team can restate the strategy in the same terms (the ¶31 scenario). #### OSPO - Policy and governance: write down who owns decision translation between maintainers, sponsors, and contributors, so removing a coordinator role doesn't move it silently (¶15). - License compliance: no direct action from this source. - Security management: no direct action; nearest relevance is the essay's list of delivery parts that haven't sped up with code generation, including security (¶18). - Software inventory: no direct action from this source. - Developer support: prepare a coaching path for maintainers shifting to reviewing AI-assisted contributions (¶24 describes the shift for senior engineers). - Community engagement: no direct action from this source. - Strategic alignment: check whether each project team can state the program's strategy in one sentence, and compare answers. #### Community - Maintainers: before a maintainer steps away, write a coverage plan that names who handles alignment and expectations, not only tasks. The essay's leave setup had hand-off documents and coverage, and alignment still slipped (¶11-¶12). - Contributors: pair newer contributors with an experienced reviewer who coaches judgment on AI-assisted changes (¶25). - Sponsors: no direct action from this source. - Ecosystem: no direct action from this source. #### WordPress - Core: no direct action from this source; nearest relevance is cross-team dependency tracking during release cycles (¶31-¶32). - Core Performance: no direct action from this source. - Core AI: if guidance on AI-assisted contribution exists, name who helps contributors with judgment, not only tooling (¶24-¶25). - Core Program Team: review whether cross-team dependencies and the strategy-to-tactics translation have a named owner, and run a short retrospective on late-found dependencies (¶30-¶31). - Mobile: none from this source. - Playground: none from this source. - Community: meetup and WordCamp organizers could host a session on running a team through a leader's absence (¶11-¶15). - Training: no direct action from this source; nearest relevance is a lesson on coaching in the context of AI-assisted work. - Marketing: none from this source. - Support: none from this source. - Design: none from this source. - Documentation: no direct action from this source; nearest relevance is documenting decision ownership so it survives a coordinator's absence. - Photos: none. - TV: none. - Polyglots: no direct action from this source; nearest relevance is locale team leads as translators of project priorities (¶27). - Accessibility: none from this source. - Meta: none from this source. - CLI: none. - Hosting: none from this source. - Tide: none. - Openverse: none. - Themes: none from this source. - Plugins: none from this source. #### The WPOCC - Programs: no direct action from this source; nearest relevance is mentorship tracks that include coaching for judgment on AI-assisted work (¶25). - Projects: no direct action from this source. - Funding experiments: none. ### FAIR - Technical independence: no direct action from this source. - Policies and covenants: no direct action from this source. - Productized governance artifacts: if charters assign coordination duties, state who carries each one when a role is vacant (¶15). ## 🧪 Hypotheses 1. Teams whose manager is absent for 4 or more weeks show more late-discovered cross-team dependencies than matched teams with a manager present, even when documentation and coverage plans exist. 2. Engineers on teams without a manager spend a higher share of their week on coordination (meetings, messages, cross-team threads) than engineers on teams with one. 3. After an org adopts AI coding tools, the time from a code-complete change to production grows relative to code-writing time (the essay says the other delivery steps haven't accelerated at the same rate, ¶18). 4. Strategy statements restated by members of five dependent teams diverge more in orgs that removed a management layer than in orgs that kept it. 5. Senior engineers who receive structured coaching on AI-assisted work report a smaller identity-shift problem (¶24) than those who don't. 6. Readers who see the essay's anecdote alone rate the claim "managers remain necessary" as more credible than readers who see the same claim without it. ## 📊 Methodology - **H1.** Pull project-tracker and incident data for teams with a leave or vacancy of 4 or more weeks, and for matched controls. Count dependencies first logged after work started, and compare rates. Control for team size and domain, and note that leave coverage plans vary. - **H2.** Use calendar and chat metadata (with consent and aggregation) to measure coordination time per engineer before, during, and after a manager's absence. Cross-check with a short self-reported time survey. - **H3.** Measure cycle-time stages (coding, review, test, security, deploy) per change across the AI adoption date for a set of teams. Compare the proportion of time in each stage before and after. - **H4.** Ask a sample of engineers across teams to restate the current strategy in one paragraph. Have raters code divergence from the source statement. Compare orgs by management-layer count, controlling for org size. - **H5.** Run a pilot where one cohort of senior engineers gets monthly coaching and a comparison cohort doesn't. Survey for role clarity and perceived value at baseline and 3 months. - **H6.** Randomize readers into two versions of the argument, one with the leave anecdote and one without, then rate credibility on a standard scale. Keep word count equal. ## ❓ Questions - How long were the two leaves, and how many reports did the author have? The text says "weeks" (¶12) and gives no team size. - What did the colleagues who said they hadn't realized the extent of the invisible work (¶14) say specifically, and would a different manager's absence produce the same result? - Which parts of the manager role did senior engineers pick up, if any, and could a deliberate redistribution have prevented the drift the author describes (¶16)? - Does the essay's claim that non-code delivery steps haven't sped up (¶18) hold in data from teams that have used AI tools for a year or more? The linked "10 not 10x" article suggests that line of evidence exists, but the capture doesn't state it. - What counts as "meaningful adoption" of AI (¶28), and who decides? - If AI takes over the judgment work later (¶33), what's the first piece of the manager role that moves, and what signals it? - How would the "five teams, five interpretations" failure (¶31) show up in a metric before it shows up as duplicate work? - What would the author accept as evidence that a flattened org handled the coordination work without a manager? ## 🔮 Future research - **Absence studies.** Measure what changes on a team during planned manager absences across companies, using the same indicators (dependencies, rework, engineer coordination time). - **Flattened-org outcomes.** Compare delivery, retention, and engineer-reported clarity in orgs before and after management-layer cuts that cite AI, using the Coinbase example the essay links as one case. - **Coaching for AI-assisted work.** Define what good coaching looks like for seniors shifting from authoring to accountability (¶24), and test whether it changes outcomes. - **Strategy-translation fidelity.** Build a repeatable way to measure how closely teams' restated strategies match the source, and track drift over time. - **Where AI helps judgment.** Track which parts of the managerial role AI tools handle credibly, which the author says is likely in the future (¶33). ## 💡 Implications - **Practice.** Before cutting a management layer, list the interpretive duties in ¶9 and name an owner for each. The essay's central warning is that unowned work lands on engineers (¶13). - **Policy.** Leave and coverage plans should name who holds alignment and expectation-setting, not only task hand-offs. The author's plan covered tasks and still lost alignment (¶11-¶12). - **Security.** Security is on the essay's list of delivery work that hasn't accelerated like code generation (¶18). A faster code path with a slower review path raises the gap between code written and code that's safe to ship. - **Education.** Engineering managers and engineers can use the essay's three-part split (mechanical toil, interpretive work, translation) as a vocabulary for discussing which tasks to automate. - **Funding.** The essay gives no cost figures. A funding case for the manager role would need data on the cost of fragmentation (duplicate work, late dependencies, standards drift) that the essay names but doesn't measure. - **Reader caution.** The essay is advocacy from a person in the role. Pair it with data before using it to justify headcount. ## 🧠 Learning styles assessment - **Reading level estimate.** About 1,290 words of body text (excluding the key-takeaways box). Using a simple vowel-group syllable count, I get a Flesch Reading Ease of about 48 and a Flesch-Kincaid Grade Level of about 11, which is college-entry level. Long sentences with abstract nouns ("interpretive," "fragmentation," "sense-making") push it up. The estimate is approximate, not from a calibrated tool. #### 👀 Visual learners - Present: one hero image (alt text "article hero – leadership"). No diagrams, charts, or tables appear in the captured text. - Improve: a diagram of the "shallow" and "deeper" coordination layers (¶20), and a before/after of where coordination work lands when the manager leaves (¶13-¶14). #### 🔊 Aural learners - Present: no audio, podcast, or narration is referenced in the captured text. - Improve: a 2-minute audio summary of the three takeaways. #### 🗣️ Verbal learners - Present: short paragraphs, plain sentences, an anecdote, and a memorable closing line (¶35). The "Key takeaways" box gives a quick verbal summary. - Improve: define "flattening," "shallow coordination," and "interpretive work" in one sentence each, and name examples of each. #### 🧩 Kinesthetic learners - Present: no exercise, template, or checklist. - Improve: a worksheet that lists the duties in ¶9 and asks the reader to name who covers each during a manager's absence. #### 🧠 Logical learners - Present: a clear structure, with premise (managers do interpretive work), mechanism (speed raises misalignment cost), and conclusion (hierarchy removal doesn't remove dependencies). - Improve: state the argument as numbered premises and mark which are experience-based and which are reasoning, so a reader can test each. #### 🧑‍🤝‍🧑 Social learners - Present: the anecdote involves team and leadership reactions (¶14), and the topic invites discussion. - Improve: add discussion prompts for a team to answer, such as the adoption questions in ¶28. #### 🧘‍♀️ Solitary learners - Present: reflective first-person narrative. - Improve: add self-check questions, such as "who does this work on your team when your manager is out?" #### 🌿 Naturalistic learners - Present: none; the text uses no environmental or ecosystem analogies. - Improve: an analogy to a system losing a connective role and the load shifting to other parts (a systems-thinking frame) would fit the ¶15 point. ## 📊 Accessibility assessment Judged from the captured text, link list, and image alt file only. Rendered contrast, focus order, and page structure are unknowable from this capture. #### Screen reader semantics - Present: four lines are formatted as subheads in the capture ("What happens when the engineering manager leaves," "Your senior engineers need a coach now," "Translation is the permanent work of engineering management," plus the key-takeaways label). The capture marks three with "##", which suggests real H2 headings. The one hero image has alt text "article hero – leadership." - Improve: confirm the headings are real elements in order (WCAG 2.2 AA 1.3.1 Info and Relationships, 2.4.6 Headings and Labels). The alt text names the image's role but doesn't describe its content, so check it against 1.1.1 Non-text Content. #### Keyboard navigation - Present: 21 links in the list, all ordinary anchors as far as the capture shows. - Improve: not verifiable from text. Check 2.1.1 Keyboard and 2.4.7 Focus Visible on the rendered page. #### Contrast and readability - Present: unknowable from the capture. Paragraphs are short, with one idea each, and the font and color aren't visible. - Improve: verify 1.4.3 Contrast (Minimum) for body text and link color. #### Text resizing and reflow - Present: text-only content should reflow, and the capture shows no fixed-size media beyond the hero image. - Improve: verify 1.4.4 Resize Text and 1.4.10 Reflow at 320 CSS px and 200% zoom. #### Media and captions - No media referenced in the captured text. The one image is the hero. The text mentions no captions or transcripts, and there is no embedded video or audio. #### Forms and interactions - Present: no form appears in the captured text. - Improve: if a newsletter signup or comment form exists on the page, check 3.3.2 Labels or Instructions. #### Standards reference - Likely gaps to check against WCAG 2.2 AA: **2.4.4** Link Purpose (In Context), because many anchors are short single words ("AI," "coaching," "flattening," "engineering managers") that depend on surrounding text, and two anchors appear to repeat with different surrounding context. **1.1.1** for the hero alt text. **1.3.1** for the heading levels. Everything else needs the rendered page. ## 🌍 DEIB assessment #### Cultural breadth - Present: the essay speaks generally about "engineering organizations" and gives no geography. It mentions parental leave, which is a benefit that differs widely by country and employer. - Improve: say whether the leaves were paid and how long they ran, since leave length and coverage vary by region and affect whether the anecdote generalizes. #### Inclusive language - Present: plain English, with few idioms. "Taped together" (¶12) and "bogging them down" (¶21) are mild idioms. Jargon like "sense-making" and "shallow coordination layer" is left undefined. - Improve: define the terms and avoid idioms for readers working in a second language. #### Neurodiversity support - Present: a key-takeaways box up front, headed sections, short paragraphs, consistent structure. - Improve: more subheads in the long opening section (¶5-¶9) and in the translation section (¶26-¶32), plus a one-line summary at the start of each. #### Representation - Present: the author writes from the manager's perspective and names engineering roles (senior, junior, leaders), not individuals. The text states no one's gender, and I use none for the author. - Improve: the essay speaks only for managers' experience. Quotes or accounts from engineers who worked through a manager's absence would balance the perspective. #### Psychological safety - Present: the tone is measured, and the essay credits colleagues who covered the author's work and acknowledges that managers aren't the only people capable of it (¶16). - Improve: the passage on engineers' "identity shift" (¶24) could note that the discomfort is a normal response and say where to get support. ## ✅ Logical validity #### Strong reasoning - **Fair statement of the opposing view, ¶5-¶8.** The author describes the "managers are overhead" argument, grants its logic, and concedes that status work should go to AI. That makes the later disagreement narrower and easier to assess. - **Mechanism, ¶17-¶19.** The speed claim comes with a mechanism: code generation accelerates, other delivery steps (decisions, testing, security, rollout) don't, so misalignment costs more and coordination time shrinks. A reader can test each step. - **Concrete scenario, ¶31.** The five-team example shows how fragmentation arises with no individual error, which makes the "invisible risk" claim intelligible. - **Hedging, ¶16, ¶33-¶34.** The author concedes that senior engineers may carry parts of the work, that AI will probably assist with judgment later, and that the manager count or role name may change. The thesis is that the work persists, not that the current role does. - **Clear thesis, ¶35.** The closing sentence is a compact, falsifiable form of the claim: removing hierarchy removes the people who manage dependencies, not the dependencies. #### Fallacies No formal fallacy dominates, and the piece is advocacy by an interested party, so the points below are weaknesses in evidence and framing. - **Anecdote as evidence, ¶11-¶15.** "Both times I went on parental leave..." is one person's experience with a well-prepared team over "weeks," and the essay generalizes from it to the claim that management layers matter. *Fix:* say how many teams, how long, and whether any outcome was measured, or label it as an illustration. - **Self-interest, whole piece.** An engineering manager argues the manager role is valuable. This isn't a fallacy, but the essay doesn't acknowledge it, and a reader should weigh it. *Fix:* a one-line acknowledgment. - **Begging the question, ¶9.** The essay says the remaining work "isn’t about mechanical toil" and requires judgment, then argues that managers are needed because that work exists. It doesn't show that managers, as opposed to senior engineers or others, are the necessary owner. ¶16 partly answers this by conceding the point. *Fix:* argue directly why a dedicated role beats distributing the work. - **False dichotomy framing, ¶6.** The essay characterizes the opposing view as "we don’t need engineering managers" and "all a manager provides is additional overhead." Some flattening proposals keep coordination roles under a different structure. The author acknowledges this in ¶16 and ¶34, so the effect is partial. *Fix:* engage a specific flattening proposal. - **Unsupported empirical claim, ¶18-¶19.** "Those aspects haven’t necessarily accelerated at the same rate as code generation" and "the cost of misalignment rises just as quickly" are stated without a figure. The nearby links (the "10 not 10x" and "writing code was never the bottleneck" slugs) suggest related coverage, but the capture states no number. *Fix:* cite the data in the sentence. - **Slippery slope, ¶32.** "Fragmentation... invisible until things stop working as they should" moves from reasonable local decisions to expensive failure without showing how often that chain occurs. *Fix:* give an example or an incidence figure. **Injection check.** I looked for text addressed to an AI, an assistant, or "the reader" in the article and link list. The article contains none. The link list contains only URLs and anchors. #### Tone of voice - Reflective, first-person, and conversational, with a confident thesis voice. Examples: "I’ve lost count" (¶5), "Everything felt a bit taped together" (¶12), and the rhetorical questions in ¶28 ("Who is investing time getting engineers past the hurdle of skepticism..."). The title, "Long live the engineering manager," is celebratory. It's advocacy, with measured concessions in ¶16 and ¶33. ## 🛡️ DARVO analysis Not applicable to this source. DARVO (Deny, Attack, Reverse Victim and Offender) describes a response to an accusation, and this essay isn't responding to one. It argues against a published genre of claims. Each prong is checked anyway. - **Deny.** None. The author doesn't deny a charge. Disagreeing with "managers are obsolete" is a counter-argument, and the essay concedes several points (¶8, ¶16, ¶33). - **Attack.** None aimed at people. The opposing articles are characterized as following "similar themes" (¶6) and as breaking down at one assumption (¶9), which targets the argument, not the authors. - **Reverse victim and offender.** None. The essay doesn't cast managers as victims of critics. It describes engineers as bearing the cost when the manager layer disappears (¶13), which is a claim about workload, not about blame. - **Emotional cues.** "Invisible work" and the "identity shift" for senior engineers (¶14, ¶24) carry some emotional weight, and the essay uses them to illustrate an argument, not to deflect. ## 🎯 Conclusion The essay argues that AI removes managers' shallow coordination work (status updates, progress tracking) but not the interpretive work of coaching, prioritization, alignment, and strategy translation. Its main support is the author's two parental leaves, where alignment slipped and engineers and leaders absorbed the work, plus a mechanism: faster code generation raises the cost of misalignment because other delivery steps haven't accelerated at the same rate. The closing claim is that removing hierarchy doesn't remove dependencies. What the essay doesn't establish: how often or how badly flattened orgs fail, whether another structure could carry the work at lower cost, and any figure for the cost of fragmentation. The captured text states no data, and the many linked LeadDev articles may supply some. The author is an engineering manager, which is worth weighing. **Next steps for readers:** list the duties in ¶9 for your own team and name who covers each when the manager is out. Ask who translates leadership's AI direction into your team's decisions. If you cite the essay, label it as an opinion piece, and open the linked LeadDev pieces on productivity gains and misalignment before using them as evidence. ## 🔄 Refactor Appendix — Long live the engineering manager > Density: 2–5 Literature atoms (H3 pad), 0–3 Permanent candidates (H4 pad). > Emitted: 5 Literature, 2 Permanent. Resonance filter applied: the key-takeaways > box (¶2-¶4) was dropped as duplicate of ¶9, ¶19, and ¶35. > > Konik claim-header rules: present tense, declarative, ≤10 words, searchable, unique. > > Atomicity: one declarative sentence per atom. "and"/"also" → split. > > Tag pool: #bmf · #addendum · #xref · #articleseed · #storystem · #share · #aphorisms ### 📚 Literature Split Pad #### [H1] Removing hierarchy leaves the dependencies in place > [!quote] [¶35] > Removing hierarchy doesn’t remove dependencies. It just removes the people whose job it is to manage them. **Context & use**: - ¶35, the essay's closing line and thesis in compact form. - It's an assertion, supported in the essay by one anecdote and the five-team scenario. Use it as a claim to test, not a finding. **Tags**: #xref #aphorisms  #### [H2] AI removes shallow coordination and exposes deeper coordination > [!quote] [¶20] > AI is removing the shallow coordination layer and exposing the deeper one. **Context & use**: - ¶20, the essay's central image. "Shallow" is status and progress work, and "deeper" is how work connects across teams and how strategy translates into tactics. - The essay doesn't define the two layers beyond that description. Define them before reusing the terms. **Tags**: #xref #articleseed  #### [H3] Faster teams pay more for misalignment > [!quote] [¶19] > When teams start to move faster, the cost of misalignment rises just as quickly. **Context & use**: - ¶19, the speed-to-misalignment mechanism. The essay gives no figure. - Pair with ¶18, where the author lists delivery steps that haven't sped up with code generation. **Tags**: #xref  #### [H4] Senior engineers face an identity shift > [!quote] [¶24] > That’s not a tooling change so much as an identity shift **Context & use**: - ¶24, on senior engineers moving from authoring every line to being responsible for AI-assisted output. - It frames the coaching need as about role identity, not tool training. The captured text offers no survey or other data for it. **Tags**: #xref #share  #### [H5] A manager's absence blurs alignment and expectations > [!quote] [¶12] > nothing major broke, but it was clear even in the limited time I was absent that alignment was never quite achieved **Context & use**: - ¶12, the core of the anecdote. One manager, two leaves, "weeks," with hand-off documents and a coverage plan. - It's an observation by the person who was absent. The essay reports no measurement. **Tags**: #xref #articleseed  ### 🧠 Atomic Split Pad #### [P1] Unowned coordination lands on whoever is nearby **Claim** (one sentence, Courtney's voice): When a coordination role disappears, the work doesn't go away, it moves to people whose attention was meant for something else. **Evidence pointer**: [[#H5]] · [[#H1]] **Scope & conditions**: Holds when the work is a real duty (alignment, expectations, translation) and not toil that can be automated or dropped. Weakens if the work is deliberately redistributed with named owners, which the essay allows for in ¶16. The evidence is one anecdote, so treat the claim as plausible and untested. **Links**: - [[Hidden work in teams]] — because extends - [[Automating status reporting]] — because contrasts on toil versus judgment work - [[Flattening a management layer]] — because applies-in AI-era org changes  #### [P2] Speed raises the price of unaligned teams **Claim** (one sentence, Courtney's voice): When code arrives faster than decisions, testing, and rollout, the cost of teams working from different readings of the plan goes up. **Evidence pointer**: [[#H3]] · [[#H2]] **Scope & conditions**: Holds when non-code delivery steps haven't sped up in proportion (¶18). Doesn't hold if those steps accelerate too. The essay states the mechanism without a figure, so test it against cycle-time data. **Links**: - [[Writing code was never the bottleneck]] — because extends - [[Cross-team dependencies]] — because applies-in strategy translation across dependent teams - [[Coordination cost in software teams]] — because evidence-for the claim that more speed shortens coordination time  ### ✏️ Fleeting Queue - [F1] Check the linked LeadDev "AI productivity gains are closer to 10% than 10x" piece for the figures behind ¶21 — https://leaddev.com/reporting/ai-productivity-gains-are-closer-to-10-than-10x #fleeting #inbox - [F2] List the duties in ¶9 for my own team and name who covers each when I'm out #fleeting #inbox - [F3] Open question: how would five teams' divergent readings of one strategy (¶31) show up in a metric before duplicate work does? #fleeting #inbox - [F4] Article seed: "What moves when the coordinator leaves," a short post using ¶12-¶15 as the example #fleeting #inbox #articleseed - [F5] Note that the essay is advocacy from a manager and carries one anecdote, when citing it #fleeting #inbox ### → Things 3 (max 2 actions) - [ ] Write down who owns alignment, expectations, and strategy translation on my team during an absence — team practice, 30 min #things - [ ] Read the linked LeadDev pieces on AI productivity gains and misalignment and note which figures support ¶18-¶21 — research, 45 min #things  📄 **Full text:** [[Full Document Contents/Articles/Long Live the Engineering Manager.md|Long Live the Engineering Manager by Liz de Moll]] ## Highlights - 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. ([View Highlight](https://read.readwise.io/read/01m5a2encemk057y8n3nm2cg8r)) - Note: [H5] A manager's absence blurs alignment and expectations - Tags: atom/literature/h3 - 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. ([View Highlight](https://read.readwise.io/read/01m5a2egf5j2gcwwz1mrqdye9s)) - Note: [H3] Faster teams pay more for misalignment - Tags: atom/literature/h3 - 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. ([View Highlight](https://read.readwise.io/read/01m5a2ee57kmn83pbss15a03j7)) - Note: [H2] AI removes shallow coordination and exposes deeper coordination - Tags: atom/literature/h2 - 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. ([View Highlight](https://read.readwise.io/read/01m5a2ek2dm729ns3yqev3hj3k)) - Note: [H4] Senior engineers face an identity shift - Tags: atom/literature/h3 - Removing hierarchy doesn’t remove dependencies. It just removes the people whose job it is to manage them. ([View Highlight](https://read.readwise.io/read/01m5a2ebsscp8gvkpk0t8rz8kb)) - Note: [H1] Removing hierarchy leaves the dependencies in place - Tags: atom/literature/h1