# How to stay technical as an engineering manager > [!question] Lingering Questions > - The "no longer optional" framing leans on James Stanier's line rather than data — under which org structures does it actually hold weakest (e.g., orgs that formally split EM and staff/principal-engineer tracks)? > - Which of the four strategies (prompting, pairing, domain depth, architecture review) has the highest proficiency-per-hour return? The article doesn't rank them. > - How often can an EM realistically pair before it measurably taxes the team's throughput? > [!tip] Article Ideas > - Package the five-part prompt scaffold (persona, context, problem, criteria, output format) as a reusable internal template for technical-strategy drafting. > - Turn the two-pass RFC reading method plus the primary/secondary/tertiary consequence lens into a shareable review checklist. > [!link] Cross Reference > - [[3. Resources/Permanent Notes/Managers Should Code Off the Critical Path]] — adjacent EM-technical-involvement territory; check for overlap with the pairing strategy before treating this source's pairing material as fully novel. > - [[3. Resources/Permanent Notes/The Workhorse Trap Prevents Leadership Emergence]] — a caution worth holding against this article's "stay hands-on" advice: proficiency maintenance and over-functioning are not the same thing. > - [[3. Resources/MOCs/Product & Startup Instincts MOC]] — technical-leadership practice. > [!quote] Vocabulary > - **Technical proficiency (EM sense)** — per Bostian: understanding codebase architecture, identifying bottlenecks, and knowing the team's tools well enough to make sound judgment calls and set strategy — explicitly *not* the same as writing production code. ## Metadata - Source: [[3. Resources/Readwise/Full Document Contents/Articles/How to stay technical as an engineering manager]] - Author: Emma Bostian, Engineering Manager at Spotify (published on LeadDev) - URL: https://leaddev.com/career-development/how-to-stay-technical-as-an-engineering-manager ## Author's thesis Staying technical has shifted from "nice to have" to a requirement for engineering managers. Bostian lays out four concrete, escalating maintenance strategies — AI-assisted learning (structured prompting), bursty hands-on learning (sparing, respectful pairing), deliberate compounding learning (picking one domain at a time), and high-leverage application (active architecture and design review participation) — arguing that small, consistent investment compounds and the goal is understanding what the team builds and why, not out-coding them. ## Key arguments 1. **Technical proficiency for an EM is judgment, not code output**: understanding architecture, bottlenecks, and tooling well enough to make sound calls and set strategy. 2. **Four concrete strategies maintain that proficiency without becoming the team's bottleneck**: structured AI prompting, time-boxed and honest pairing, one-domain-at-a-time depth building, and active architecture-review participation. 3. **Architecture and design reviews carry the highest stakes** because their decisions shape scalability, maintainability, and velocity for years — and a two-pass reading method plus a primary/secondary/tertiary consequence lens surfaces risks a single read-through misses. ## Claim atoms ### 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." Where/why: key takeaways box and conclusion — reframes "technical EM" away from line-count toward judgment, setting a reachable, durable target. ### 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." Where/why: Strategy 1, the microservices-vs-monolith worked example — a reusable five-part prompt scaffold applicable to any EM technical-strategy task. ### 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." Where/why: Strategy 4 — separates orientation from critique so the second pass catches gaps the first would miss. ### 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." Where/why: Strategy 4, the REST→Kafka migration example — a tiered lens that surfaces silent failures and onboarding costs design docs tend to omit. ## Permanent candidates - **Compounding, deliberate technical investment as the mechanism of EM proficiency** (atom 1) is a general claim adjacent to, but distinct from, [[3. Resources/Permanent Notes/Managers Should Code Off the Critical Path]] (that note is scoped narrowly to hands-on coding staying off the critical path; this article's claim is broader and less novel) — not promoted as a separate note. - **The primary/secondary/tertiary consequence lens for design review** (atom 4) — a distinct, concrete, reusable review technique not covered by the existing manager-coding notes. Promoted below. - The prompt scaffold (atom 2) is a genuinely useful template but is closer to a practical tool than a falsifiable claim — not promoted as a Permanent note on its own. ## Processing checklist - [x] Checked [[3. Resources/Permanent Notes/Managers Should Code Off the Critical Path]] for overlap — narrower scope (hands-on coding specifically), not a duplicate - [x] Connect into the relevant MOC — [[3. Resources/MOCs/Product & Startup Instincts MOC]] ## Links - [[3. Resources/MOCs/Product & Startup Instincts MOC]] — technical-leadership practice and manager skill maintenance - [[3. Resources/Permanent Notes/Managers Should Code Off the Critical Path]] — adjacent claim to verify against for overlap - [[3. Resources/MOCs/AI & the Future of Knowledge Work MOC]] — applies-in: Joins the thread on how engineering careers change as AI reshapes technical work.