How to Stay Technical as an 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/2026/06/Staying-technical.jpg) 🔗 **Source:** [How to Stay Technical as an Engineering Manager](https://leaddev.com/career-development/how-to-stay-technical-as-an-engineering-manager) > [!note]+ Document Notes > tags: [engineering-management, technical-leadership, prompt-engineering, pair-programming, architecture-review, career-development] > author: Emma Bostian > source: LeadDev > reference: https://leaddev.com/career-development/how-to-stay-technical-as-an-engineering-manager > date created: 2026-06-22 00:00 > > # 🏷️ Title: How to stay technical as an engineering manager > <!-- 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 - [The end of the non-technical engineering manager — James Stanier](https://leaddev.com/career-development/the-end-of-the-non-technical-engineering-manager) - [The engineering manager role is splitting in two](https://leaddev.com/career-development/the-engineering-manager-role-is-splitting-in-two) - [Google's Prompting Essentials Specialization (Coursera)](https://www.coursera.org/specializations/prompting-essentials-google) ## 📝 Summary - What happened: Emma Bostian, an engineering manager at Spotify, lays out four concrete strategies engineering managers can use to keep their technical proficiency current: master prompt engineering, pair with engineers, build deep domain knowledge, and engage in architecture/design reviews. - Why it matters: She argues technical proficiency for EMs has shifted from "nice to have" to a requirement, echoing James Stanier's line that people management alone is "no longer sufficient." - Key stakeholders: Engineering managers, the engineers who report to them, and leadership that relies on EMs to represent technical work accurately. - Risks and tradeoffs: Pairing and learning consume engineers' focus time; over-pairing with one engineer drains their productivity. The goal is understanding, not out-coding the team. - Bottom line: Small, consistent investment compounds. You don't need to be the best coder — you need to understand what your team builds, why, and what's at stake. ## 📖 Main Content - The article first defines technical proficiency for an EM as understanding codebase architecture, identifying bottlenecks, and knowing the team's tools well enough to make sound judgment calls and set strategy — not necessarily writing production code. - It then makes the case for why this matters via four impacts: credibility with the team, protecting engineers' focus time, shortening the feedback loop with stakeholders, and improving hiring. - The core of the piece is four maintenance strategies, presented as an escalating sequence: AI-assisted learning (prompt engineering), bursty hands-on learning (pairing), deliberate compounding learning (domain depth), and high-leverage application (architecture reviews). - Prompt engineering is framed as a force multiplier: a worked example contrasts a generic prompt ("what are the tradeoffs between microservices and a monolith?") with a context-rich one specifying persona, context, problem, criteria, and output format. - Pairing is bounded by an ethic of not over-taxing engineers — pick non-critical, time-boxed tasks, be honest about your learning goal, ask "why," and document follow-ups. - Domain knowledge is illustrated with a three-month observability arc: learn foundations, gain hands-on experience, then apply it in RFCs and design discussions. - Architecture reviews are positioned as where the most consequential decisions live; she recommends a two-pass reading method and thinking through primary, secondary, and tertiary consequences (illustrated with a REST-to-Kafka migration). - Uncertainty/contested claim: the strong "no longer optional" framing is asserted rather than empirically demonstrated; reasonable EMs in some org structures may dispute the degree. ### 🗒️ Notes - **Definition** — Technical proficiency = understanding architecture, spotting bottlenecks, knowing the team's tools enough to make judgment calls and set strategy. Not necessarily coding. - **Four reasons it matters** — (1) credibility representing the team to leadership; (2) protects engineers' focus time by reducing pull-ins; (3) reduces the feedback loop with stakeholders; (4) promotes effective hiring because you understand the role. - **Strategy 1 — Prompt engineering** — Bad prompt is generic and contextless. Good prompt adopts a persona, provides context (team size, stack, scale), describes the problem, details evaluation criteria, and specifies output format. EM uses: triage/fix bugs, performance-eval frameworks, technical strategies, codebase overviews, tooling diagrams. - **Strategy 2 — Pair with engineers** — Use sparingly; don't repeatedly tax one engineer. Best tasks: useful but non-critical, no timeline urgency. Tips: be honest about the goal, pick time/requirements-bound tasks, decide who drives, ask "why," document follow-ups. Good: reviewing a PR, low-priority bug. Bad: prod incidents (time sensitive), new-tool investigation (open-ended), deep optimization (too technical). - **Strategy 3 — Domain knowledge** — Pick one relevant domain, get comfortable, pick another; knowledge compounds. Choose by: what the team works on now, where you feel least confident, where decisions get made. Build it by balancing concepts with practice, finding a mentor, reading deeper docs (blogs → RFCs → specs), and timeboxing regularly. Observability example: Month 1 foundations (OpenTelemetry/Honeycomb docs, tracing talks), Month 2 hands-on (pair on tracing, personal project), Month 3 apply (contribute in discussions, spot observability gaps in RFCs). - **Strategy 4 — Architecture and design reviews** — Where the most consequential decisions are made (scalability, maintainability, hiring, cost, velocity for years). Read the doc twice: first pass no notes, think business/team implications; second pass highlight, note questions/gaps, think codebase implications. In live reviews ask clarifying ("help me understand why we chose Y") not leading ("shouldn't we just use X") questions. Consider secondary/tertiary consequences. REST→Kafka example: primary (less coupling, better spike handling, fault tolerance), secondary (silent/delayed failures, consumer lag, out-of-order events, harder cross-service debugging), tertiary (implicit data flow complicates onboarding). - **Closing** — Proficiency isn't acquired once; needs ongoing investment. Small consistent actions compound. Engineers need you to understand what they build, why it matters, and what's at stake — not to be the best coder. ## 📚 References - [How to stay technical as an engineering manager — Emma Bostian, LeadDev](https://leaddev.com/career-development/how-to-stay-technical-as-an-engineering-manager) - [The end of the non-technical engineering manager — James Stanier](https://leaddev.com/career-development/the-end-of-the-non-technical-engineering-manager) - [The engineering manager role is splitting in two](https://leaddev.com/career-development/the-engineering-manager-role-is-splitting-in-two) - [Prompt engineering (IBM)](https://www.ibm.com/think/topics/prompt-engineering) - [Google's Prompting Essentials Specialization (Coursera)](https://www.coursera.org/specializations/prompting-essentials-google) - [How to master the perfect pull request — LeadDev](https://leaddev.com/technical-direction/how-to-master-the-perfect-pull-request) ## 🗣️ Paraphrase - Engineering managers drift from the daily technical work, and that gap now carries a real cost; proficiency means understanding architecture, bottlenecks, and tooling well enough to judge and strategize, not necessarily to ship code. - Staying technical pays off in credibility, protected focus time, faster feedback loops, and better hiring — and you maintain it through four deliberate moves: strong prompting, sparing and respectful pairing, compounding domain depth, and active participation in architecture reviews where the stakes are highest. ## 📰 Newsletter - Engineering managers, this one's for you: Emma Bostian (Spotify EM) makes the case that staying technical is no longer optional — and gives you four moves to do it without becoming the team's bottleneck. The standout for the WordPress crowd: her prompt-engineering worked example is a clean template you can reuse for codebase overviews and technical strategy docs. Pair it with her "read the RFC twice" review ritual and the primary/secondary/tertiary consequence framing, and you've got a practical kit for showing up sharp in design reviews. Worth a read: [How to stay technical as an engineering manager](https://leaddev.com/career-development/how-to-stay-technical-as-an-engineering-manager). ## ✅ Action Items #### DevRel - Developer advocacy: turn the prompt-engineering example into a reusable internal prompt template for technical-strategy drafting. - Education: build a workshop around the three-month domain-learning arc (foundations → hands-on → apply). - Developer experience: document a "pairing for managers" guide with the time-box and honesty norms. - Developer marketing: package the two-pass RFC reading method as a short, shareable checklist. - Community management: survey EMs on which strategy they actually use and what blocks them. - Internal/external/cross-project: align EM-engineer pairing expectations so focus-time tradeoffs are explicit. #### OSPO - Policy & Governance: codify architecture-review participation expectations for managers. - License Compliance: not applicable to this source — the article does not address licensing. - Security Management: fold secondary/tertiary consequence analysis (e.g., silent Kafka failures) into review templates. - Software Inventory: not applicable to this source — no SBOM or inventory content. - Developer Support: offer manager office hours focused on domain-learning roadmaps. - Community Engagement: not applicable to this source — no upstream funding content. - Strategic Alignment: tie technical-proficiency goals to EM development OKRs. #### Community - Maintainers: adopt the "ask why, document follow-ups" pairing pattern in mentoring sessions. - Contributors: use low-priority bugs as safe pairing tasks for skill transfer. - Sponsors: not applicable to this source — no sponsorship content. - Ecosystem: not applicable to this source — no cross-project incident-drill content. #### WordPress - Core: not applicable to this source — no WordPress core content. - Core Performance: borrow the observability-domain example for perf-monitoring upskilling. - Core AI: pilot the prompt-engineering framework for AI-assisted triage with guardrails. - **Core Program Team:** use the two-pass review ritual in cross-team RFC reviews. - Mobile: not applicable to this source — no mobile-specific content. - Playground: build a reproducible prompt-engineering lab for managers. - Community: run an EM meetup session on staying technical. - Training: turn the four strategies into a Learn WordPress lesson path. - Marketing: not applicable to this source — no marketing-narrative content. - Support: not applicable to this source — no support-ops content. - Design: not applicable to this source — no design-system content. - Documentation: document the clarifying-vs-leading-questions distinction for review etiquette. - Photos / TV / Polyglots / Meta / CLI / Hosting / Tide / Openverse / Themes / Plugins: not applicable to this source — no content touching these teams. - Accessibility: not applicable to this source — the article does not cover accessibility. #### The WPCC - Programs: not applicable to this source — no fellowship/grant content. - Projects: not applicable to this source. - Funding experiments: not applicable to this source. ### FAIR - Technical independence: not applicable to this source — no metadata/provenance content. - Policies and covenants: not applicable to this source. - Productized governance artifacts: not applicable to this source. ## 🧪 Hypotheses - EMs who timebox regular domain learning report higher confidence in architecture reviews within one quarter than those who don't. - Context-rich prompts (persona + context + criteria + format) produce higher-rated technical outputs than generic prompts. - Manager-engineer pairing capped at short, non-critical tasks improves manager proficiency without measurable loss in engineer throughput. - Two-pass RFC reading surfaces more secondary/tertiary risks than single-pass reading. - Teams whose EM is technically proficient escalate fewer technical decisions to senior engineers. ### 📊 Methodology - Run a controlled prompt study: same task, generic vs. structured prompt, blind-rated by senior engineers. - Survey + diff EM self-rated confidence before/after a quarter of timeboxed domain learning. - Instrument engineer focus-time (calendar/PR throughput) before and after a manager-pairing program. - A/B the two-pass vs. single-pass reading protocol on matched RFCs, count risks surfaced. - Mine decision logs to compare escalation rates across teams by EM proficiency. ### ❓ Questions - Which of the four strategies has the highest proficiency-per-hour return? - How often should an EM realistically pair before it taxes the team? - Does heavy reliance on AI prompting erode or build durable understanding over time? - What's the right cadence for rotating to a new domain? ### 🔮 Future Research - Longitudinal study of EM proficiency trajectories under each strategy. - Effect of AI-assisted learning on retention of technical knowledge vs. hands-on pairing. - Org-structure moderators: where the "no longer optional" claim holds strongest vs. weakest. ### 💡 Implications - Practice: EMs get a concrete, low-friction kit instead of vague "stay close to the code" advice. - Policy: orgs may formalize technical-proficiency expectations and review participation. - Security: secondary/tertiary consequence thinking improves risk surfacing in design reviews. - Education: clear curriculum hooks (prompting, domain arcs, review rituals). - Funding models: not applicable to this source — the article does not address funding. ### 🧠 Learning Styles Assessment - Reading level estimate: roughly grade 11–13 (Flesch-Kincaid Grade Level estimate ~11–13) given moderate sentence length and domain vocabulary; LeadDev lists ~9 minutes estimated reading time. #### 👀 Visual learners - Present: a hero image; no diagrams or charts in the body. - Improve: add a decision-tree for choosing a domain, a before/after prompt diagram, and a primary/secondary/tertiary consequence map. #### 🔊 Aural learners - Present: none — no audio version. - Improve: add a 2–5 minute audio summary or TTS narration. #### 🗣️ Verbal learners - Present: clear definitions, worked examples, and analogies (REST→Kafka, observability arc). - Improve: add a short glossary (RFC, OpenTelemetry, event-driven). #### 🧩 Kinesthetic learners - Present: actionable tips and a month-by-month plan. - Improve: a downloadable pairing checklist and a starter prompt template. #### 🧠 Logical learners - Present: structured lists, numbered prompt criteria, tiered consequences. - Improve: a table mapping each strategy to its impact and cost. #### 🧑‍🤝‍🧑 Social learners - Present: pairing and mentorship guidance; share buttons. - Improve: discussion prompts or a peer-review rubric for reviews. #### 🧘‍♀️ Solitary learners - Present: self-paced domain-learning arc. - Improve: reflection prompts ("where do you feel least confident?") as a worksheet. #### 🌿 Naturalistic learners - Present: none. - Improve: frame domain knowledge as an ecosystem that compounds; lifecycle analogies. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: clear heading hierarchy and an author landmark. - Improve: ensure the hero image has descriptive alt text (current alt appears generic, "Staying technical"). #### Keyboard navigation - Present: standard article links, likely focusable. - Improve: confirm visible focus states and skip-to-content (a skip link is present in markup). #### Contrast and readability - Present: standard LeadDev typography. - Improve: verify 4.5:1 contrast on link colors and metadata text. #### Text resizing and reflow - Present: responsive viewport meta tag, though it caps maximum-scale at 5. - Improve: confirm no clipping at 200% zoom; avoid maximum-scale restrictions. #### Media and captions - Present: no video/audio, so captions not required. - Improve: if an audio summary is added, ship a transcript. #### Forms and interactions - Present: a newsletter signup with an email field. - Improve: confirm the email input has a programmatic label and inline validation. #### Standards reference - Map gaps to WCAG 2.2 AA: 1.1.1 Non-text Content (alt text), 1.4.3 Contrast, 1.4.4 Resize Text, 1.4.10 Reflow, 3.3.2 Labels. ### 🌍 DEIB Assessment #### Cultural breadth - Present: vendor-neutral examples (Rails, Kafka, OpenTelemetry, Honeycomb) that travel across regions. - Improve: add non-US/global team-context case studies. #### Inclusive language - Present: gender-neutral, jargon mostly defined or linked. - Improve: add a plain-language summary for readers newer to the role. #### Neurodiversity support - Present: chunked sections, consistent structure, clear headings. - Improve: add icon+text cues and a TL;DR per strategy. #### Representation - Present: cites two named authors (Bostian, Stanier) and links varied roles. - Improve: broaden quoted voices beyond two contributors. #### Psychological safety - Present: explicitly frames pairing honestly to reduce engineers' fear of evaluation. - Improve: add guidance for managers admitting knowledge gaps without losing credibility. ### ✅ Logical Validity #### Strong reasoning - Inductive: the four strategies generalize from common EM experience; reasonable as practical heuristics. - Causal: the REST→Kafka consequence chain (primary→secondary→tertiary) is a clear, well-structured causal analysis. - Analogical: the observability three-month arc is a strong concrete analogy for "compounding" domain learning. #### Fallacies - Appeal to authority (mild): "no longer optional" leans on Stanier's quote rather than data — fix by citing evidence (e.g., the Engineering Leadership Report) for the necessity claim. - Hasty generalization (mild): "Technical proficiency is no longer a 'nice to have'... It's a requirement" is asserted broadly; fix by scoping to contexts/org types where it holds. #### Tone of voice - Practical, encouraging, peer-to-peer ("you've probably felt it"); reassuring close ("you don't have to do it all at once"). ### 🛡️ DARVO Analysis - Deny: not applicable to this source — no accusation is being denied or minimized. - Attack: not applicable to this source — no accusers or credibility targets present. - Reverse victim/offender: not applicable to this source — no victim/offender dynamic. - Note: this is a how-to career article with no conflict framing, so DARVO patterns do not appear. ## 🎯 Conclusion - Bottom line: Staying technical as an EM is an ongoing, deliberate practice — sharpen prompting, pair sparingly and honestly, build domain depth that compounds, and show up sharp in architecture reviews. The aim is understanding, not out-coding your team. - Next steps for readers: pick one domain to learn this quarter, draft a reusable structured prompt, adopt the two-pass RFC reading method, and schedule one low-stakes pairing session with explicit goals. ## 🔄 Refactor Appendix — How to stay technical as an engineering manager > 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 technical proficiency means understanding, not coding > [!quote] ID:rw_leaddev_01 > "the goal is to understand what your team is building, why decisions were made, and what's at stake – not to out-code your engineers." **Context & use**: - Key takeaways box and conclusion of the article. - Reframes "technical EM" away from line-count toward judgment; lowers the bar to a reachable, durable target. **Tags**: #xref **Highlight**: [view highlight](readwise://) <!-- atomicity: 1 idea ✓ --> #### [H2] Structured prompts beat generic ones for technical judgment > [!quote] ID:rw_leaddev_02 > "Asks AI to adopt a persona... Provides context... Clearly describes the problem... Details the evaluation criteria... Clarifies the desired output format." **Context & use**: - Strategy 1, the microservices-vs-monolith worked example. - A reusable five-part prompt scaffold for any EM technical-strategy task. **Tags**: #xref #articleseed **Highlight**: [view highlight](readwise://) <!-- atomicity: 1 idea ✓ --> #### [H3] Read an RFC twice before reviewing it > [!quote] ID:rw_leaddev_03 > "First read-through: do not highlight or take notes... Second read-through: highlight important information and take notes on questions you may have." **Context & use**: - Strategy 4, architecture and design reviews. - Separates orientation from critique so the second pass catches gaps the first would miss. **Tags**: #xref **Highlight**: [view highlight](readwise://) <!-- atomicity: 1 idea ✓ --> #### [H4] Analyze primary, secondary, and tertiary consequences > [!quote] ID:rw_leaddev_04 > "RFCs often account for primary consequences, however secondary and tertiary consequences may not be as obvious." **Context & use**: - Strategy 4, the REST→Kafka migration example. - A tiered lens that surfaces silent failures and onboarding costs design docs tend to omit. **Tags**: #xref #addendum **Highlight**: [view highlight](readwise://) <!-- atomicity: 1 idea ✓ --> ### 🧠 Permanent Candidates (H4) #### [P1] Managerial technical depth is a compounding investment **Claim** (one sentence, Courtney's voice): A manager's technical credibility is built by small, repeated, deliberate learning that compounds rather than by any single act of mastery. **Evidence pointer**: [[#H1]] **Scope & conditions**: Holds for managers of technical teams who control some of their own time; breaks when the role is purely administrative or the org explicitly separates technical authority from management. **Links**: - [[Engineering management]] — because extends - [[Deliberate practice]] — because applies-in skill maintenance - [[Architecture review]] — because evidence-for <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] Build a one-page structured-prompt template from the five criteria — leaddev.com/career-development/how-to-stay-technical-as-an-engineering-manager #fleeting #inbox - [F2] Compare this with James Stanier's "end of the non-technical EM" piece for a synthesis note — #fleeting #inbox ### → Things 3 (max 2 actions) - [ ] Draft a reusable structured-prompt template for technical-strategy work — #things - [ ] Pick one domain to timebox-learn this quarter using the three-month arc — #things <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/How to Stay Technical as an Engineering Manager.md|How to Stay Technical as an Engineering Manager by leaddev.com]] ## Highlights - - You don’t need to be the best coder in the room: the goal is to **understand what your team is building**, why decisions were made, and what’s at stake – not to out-code your engineers. ([View Highlight](https://read.readwise.io/read/01kvqpq9ejh6z1sygnzfe0gy3k)) - Note: EM proficiency is understanding, not out-coding - Tags: atom/literature/h1 - - **First read-through:** do not highlight or take notes. This pass is simply to put your brain in the right context. During this iteration, think about the implication on your team and the business. ([View Highlight](https://read.readwise.io/read/01kvqpqf2rvp8xkpjgkbmhwswy)) - Note: Two-pass RFC reading: orient then critique - Tags: atom/literature/h3 - Additionally you should consider secondary or tertiary implications of the proposed changes. RFCs often account for primary consequences, however secondary and tertiary consequences may not be as obvious. ([View Highlight](https://read.readwise.io/read/01kvqpqe4pjwybf2sm9j1z94w2)) - Note: Tiered consequence analysis surfaces hidden risks - Tags: atom/literature/h2 ## Links - [[Managers Should Code Off the Critical Path]] — existing Permanent captures the boundary between technical awareness and becoming another delivery dependency. - [[Technical Interviews Should Test Explanation and Tradeoffs Not Recall]] — extends: technical proficiency shows in consequence analysis and design judgment, not syntax recall or coding volume.