Engineering Managers Are Back in the Codebase ![rw-book-cover](https://res.cloudinary.com/leaddev/image/upload/f_auto/q_auto/dpr_auto/c_limit,w_1920,h_1080/next/2025/04/mandate-brink-02.jpg) 🔗 **Source:** [Engineering Managers Are Back in the Codebase](https://leaddev.com/management/engineering-managers-are-back-in-the-codebase) > [!note]+ Document Notes > > [!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. > > --- > tags: [engineering-management, ai-coding-tools, player-coach, technical-leadership, developer-productivity] > author: [MISSING] > source: LeadDev > reference: https://leaddev.com/management/engineering-managers-are-back-in-the-codebase > date created: 2026-08-10 > > --- > > # 🏷️ Title: Engineering managers are back in the codebase > <!-- deep-read:sections start --> ## 🧭 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) ### 🔗 References - [Engineering Leadership Report 2026](https://leaddev.com/the-engineering-leadership-report-2026/) — LeadDev - [Pragmatic Engineer: Engineering leadership skillset overlaps (2021 diagram)](https://newsletter.pragmaticengineer.com/p/engineering-leadership-skillset-overlaps) - [Pragmatic Engineer: the "player-coach" ZIRP prediction (2024)](http://newsletter.pragmaticengineer.com/p/zirp-engineering-managers) - [Business Insider: Zuckerberg moves desk, codes again](https://www.businessinsider.com/mark-zuckerberg-moved-desk-coding-again-sits-by-alexandr-wang-2026-4) - [Livemint: Sergey Brin comes out of retirement to code on Gemini](https://www.livemint.com/technology/tech-news/google-co-founder-sergey-brin-comes-out-of-retirement-to-code-on-google-s-gemini-calls-ai-era-most-exciting-11748001805755.html) ## 📝 Summary - What happened: LeadDev's Engineering Leadership Report 2026 shows engineering managers writing more code again — EM hands-on technical work rose from 20% (2025) to 35% (2026), and hands-on time rose across every leadership tier (tech leads 41%, managers of engineers 31%, managers of managers 30%, CTOs 44%). - Why it matters: AI coding assistants have lowered the barrier to producing working software, so the 2024 "player-coach" prediction (managers who both lead and code) is now measurable reality rather than a projection. - Key stakeholders: engineering managers, CTOs, tech leads, Spotify EM Emma Bostian, Bloomberg's Paul Williams, and high-profile examples (Mark Zuckerberg, Sergey Brin) used as anecdotal color. - Risks and tradeoffs: the article and its sources explicitly warn against managers becoming "another engineer" — the risk is EMs drifting from people-leadership and stakeholder work back toward IC-shaped output, diluting their core value. - Bottom line: AI didn't create a new manager archetype so much as remove the technical excuse for staying out of the codebase; the debate now is how much hands-on coding is additive versus a distraction from the job's actual leverage points. ## 📖 Main Content - The piece opens with two celebrity anecdotes (Zuckerberg, Brin) to dramatize a broader statistical trend, then pivots to LeadDev's own survey data as the real evidence. - Core term: "player-coach" — a manager who still plays (codes) while coaching (leads people). Attributed to Gergely Orosz's 2024 Pragmatic Engineer prediction, itself a follow-up to his 2021 diagram that placed EMs outside the "code circle," at the intersection of people and stakeholder management. - The causal claim in the piece is that generative AI coding tools lowered the *skill and time* cost of producing code, which re-opened coding as a viable use of an EM's limited hours — not that EMs became better engineers or that the job description formally changed. - Contested/uncertain: the article does not disclose survey methodology (sample size, selection, definition of "hands-on technical work") beyond citing percentages from the Engineering Leadership Report 2026, so the causal link between AI adoption and the 15-point EM increase is asserted, not demonstrated with a controlled comparison. - Two practitioner voices push back on over-interpreting the trend: Bostian frames the value of staying technical as informational (credibility, situational awareness) rather than output-driven, and Williams argues the EM's core job (vision, stakeholder alignment, consensus-building, team environment) is unchanged — hands-on coding is only useful insofar as it unblocks the team on non-critical-path work. ### 🗒️ Notes - Numbers to remember: EM hands-on work 20%→35% YoY; overall leader hands-on increase 37%; tech leads 41%, managers of engineers 31%, managers of managers 30%, CTOs 44%. - Two framings sit in tension throughout: "AI restored the player-coach model" (structural/statistical framing) vs. "coding again doesn't mean becoming another engineer" (normative/cautionary framing). The article never resolves which framing should dominate a given manager's calendar. - Zuckerberg/Brin anecdotes are survivorship-biased examples (founder-level authority, discretionary time, unusual stakes) used to illustrate a trend measured in a broader, presumably more representative, manager population — worth flagging when citing this piece as evidence for typical EM behavior. - Williams' "non-critical path work" framing is the most actionable operational filter offered: use hands-on coding to unblock ICs on work that isn't gating the roadmap, not to personally increase throughput on critical-path features. - No discussion of second-order effects: code review load, code ownership/on-call implications, or whether EM commits get the same review rigor as IC commits. ## 📚 References - [Engineering Leadership Report 2026](https://leaddev.com/the-engineering-leadership-report-2026/) - [The reality of being an engineering manager](https://leaddev.com/career-development/the-reality-of-being-an-engineering-manager) - [The end of the non-technical engineering manager](https://leaddev.com/career-development/the-end-of-the-non-technical-engineering-manager) - [Engineering managers have a new job description](https://leaddev.com/management/engineering-managers-have-a-new-job-description) - [How to stay technical as an engineering manager](https://leaddev.com/career-development/how-to-stay-technical-as-an-engineering-manager) - [Inside Bloomberg's flat engineering culture](https://leaddev.com/career-development/inside-bloombergs-flat-engineering-culture) - [Should managers still code? — The Engineering Manager](https://www.theengineeringmanager.com/growth/should-managers-still-code/) ## 🗣️ Paraphrase - Managers coding again isn't a fringe curiosity — LeadDev's own 2026 numbers show it happening at every leadership tier, and the shift tracks closely with the spread of AI coding assistants. - The practitioners quoted are careful to separate "staying technically credible" from "doing the engineer's job," suggesting the healthy version of this trend is bounded, situational, and secondary to people-leadership — not a full reversion to IC work. ## 📰 Newsletter - New data point for anyone tracking how AI tools reshape team roles, not just IC workflows: LeadDev's 2026 report finds engineering managers coding hands-on rose from 20% to 35% in a year, with the "player-coach" idea moving from prediction to measured pattern. Worth a skim if you manage engineers, mentor EMs, or run WPOCC/DevRel programs where technical credibility and people-leadership constantly trade off against each other. Useful companion to the "non-critical path work" framing as a practical guardrail for how much code a manager should actually be shipping. ## ✅ Action Items #### DevRel - Developer advocacy: n/a — not evaluating a developer product or program. - Education: consider referencing this data point in DevRel-manager career-path talks about staying technical without regressing to an IC role. - Developer experience: n/a. - Developer marketing: n/a. - Community management: n/a. - Internal/external/cross-project: if DevRel leads at courtneyr.dev-adjacent orgs are managers, use Williams' "non-critical path work" filter when deciding whether a DevRel lead should pick up hands-on coding tasks. #### OSPO - Policy & Governance: n/a. - License Compliance: n/a. - Security Management: n/a. - Software Inventory: n/a. - Developer Support: n/a. - Community Engagement: n/a. - Strategic Alignment: n/a — no OSPO-specific claims in source. #### Community - Maintainers: relevant analogy — maintainers who also manage contributor teams face the same player-coach tension; the "unblock non-critical path work" heuristic could apply to maintainer time allocation too. - Contributors: n/a. - Sponsors: n/a. - Ecosystem: n/a. #### WordPress - Core: n/a — article is general engineering-management research, not WordPress-specific. - Core Performance: n/a. - Core AI: tangential — the underlying driver (AI lowering the coding barrier) is directly relevant to any Core AI guardrail discussion about who is now capable of shipping code with AI assistance. - Core Program Team: n/a. - Mobile: n/a. - Playground: n/a. - Community: n/a. - Training: n/a. - Marketing: n/a. - Support: n/a. - Design: n/a. - Documentation: n/a. - Photos: n/a. - TV: n/a. - Polyglots: n/a. - Accessibility: n/a. - Meta: n/a. - CLI: n/a. - Hosting: n/a. - Tide: n/a. - Openverse: n/a. - Themes: n/a. - Plugins: n/a. #### The WPOCC - Programs: n/a — not directly applicable, no WPOCC-specific claims in source. - Projects: n/a. - Funding experiments: n/a. ### FAIR - Technical independence: n/a. - Policies and covenants: n/a. - Productized governance artifacts: n/a. ## 🧪 Hypotheses - H1: EM hands-on coding time correlates with AI coding-assistant adoption rate within the same org, not just calendar year. - H2: Managers who code more hands-on report higher technical credibility scores from their direct reports than managers who code less, controlling for tenure. - H3: Teams whose managers code on "non-critical path" work (per Williams' framing) ship faster than teams whose managers code on critical-path features, due to reduced context-switching for ICs. - H4: The 20%→35% EM increase is partly an artifact of survey self-selection (more technically active EMs opting into the 2026 survey) rather than a pure behavioral shift. - H5: Player-coach EMs experience higher burnout/role-conflict scores than pure-people-manager EMs, since the two modes compete for the same hours. ## 📊 Methodology - To test H1: survey EMs on both self-reported AI tool usage frequency and hands-on coding hours; regress coding-hours against tool-usage frequency, controlling for team size and org AI-adoption maturity. - To test H2: pair manager self-report of coding involvement with anonymous direct-report ratings of "technical credibility" and "people-leadership effectiveness"; look for a curve (does credibility plateau or invert past a coding-time threshold?). - To test H3: classify manager commits by criticality (critical-path vs. non-critical-path) via git blame + roadmap tagging, then correlate with team cycle-time metrics. - To test H4: compare LeadDev's 2025 vs. 2026 survey respondent demographics (seniority, company size, tech stack) for compositional shifts before trusting the raw percentage change. - To test H5: longitudinal burnout survey (e.g., Maslach Burnout Inventory) segmented by self-reported coding-hours-per-week among EMs. ### ❓ Questions - What counts as "hands-on technical work" in the Engineering Leadership Report 2026 — commits, code review, architecture docs, pairing? The article never defines it. - Is the EM coding increase concentrated in AI-native startups, or is it broad-based across enterprise and legacy orgs too? - Does AI-assisted EM code get the same review scrutiny as IC code, or does manager authority create a review-rigor gap? - How do individual contributors feel about their manager writing production code again — does it read as support or as encroachment? - What happens to this trend if AI coding tools plateau or regress in reliability — does hands-on EM coding recede just as quickly as it rose? ### 🔮 Future Research - Longitudinal tracking of the 20%→35% EM figure across the 2027, 2028 reports to see if it's a spike or a sustained baseline shift. - Comparative research on IC sentiment toward "coding managers" pre- and post-AI-assistant adoption. - Research on whether player-coach EMs measurably improve or degrade team velocity and psychological safety. ### 💡 Implications - Practice: engineering-management career ladders and job descriptions may need to formally re-incorporate a technical-contribution expectation that had been designed out over the past decade. - Policy: performance-review rubrics for EMs may need a codified guardrail (e.g., a coding-time cap, or Williams' "non-critical path only" rule) to prevent drift toward IC work at the expense of people leadership. - Security: if managers are shipping AI-assisted code again, review and access-control policies need to confirm manager commits still go through the same review gates as anyone else's. - Education: EM training/mentorship programs should address "how to stay technical without becoming another IC" as an explicit skill, not an assumed byproduct of coding more. - Funding models: n/a — no funding-model claims in source. ### 🧠 Learning Styles Assessment - Reading level estimate: Flesch-Kincaid approx. grade 10-11 (short paragraphs, some domain jargon like "player-coach," "critical path," moderate sentence length). #### 👀 Visual learners - Present: none — no charts, diagrams, or screenshots accompany the survey statistics. - Improve: add a simple bar chart of the four leadership-tier percentages (tech leads 41%, managers of engineers 31%, managers of managers 30%, CTOs 44%) and a year-over-year line for the EM 20%→35% figure. #### 🔊 Aural learners - Present: none — text-only article. - Improve: a 2-3 minute audio summary or podcast companion segment would suit LeadDev's newsletter/podcast audience. #### 🗣️ Verbal learners - Present: the "player-coach" term is defined via its origin (Orosz's 2021/2024 pieces) and reinforced with quotes from Bostian and Williams. - Improve: a short glossary callout distinguishing "player-coach" from "IC-manager" or "working manager" would help readers new to the term. #### 🧩 Kinesthetic learners - Present: none — no exercises, checklists, or self-assessment prompts. - Improve: add a short self-check ("How much of your week is critical-path code vs. unblocking work?") readers could apply immediately. #### 🧠 Logical learners - Present: the survey statistics function as a structured evidence table even though not visually formatted as one. - Improve: render the leadership-tier percentages as an actual table; add a simple decision tree for "should I code on this task" based on Williams' critical-path framing. #### 🧑‍🤝‍🧑 Social learners - Present: quotes from two named practitioners (Bostian, Williams) ground the trend in individual perspective. - Improve: a discussion prompt or comment thread ("How has your manager's coding involvement changed?") would extend the social dimension. #### 🧘‍♀️ Solitary learners - Present: the article reads cleanly as a standalone briefing piece for self-paced consumption. - Improve: a short reflection question at the end (e.g., "Where's the line for you?") would support self-paced processing. #### 🌿 Naturalistic learners - Present: none — no ecosystem/sustainability framing in source. - Improve: n/a — not a natural fit for this topic. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: standard `<p>`, `<ul>/<li>`, and `<figure>/<figcaption>` structure; images carry descriptive `alt` text (e.g., "AI coding mandates are pushing developers to the brink," "LDX3 New York is live"). - Improve: the second figure's alt text ("LDX3 New York is live") describes a promotional banner but is redundant with the adjacent `<figcaption>` — consider `alt=""` for purely decorative promo images to reduce screen-reader noise, or differentiate alt/caption content. #### Keyboard navigation - Present: standard inline `<a>` links throughout body text are natively keyboard-focusable. - Improve: cannot assess focus order or skip links from html_content alone (no page chrome/nav captured); would need live-page testing. #### Contrast and readability - Present: cannot assess actual rendered contrast from html_content alone (no CSS captured). - Improve: verify body text meets 4.5:1 against LeadDev's site background on the live page. #### Text resizing and reflow - Present: cannot assess from html_content alone. - Improve: verify responsive reflow at 200% zoom on the live article page, particularly the `<figure>` image `sizes`/`srcset` scaling. #### Media and captions - Present: both images have `alt` and `<figcaption>` text; no video/audio content in this article. - Improve: n/a beyond the alt-text redundancy noted above. #### Forms and interactions - Present: a single inline link to "register" a free account; no interactive form fields captured in html_content. - Improve: cannot assess the registration form itself from this content snapshot. #### Standards reference - Gaps mapped to WCAG 2.2 AA: 1.1.1 Non-text Content (alt-text redundancy is a minor quality issue, not a failure); 1.4.3 Contrast (unverifiable from this snapshot — flag for live-page check); 1.4.10 Reflow (unverifiable from this snapshot). ### 🌍 DEIB Assessment #### Cultural breadth - Present: examples are US/Silicon Valley-centric (Meta, Google, Spotify, Bloomberg) with no non-US perspectives represented. - Improve: include EM perspectives from outside major US tech hubs to test whether the trend holds globally or is a US big-tech phenomenon. #### Inclusive language - Present: gender-neutral role terms throughout ("engineering managers," "leaders," "tech leads"); named sources include one woman (Bostian) and two men (Williams, plus anecdotal Zuckerberg/Brin). - Improve: broaden named-source diversity beyond two practitioners; the anecdotal frame (Zuckerberg, Brin) skews toward well-known male tech founders, which could be balanced with additional named examples. #### Neurodiversity support - Present: short paragraphs, a bolded "Key takeaways" bullet list up front, consistent heading-free but logically ordered structure. - Improve: add subheadings between major sections (currently a single unbroken scroll of paragraphs) to support chunked reading. #### Representation - Present: one woman practitioner quoted (Bostian) alongside two male examples/quotes; no explicit discussion of how this trend affects managers from underrepresented groups. - Improve: examine whether the "return to coding" trend advantages managers who already have strong technical backgrounds (which correlates with existing pipeline demographics), potentially disadvantaging managers who moved into leadership via non-traditional paths. #### Psychological safety - Present: the article implicitly validates a boundary ("coding again doesn't mean becoming another engineer") that protects managers from role-creep pressure. - Improve: explicitly address the risk that "manager should code more" becomes an unstated performance expectation, creating pressure on EMs who legitimately can't or shouldn't reallocate time to coding. ### ✅ Logical Validity #### Strong reasoning - Inductive: the piece grounds its central claim in a broad, multi-tier statistical pattern (20%→35% EM figure, plus consistent increases across tech leads/managers/CTOs) rather than resting solely on the celebrity anecdotes — this is the strongest evidentiary move in the piece, since convergent data across leadership tiers makes a single-cause explanation (AI lowering the coding barrier) more plausible than if only one tier had shifted. - Analogical: framing the trend through Orosz's pre-existing "player-coach" concept (2024) gives readers a testable prior prediction that the 2026 data can be checked against, which is a legitimate and falsifiable use of analogy — the prediction either matches the data or it doesn't, and the article shows it matching. #### Fallacies - Hasty generalization / anecdotal fallacy: opening with Zuckerberg and Brin (two extreme, resource-unconstrained outliers) to illustrate a trend meant to describe typical engineering managers. Location: paragraphs 2-3 ("Mark Zuckerberg started coding again..."; "Sergey Brin... came out of retirement"). Why weak: founder-CEOs have discretionary schedules, near-infinite authority, and symbolic motives unlike a line-level EM juggling sprint planning and 1:1s — their behavior doesn't validate that typical EMs face the same tradeoffs or make the same choice for the same reasons. Fix: either drop the anecdotes or explicitly flag them as illustrative color, not representative evidence, and lead with the survey data instead. - Unstated methodology / appeal to authority via statistics: the article cites the Engineering Leadership Report 2026 percentages as settled fact without describing sample size, respondent selection, or how "hands-on technical work" was operationalized. Location: "the Engineering Leadership Report 2026 found that 37% of engineering leaders are doing more hands-on technical work than in 2025." Why weak: readers can't evaluate whether the 15-point EM jump reflects real behavior change or a shift in who took the survey. Fix: link to or summarize the report's methodology section, or caveat the stat with a confidence qualifier. #### Tone of voice - Measured and journalistic, with a mild "trend piece" enthusiasm in the framing ("shipping diffs again," "clear shift occurring") balanced by cautionary quotes from Bostian and Williams that pull the piece back from hype. Example: "AI may make it easier for engineering managers to stay technically engaged, but leadership experts argue that the goal is not to become another engineer on the team." ### 🛡️ DARVO Analysis - Not applicable to this source — this is a management-trends briefing piece with no accusation, denial, or victim/offender dynamic present. No party is being accused of wrongdoing; the article synthesizes survey data and practitioner commentary without a defensive or reputation-management posture. ## 🎯 Conclusion - Bottom line: AI coding tools have made it cheap enough for engineering managers to write code again that a meaningful share of them are doing so — LeadDev's data shows this at every leadership tier, not just among famous founders. The practitioners quoted are unanimous that this shouldn't mean reverting to an IC role; the value-add is staying credible and unblocking non-critical-path work, not maximizing personal output. - Practical next steps for readers: if you manage engineers, use Williams' filter (code only on non-critical-path, unblocking work) as a concrete boundary; if you're an EM's manager or HR partner, consider whether performance expectations implicitly reward coding time over people-leadership time, and correct for that if so. ## 🔄 Refactor Appendix — Engineering managers are back in the codebase > Density: 2–5 Literature atoms (H3), 0–3 Permanent candidates (H4). > Defaults: 3 Literature, 1 Permanent. Resonance filter: if you can't > articulate in one line why a claim matters, drop it. > > Konik claim-header rules: present tense, declarative, ≤10 words when > possible, searchable, unique, mirrors annotation focus if present. > > Atomicity: one declarative sentence per atom. "and"/"also" → split. > > Tag pool: #bmf · #addendum · #xref · #articleseed · #storystem · #share · #aphorisms ### 📚 Literature Atoms (H3) #### [H1] EM hands-on coding jumps from 20% to 35% in a year > [!quote] ID:rw_01kzp1fsk531rcm6jkm7p95sr3-h1 > Among engineering managers specifically, the share rose from 20% in 2025 to 35% in 2026. **Context & use**: - Mid-article, the central statistic supporting the whole piece's thesis. - The single most citable number for the "player-coach becomes reality" claim; anchor for H2 and H3. **Tags**: #xref **Highlight**: [view highlight](readwise://open?url=https%3A%2F%2Fleaddev.com%2Fmanagement%2Fengineering-managers-are-back-in-the-codebase) <!-- atomicity: 1 idea ✓ --> #### [H2] Zuckerberg codes 10 hours weekly after 20-year gap > [!quote] ID:rw_01kzp1fsk531rcm6jkm7p95sr3-h2 > Mark Zuckerberg started coding again after a 20-year break. **Context & use**: - Opening anecdote, paragraph 2. - Illustrative but not representative — flagged in Logical Validity as a hasty-generalization risk; useful as a vivid hook, not as evidence. **Tags**: #xref **Highlight**: [view highlight](readwise://open?url=https%3A%2F%2Fleaddev.com%2Fmanagement%2Fengineering-managers-are-back-in-the-codebase) <!-- atomicity: 1 idea ✓ --> #### [H3] AI lowers barrier from idea to working software > [!quote] ID:rw_01kzp1fsk531rcm6jkm7p95sr3-h3 > AI has drastically lowered the barrier to entry for turning an idea into working software **Context & use**: - Emma Bostian (Spotify EM) quote, mid-article — the article's stated causal mechanism. - Direct claim about the underlying driver of the whole trend; central for H1 hypothesis testing. **Tags**: #xref **Highlight**: [view highlight](readwise://open?url=https%3A%2F%2Fleaddev.com%2Fmanagement%2Fengineering-managers-are-back-in-the-codebase) <!-- atomicity: 1 idea ✓ --> #### [H4] EM's core job is vision, not code output > [!quote] ID:rw_01kzp1fsk531rcm6jkm7p95sr3-h4 > the primary role of the engineering manager is to set the vision, work with stakeholders to define the requirements, be responsible for gaining consensus around nuanced decisions **Context & use**: - Paul Williams (Bloomberg) quote, near the end — the article's counterweight/guardrail claim. - Best operational filter offered in the piece; used in Action Items and Implications above. **Tags**: #xref **Highlight**: [view highlight](readwise://open?url=https%3A%2F%2Fleaddev.com%2Fmanagement%2Fengineering-managers-are-back-in-the-codebase) <!-- atomicity: 1 idea ✓ --> ### 🧠 Permanent Candidates (H4) #### [P1] Code only on non-critical-path work as an EM **Claim** (one sentence, Courtney's voice): When I take on hands-on coding as a manager, I should restrict it to non-critical-path work that unblocks my team, not code that competes with my people-leadership hours. **Evidence pointer**: [[#H4]] **Scope & conditions**: Holds when the team already has clear technical ownership and the manager's coding is additive/optional; breaks down in very small teams where the manager is also the only available senior IC on critical-path work. **Links** (≥1 with annotation): - [[Player-coach model]] — because extends - [[Technical credibility vs. technical output]] — because contrasts on what "staying technical" is for <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] Check whether LeadDev's Engineering Leadership Report 2026 publishes its survey methodology (sample size, respondent selection) — needed to properly weigh the 20%→35% stat. #xref - [F2] Possible Field Notes tie-in: pair this with any DevRel/OSPO piece on "technical credibility" for a cross-link on manager role-drift under AI tooling. #articleseed ### → Things 3 (max 2 actions) - [ ] Check LeadDev Engineering Leadership Report 2026 methodology before citing the 20%→35% stat elsewhere — engineering-management #things <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/Engineering Managers Are Back in the Codebase.md|Engineering Managers Are Back in the Codebase by leaddev.com]] ## Highlights - Mark Zuckerberg started coding again after a 20-year break. According to [multiple reports](https://www.businessinsider.com/mark-zuckerberg-moved-desk-coding-again-sits-by-alexandr-wang-2026-4), he moved his desk to Meta’s AI lab and spends up to 10 hours a week writing code alongside the Meta Superintelligence Labs team. The man who built Facebook in a dorm room and then spent two decades managing tens of thousands of people is shipping diffs again. ([View Highlight](https://read.readwise.io/read/01kzp1t6y3882zfkbyzt9xjqqb)) - Note: Opening anecdote, illustrative but not representative (hasty-generalization risk flagged in Logical Validity). - Tags: atom/literature/h2 - Among engineering managers specifically, the share rose from 20% in 2025 to 35% in 2026. ([View Highlight](https://read.readwise.io/read/01kzp1t4brmm10g6rcda9xgr5e)) - Note: Central statistic anchoring the piece's thesis: EM hands-on coding jumps from 20% to 35% in a year. - Tags: atom/literature/h1 - [AI](https://leaddev.com/ai/best-ai-coding-assistants) has drastically lowered the barrier to entry for turning an idea into working software, Emma Bostian, engineering manager at Spotify, tells LeadDev. Engineering leaders can now use natural language to gather context, generate code, build proof of concepts, and validate or challenge assumptions in a fraction of the time it once took, she adds. ([View Highlight](https://read.readwise.io/read/01kzp1tabc5m6pt5kprv799ytk)) - Note: Bostian's stated causal mechanism for the whole trend: AI lowers the barrier from idea to working software. - Tags: atom/literature/h3 - “I still think the primary role of the engineering manager is to set the vision, work with stakeholders to define the requirements, be responsible for gaining consensus around nuanced decisions, and provide an environment where the team can work as efficiently as possible and grow as developers.” ([View Highlight](https://read.readwise.io/read/01kzp1tegg2xmhjb2qg85es850)) - Note: Williams' guardrail claim: the EM's core job is vision and stakeholder alignment, not code output. - Tags: atom/literature/h4 ## Links - [[Managers Should Code Off the Critical Path]] — distilled claim: technical participation helps only while a manager's code doesn't gate delivery. - [[The Bottleneck Moved From Code Generation to Review and Judgment]] — context: AI can make manager output cheaper while increasing the team's review burden.