Should managers still code?

Scope of the Question

• Many commenters stress context: startup vs BigCo, “player/coach” EM vs pure people manager, inside vs outside hire, and company culture around management all change the answer.
• Several argue the real question is not “can they code?” but “should they be writing production code on the critical path?”

Arguments for Managers Coding

• Keeps them technically current: better estimates, more realistic timelines, and fewer outdated “best practices” pushed from years-old experience.
• Improves empathy and judgment: feeling real SDLC pain (env setup, deployment friction, tech debt) helps prioritize tooling, refactors, and process fixes.
• Aids evaluation: seeing code, blame, and design decisions first-hand can reveal who is actually delivering versus just talking.
• Reduces disconnect: managers who can run the project, tweak code, or build small tools are seen as peers “in the trenches,” which can boost trust and morale.
• Career safety: staying hands-on preserves employability when management roles are cut.

Arguments Against Managers Coding

• Time and context switching: serious management (hiring, performance, politics, alignment, stakeholder wrangling) is a full-time job; adding real coding leads to missed responsibilities or broken commitments.
• Power imbalance: manager-written code can become “untouchable,” and ICs may feel unsafe pushing back on bad designs or half-baked POCs.
• Risk of bottlenecks: when managers own critical-path work, meetings and interruptions delay shipping.
• Temptation and avoidance: coding is a comfortable escape from the uncomfortable work of feedback, conflict, and managing up.
• Micromanagement: partial technical knowledge often manifests as annoying PR nitpicks, late-stage architecture objections, or overriding IC decisions.

Common Middle-Ground Patterns

• Strong separation from critical path: managers may write small, non-essential code—bug fixes, tooling, cleanup, experiments—while never owning key features.
• “In the code” without being another IC: reading code, doing selective reviews, running builds/tests, building prototypes, but not head-down feature work.
• Use tech leads or senior ICs as primary technical authorities and reviewers, with EMs focusing on people, strategy, and cross-team coordination.

Divergent Philosophies

• Some insist EMs must actively code to credibly lead engineers.
• Others insist managers should never write or review product code and should specialize fully in management.
• Many conclude: it depends heavily on org size, maturity, role design, and the individual manager’s skills and goals.