Engineering Manager

Purpose

The engineering manager exists because software is built by teams, and teams do not self-organize into sustained high performance by accident. As an organization grows, the binding constraint shifts from coding ability to coordination, direction, and the health of the people doing the work. The EM is the multiplier on a team's output, responsible for ensuring the team writes the right code, sustainably, and grows. An excellent EM holds three intertwined jobs — delivery, people, and direction — judged by what the team produces, not what they personally produce.

Core Mission

Build and sustain a team that reliably delivers valuable, high-quality software by aligning the right people, work, and direction so its output exceeds the sum of its individuals.

Primary Responsibilities

Run effective 1:1s and grow each engineer through feedback, coaching, and stretch work. Hire, onboard, and — when necessary — manage out underperformers. Own delivery: planning, execution, unblocking, predictable shipping against commitments. Translate strategy into direction and scope. Maintain technical and operational health: tech-debt management, SLOs, on-call, incident response, architectural coherence. Shield the team from organizational noise while keeping them informed, and manage interfaces with product, design, and other teams. Handle performance management, compensation advocacy, and the glue work that keeps the team running.

Guiding Principles

• You are a force multiplier, not the best engineer. Your job is the team's output; coding more than you manage means avoiding the harder job.
• Delivery, people, and direction are one system. Neglect people and delivery decays; neglect direction and the team ships the wrong thing efficiently.
• Trust is the operating system. A team that trusts its manager surfaces problems early — built through 1:1s, consistency, and taking the public hit.
• Hire slowly, address performance quickly. A bad hire costs a year; a tolerated low performer demoralizes everyone.
• Make the path clear, then get out of the way. Set context and constraints, delegate the how.
• Conway's Law is real — design the org, not just the code. Team boundaries become system boundaries; shape teams to match the architecture you want.
• Optimize for the long run. Velocity bought by burning people or skipping tests is a loan with brutal interest.

Mental Models

• The three hats — delivery, people, direction. A diagnostic for where you're under-invested: if delivery is fine but attrition rises, you've over-indexed on shipping at the cost of people.
• Span of control. Beyond roughly 6–8 directs, 1:1 quality and context degrade — the signal to split or layer.
• Conway's Law. Systems mirror the communication structures that build them; restructure teams to get the architecture you want.
• Force multiplier vs. individual contributor. Your leverage is removing blockers, setting context, and growing engineers — compounding across the team.
• Glue work. The invisible coordination, mentoring, and unblocking that holds a team together — undervalued but essential; the EM does it and ensures it's recognized.
• The manager's path / two ladders. Management and senior IC are distinct tracks, not up vs. down — an engineer can grow without managing.
• Local vs. global optimization. A team optimizing its own velocity can hurt the system; the EM holds the global view.

First Principles

Software is a team sport; the unit of delivery is the team, not the individual. People do their best work with autonomy, mastery, and purpose, and when safe to fail. Information flows poorly up a hierarchy — bad news must be pulled or it arrives too late. Trust is built in drops and lost in buckets. Manager and engineer incentives diverge under pressure (manager owns the deadline, engineer owns quality); the EM keeps that tension productive, not winning it.

Questions Experts Constantly Ask

• Is the team shipping the most valuable thing, or just the busiest?
• Who is growing, who is stuck, and who is at flight risk?
• What is each person trying to tell me in their 1:1 but not saying?
• Am I the bottleneck on this decision, and can I delegate it?
• Is our pace sustainable, or borrowing against next quarter?
• Does our team structure match the system we're building?
• What am I shielding the team from, and what should I let through?
• Is my time on the highest-leverage thing?

Decision Frameworks

• Delegate vs. do: Delegate anything that grows an engineer or that you're not uniquely needed for; reserve your hands for what only you can do — hard people calls, cross-team alignment.
• Build vs. buy vs. borrow (for capability): Hire for durable need, contract for spikes, develop existing engineers for retention.
• Performance intervention ladder: Coach → explicit feedback with examples → improvement plan with clear bar and timeline → exit; clarity is kinder than ambiguity.
• Tech-debt vs. feature tradeoff: Fund debt paydown when it slows delivery or threatens reliability (rising incident rate, falling velocity); resist gold-plating otherwise. Make the cost visible to product in delivery terms.
• Escalation: Escalate cross-team blockers and resourcing conflicts you can't resolve; never what a peer chat would solve.

Workflow

Trigger: a team, a mandate, a roadmap. Cadence: weekly 1:1s with every direct (their agenda first); planning aligned to the sprint/quarter; regular skip-levels and peer-manager syncs. Daily: clear blockers, watch for risk signals, protect focus time, stay close enough for context. Delivery loop: scope with product, break down work, track commitments, surface slippage early. People loop: continuous feedback, quarterly growth conversations, active management of performance and morale. Health loop: monitor SLOs, incident trends, and tech-debt drag; fund remediation before a crisis. A good state is a team that ships predictably, grows its people, and would speak well of you.

Common Tradeoffs

• Delivery vs. people vs. direction. Time on any one is taken from the others; over-rotating on delivery burns people, on direction starves execution.
• Shipping now vs. team health. A crunch can hit a date and cost attrition, quality, and two quarters of velocity.
• Autonomy vs. alignment. Too much autonomy fragments architecture; too much control kills ownership.
• Hands-on vs. hands-off. Staying technical keeps judgment sharp but pulls you into IC work; detachment leaves you unable to assess risk.
• Protecting the team vs. exposing them. Shielding builds trust but can leave engineers unprepared for reality.
• Tech debt vs. features. Both are real costs; the skill is funding debt in terms product can weigh.
• Loyalty to a struggling engineer vs. fairness to the team. Carrying someone too long is unfair to those who compensate.

Rules of Thumb

• The 1:1 is the engineer's meeting, not your status update — if you're talking most of it, you're doing it wrong.
• If you're the smartest engineer on everything, your team is too junior or you're hoarding the interesting work.
• Praise in public, correct in private, own failures as the leader.
• When velocity drops, look for fear, ambiguity, or tech debt before laziness.
• Don't reorganize to fix what a conversation could fix.
• Hire for trajectory and collaboration, not just current skill.
• If you've meant to give hard feedback for two weeks, you're already late.

Failure Modes

• The player-coach trap: Keeps coding the critical path, becomes a bottleneck, neglects management.
• Seagull management: Swoops in only when things break, dumps decisions, leaves — destroying trust.
• Conflict avoidance: Lets performance and interpersonal issues fester rather than have the hard conversation; the team pays.
• Death-march delivery: Hits dates by burning people, then loses them and their velocity.
• Process cargo-culting: Adds ceremonies and metrics (story points, velocity charts) as ritual, optimizing the proxy not outcomes.
• Hero dependence: Builds the team around one indispensable engineer — fragility and burnout.
• Information hoarding or flooding: Shields the team from everything (blindsided) or relays every tremor (anxious).

Anti-patterns

• Promoting the best engineer into management as a reward — losing a great IC, gaining a poor manager.
• Measuring engineers by lines of code, commits, or hours.
• Skipping 1:1s when busy — exactly when they matter most.
• Treating velocity as a productivity target, not a planning aid (Goodhart's law).
• Reorganizing teams faster than they can form, storm, and norm.
• Saying yes to every product request, then overcommitting.
• Doing all the glue work yourself instead of distributing and crediting it.

Vocabulary

• 1:1: Recurring private manager-report meeting, owned by the report.
• Span of control: Number of direct reports a manager has.
• Conway's Law: Systems mirror the org's communication structure.
• Glue work: Invisible coordination/mentoring that holds a team together.
• Force multiplier: Leverage a manager adds to the team's output.
• SLO / SLA / error budget: Reliability targets and the allowance for failure.
• Tech debt: Deferred engineering cost that slows future work.
• Velocity / story points: Planning measures of throughput, not productivity scores.
• PIP: Performance Improvement Plan — a structured, time-bound intervention.
• Skip-level: Manager meeting with reports' reports.
• The two ladders: Parallel management and senior-IC tracks.
• Maker time: Long uninterrupted blocks for deep work.

Tools

Issue trackers and planning (Jira, Linear, GitHub Projects) for delivery and roadmap. 1:1 and feedback tools (Lattice, 15Five) for people management and growth. Observability and incident tools (Datadog, PagerDuty, Grafana) for SLOs and on-call health. Source and CI/CD (GitHub, GitLab) for the team's pulse — PR throughput, review latency. DORA metrics (deployment frequency, lead time, change-fail rate, MTTR) as outcome signals. Communication (Slack, docs, RFCs) as the primary medium. An EM who manages by dashboard instead of talking to people is blind.

Collaboration

Partners with the product manager on roadmap, scope, and tradeoffs — a healthy EM/PM relationship negotiates feasibility against value, not a tug of war. Works with design on what's buildable, and aligns with peer EMs on shared systems, dependencies, and Conway's-Law boundaries. Reports to a director/VP, translating strategy down and reality up, and advocates for the team in headcount, compensation, and prioritization. As the team's interface to the organization, much of the job is keeping those interfaces smooth so engineers focus.

Ethics

Tell engineers the truth — about performance, the company's situation, and a project's risks — even when uncomfortable, giving feedback that helps people grow rather than protecting your comfort. Manage people out with dignity, clarity, and fairness, never by ambush. Advocate honestly for fair compensation and credit, including the glue work that's easy to overlook. Respect the confidentiality of 1:1s. Resist pressure to crunch a team into burnout for a date that won't matter in a year. The EM holds real power over careers, and exercising it honestly and humanely is the core of the role.

Scenarios

The brilliant jerk. A senior engineer ships the best code but is corrosive in reviews — dismissive, territorial, driving two juniors toward leaving. The EM judges the net effect negative: one person's output doesn't justify losing two. Reasoning: throughput is a system, not a sum, and toxicity degrades the whole. The EM gives direct behavioral feedback in a 1:1 with a timeline; if it doesn't change, manages the person out despite the technical loss, because tolerating it teaches the team that results excuse cruelty.

The impossible deadline. Product commits the team to a date that, by the EM's read, requires a crunch or cutting quality. Rather than absorb or refuse, the EM makes the tradeoff visible — realistic scope at the date, full scope later, the cost of crunching (attrition, tech debt, defects) in delivery terms — then descopes with the PM to a credible MVP. Reasoning: the EM owns the truth about capacity; the valuable move is converting a false binary into an honest negotiation, protecting both the date and the team that must keep shipping next quarter.

The reluctant reorg. Two teams keep stepping on the same service; every change needs cross-team coordination and ownership is muddy — a classic Conway's-Law mismatch. Resisting the reflex to add process, the EM and peer EMs redraw boundaries so one team fully owns the service with a clean interface. Reasoning: the coordination cost is a symptom of an architecture/org mismatch, and changing the communication structure changes the system. They accept a short-term velocity dip for lasting autonomy.

Related Occupations

The EM most often grows from software-engineer and stays in constant collaboration with that role — the management progression from the IC track, though the senior-IC ladder is an equally valid path. Day to day the EM partners with the product-manager on what to build and the project-manager on coordinating delivery. At larger scope it borders the operations-manager and the people-leadership craft shared with the human-resources-manager.

References

• The Manager's Path — Camille Fournier.
• An Elegant Puzzle: Systems of Engineering Management — Will Larson.
• High Output Management — Andy Grove.
• Accelerate (DORA metrics) — Forsgren, Humble, Kim.