Engineering Manager Operating System

Your complete playbook for engineering leadership. Not generic management advice — this is the specific system that high-performing engineering managers run daily.

Phase 1: Team Architecture

Team Topology Assessment

Before managing people, understand the system they work in.

team_topology:
  name: "[Team Name]"
  type: stream-aligned | platform | enabling | complicated-subsystem
  mission: "[One sentence — what does this team exist to do?]"
  boundaries:
    owns: ["service-x", "domain-y", "pipeline-z"]
    consumes: ["auth-service", "data-platform"]
    provides: ["checkout-api", "payment-events"]
  cognitive_load: low | medium | high | overloaded
  interaction_modes:
    - team: "[Other Team]"
      mode: collaboration | x-as-a-service | facilitating
      friction: low | medium | high
      notes: "[What's working/not working]"
  current_headcount: N
  ideal_headcount: N
  skill_gaps: ["observability", "mobile", "ML"]

Team Health Radar (Monthly)

Score 1-5 for each dimension. Track trends over time.

Action rules:

• Any dimension ≤2 → Address THIS WEEK (it's a fire)
• Any dimension at 3 → Create improvement plan within 2 weeks
• Overall average <3.5 → Team is struggling, block new commitments until fixed
• Track quarter-over-quarter — sustained decline in any dimension = systemic issue

Team Composition Model

The ideal team has these roles covered (not necessarily 1:1 with people):

Rule of thumb: Never have >60% of team at same level. Mix creates natural mentorship.

Phase 2: 1:1 System

1:1 Cadence

1:1 Template (Direct Reports)

one_on_one:
  date: "YYYY-MM-DD"
  person: "[Name]"
  role: "[Title]"
  tenure: "[X months on team]"
  
  # Their agenda first — ALWAYS
  their_topics: []
  
  # Check-in (2 min)
  energy_level: 1-10  # "How are you feeling about work this week?"
  energy_trend: up | stable | down
  
  # Delivery (5 min)
  current_work: "[What they're working on]"
  blockers: []
  help_needed: "[What can I unblock?]"
  
  # Growth (10 min — skip if urgent topics dominate, but never 3 weeks in a row)
  career_conversation: "[Topic discussed]"
  feedback_given: "[Specific behavior → impact → request]"
  feedback_received: "[What they told me]"
  stretch_opportunity: "[Current or upcoming]"
  
  # Action items
  my_actions: []  # What I committed to do
  their_actions: []  # What they committed to do
  
  # Signals (private — don't share these)
  flight_risk: low | medium | high
  performance_trajectory: improving | stable | declining
  notes: "[Anything notable]"

1:1 Question Bank

Opening (rotate these — never use the same opener 3 weeks in a row):

• "What's on your mind?"
• "What was the best/worst part of your week?"
• "If you could change one thing about how we work, what would it be?"
• "What's something you're proud of from this week that I might not know about?"
• "On a scale of 1-10, how's your energy? What would move it up one point?"

Career development (monthly deep-dive):

• "Where do you want to be in 2 years? What's the gap between here and there?"
• "What skills are you not using that you'd like to use more?"
• "Who in the org (or industry) has a role you'd want? What specifically about it?"
• "What's the hardest technical problem you've solved recently? What did you learn?"
• "If you left tomorrow, what would you regret not doing here?"

Team health (probe with care):

• "Who on the team do you learn the most from? The least?"
• "Is there anyone whose work you don't trust to review?"
• "What's something the team avoids talking about?"
• "If you were me, what would you change about how this team operates?"

Feedback solicitation (for YOU):

• "What's one thing I could do differently that would help you most?"
• "Am I giving you too much direction or too little?"
• "Is there context I have that I'm not sharing that would help you?"
• "When was the last time I frustrated you? What happened?"

Flight Risk Detection

Monitor these signals — if 3+ present, have a retention conversation within a week:

Retention conversation framework:

1. Name it: "I've noticed [specific behavior change]. I want to check in."
2. Listen: Let them talk. Don't interrupt. Don't get defensive.
3. Understand: "What would make this the best job you've ever had?"
4. Act: Make a concrete commitment within 48 hours — title, comp, scope, flexibility
5. Follow up: Check back in 1 week. Did what you promised make a difference?

Phase 3: Performance Management

Performance Calibration Framework

Rate on two axes (both matter):

Delivery Impact (What)

Behaviors (How)

Calibration matrix:

Feedback Framework: SBI-I (Situation-Behavior-Impact-Intent)

Template: "In [situation], when you [specific behavior], the impact was [concrete effect]. I'd like to see [specific change] because [intent/why it matters]."

Examples:

✅ Good: "In yesterday's design review, when you challenged the API schema with the versioning concern, it caught a breaking change we would have shipped. That's exactly the kind of technical leadership I want to see more of."

❌ Bad: "You're doing great work. Keep it up." (Too vague — they learn nothing)

✅ Good: "In the last two sprints, PRs have been sitting in review for 3+ days. The impact is features are merging late and we're missing sprint commitments. I'd like us to commit to <24h first review because velocity depends on review speed."

❌ Bad: "You need to review PRs faster." (No situation, no impact, no collaboration)

Performance Improvement Plan (PIP) Template

pip:
  employee: "[Name]"
  role: "[Title]"
  manager: "[Your name]"
  start_date: "YYYY-MM-DD"
  end_date: "YYYY-MM-DD"  # 30-60 days, never >90
  
  context: |
    [Specific pattern of underperformance with dates and examples.
     Must reference prior feedback conversations and dates they occurred.]
  
  expectations:
    - area: "[Specific skill/behavior]"
      current_state: "[What's happening now — with examples]"
      target_state: "[What success looks like — measurable]"
      measurement: "[How we'll measure — PR metrics, sprint completion, etc.]"
      support: "[What I'll provide — pairing, training, reduced scope]"
  
  check_ins:
    frequency: weekly
    day: "[Day]"
    format: "[30 min 1:1 with written summary]"
  
  outcomes:
    success: "[What happens if targets met — return to normal performance management]"
    failure: "[What happens if targets not met — typically termination]"
  
  # CRITICAL: Have HR review before sharing. Document every check-in.
  hr_reviewed: false
  hr_reviewer: "[Name]"

PIP rules:

• A PIP should never be a surprise — if it is, YOU failed at feedback
• PIPs are for capability gaps, not attitude problems (attitude = manage out faster)
• 70% of PIPs end in termination — be honest with yourself about whether this is a development tool or a documentation exercise
• Weekly check-ins are non-negotiable — document everything in writing
• If performance improves during PIP then declines after: second PIP is rarely worth it

Promotion Case Template

promotion_case:
  candidate: "[Name]"
  current_level: "[Level]"
  target_level: "[Level]"
  manager: "[Your name]"
  date: "YYYY-MM-DD"
  
  # Already operating at next level (past 6+ months)
  evidence:
    - dimension: "Technical complexity"
      examples:
        - "[Specific project/decision with measurable impact]"
        - "[Another example]"
    - dimension: "Scope & ownership"
      examples:
        - "[Owned X end-to-end, previously needed guidance]"
    - dimension: "Influence & leadership"
      examples:
        - "[Mentored Y, led Z initiative, shaped team direction]"
    - dimension: "Business impact"
      examples:
        - "[Revenue/efficiency/reliability improvement with numbers]"
  
  peer_feedback:
    - from: "[Name, role]"
      quote: "[Specific praise with examples]"
  
  # Why now, not 6 months from now?
  timing_justification: |
    [They've been consistently operating at next level for X months.
     Delaying creates retention risk and sends wrong signal to team.]
  
  # What's the gap? (Be honest — calibration committees will find it)
  growth_areas: |
    [Areas they're still developing. Frame as "growing into" not "lacking."]

Phase 4: Hiring Machine

Hiring Pipeline

Role opened → Job description → Sourcing (5-7 days)
→ Resume screen → Recruiter screen (30 min)
→ Technical phone screen (60 min) → Take-home OR live coding (2-4 hrs)
→ Onsite/virtual loop (3-4 hrs) → Debrief → Offer → Close

Target: <21 days from first screen to offer

Job Description Template

# [Role Title] — [Team Name]

## What you'll do
[3-5 bullet points of ACTUAL work, not generic responsibilities]
- Ship [specific feature/system] that [specific impact]
- Own [specific domain] end-to-end
- [Concrete example of a recent problem this person would solve]

## What you'll need
[Must-haves only — each one must be a genuine filter]
- X years building [specific technology/domain]
- Experience with [specific technical requirement]
- [Skill that actually differentiates candidates]

## Nice to have (genuinely nice, not secretly required)
- [Thing that would accelerate ramp-up]
- [Adjacent skill that adds value]

## What we offer
[Be specific — "competitive salary" means nothing]
- Salary range: $X-$Y (based on [location/level])
- [Specific benefits that matter to engineers]
- [Team/culture thing that's actually true and differentiating]

## How we hire
[Timeline and what to expect — respect their time]
1. [Step]: [Duration] — [What we're assessing]
2. [Step]: [Duration] — [What we're assessing]
Total time investment: ~X hours

Interview Scorecard (Per Interviewer)

scorecard:
  candidate: "[Name]"
  interviewer: "[Name]"
  interview_type: "technical | system design | behavioral | culture"
  date: "YYYY-MM-DD"
  
  # Score each dimension 1-4 (no 3s allowed — forces a decision)
  dimensions:
    - name: "Technical depth"
      score: _  # 1=no hire, 2=lean no, 4=lean yes, 5=strong yes (skip 3)
      evidence: "[Specific examples from the interview]"
    - name: "Problem solving approach"
      score: _
      evidence: "[How they broke down the problem, handled hints]"
    - name: "Communication clarity"
      score: _
      evidence: "[Could they explain their thinking? Did they ask good questions?]"
    - name: "Collaboration signals"
      score: _
      evidence: "[How did they respond to pushback? Did they build on ideas?]"
  
  # Overall
  hire_recommendation: strong_no | no | yes | strong_yes
  level_recommendation: "[What level would you place them?]"
  concerns: "[Anything that gave you pause]"
  highlights: "[What impressed you most]"

Debrief Protocol

1. No pre-discussion — Submit scorecards BEFORE the debrief meeting
2. Hire bar holder speaks last — Prevent anchoring
3. Discuss each dimension, not overall vibes — "Tell me about their system design approach" not "What did you think?"
4. Any strong_no is a veto — Unless the interviewer can be convinced their signal was a misread
5. Decide in the room — Don't "sleep on it" unless genuinely torn (then it's probably a no)
6. Leveling before offer — Agree on level first, then comp follows from band

Closing Candidates

The 3 things that close engineers:

1. The problem — "Here's the specific hard problem you'd work on"
2. The people — Connect them with future teammates before offer
3. The growth — "Here's where this role leads in 18 months"

Offer call structure (15-20 min):

1. Express genuine excitement (2 min)
2. Present offer details — base, equity, bonus, start date (3 min)
3. Explain equity/comp philosophy (3 min)
4. Ask: "How does this compare to what you were expecting?" (listen)
5. Address concerns immediately if possible
6. Set a decision deadline (3-5 business days, not open-ended)
7. Ask: "Is there anything that would make this a clear yes?"

Phase 5: Technical Leadership

Architecture Decision Record (ADR)

adr:
  id: "ADR-NNN"
  title: "[Decision title]"
  date: "YYYY-MM-DD"
  status: proposed | accepted | deprecated | superseded
  superseded_by: "ADR-NNN"  # if applicable
  
  context: |
    [What situation are we in? What forces are at play?
     Include constraints: timeline, team skill, budget, scale requirements.]
  
  options:
    - name: "[Option A]"
      pros: ["pro 1", "pro 2"]
      cons: ["con 1", "con 2"]
      effort: "[T-shirt size]"
      risk: low | medium | high
    - name: "[Option B]"
      pros: ["pro 1"]
      cons: ["con 1", "con 2", "con 3"]
      effort: "[T-shirt size]"
      risk: low | medium | high
  
  decision: |
    [What we decided and WHY. The "why" is the most important part.
     Future readers need to understand the reasoning, not just the choice.]
  
  consequences: |
    [What follows from this decision? What becomes easier/harder?
     What do we need to monitor?]
  
  review_date: "YYYY-MM-DD"  # When to revisit this decision

Tech Debt Prioritization

Score each debt item on two axes:

Impact of fixing (1-5):

• 5: Unblocks multiple teams or critical features
• 4: Significant velocity improvement for our team
• 3: Moderate improvement, prevents future problems
• 2: Nice to have, minor improvement
• 1: Cosmetic or theoretical benefit

Cost of NOT fixing (1-5):

• 5: Will cause incidents or data loss
• 4: Blocking hiring/onboarding (can't explain the code)
• 3: Slowing every feature by >20%
• 2: Occasional friction, workarounds exist
• 1: Annoying but harmless

Priority = Impact × Cost-of-not-fixing

Code Review Culture Guidelines

code_review_standards:
  sla:
    first_review: "< 4 hours during work hours"
    follow_up: "< 2 hours"
    max_pr_size: 400  # lines changed — larger needs pre-review or splitting
  
  what_to_review:
    always:
      - "Correctness — does it do what it claims?"
      - "Edge cases — what happens with nil/empty/max/concurrent?"
      - "Security — auth checks, input validation, secrets exposure"
      - "Naming — will someone understand this in 6 months?"
    sometimes:
      - "Performance — only if in hot path or O(n²)+ risk"
      - "Style — only if it significantly hurts readability"
    never:
      - "Personal preference disguised as improvement"
      - "Premature optimization suggestions"
      - "Rewriting working code to your style"
  
  tone_rules:
    - "Ask questions instead of making demands: 'What happens if X is nil?' not 'Handle the nil case'"
    - "Prefix opinion with 'nit:' or 'optional:' — make severity clear"
    - "Praise good code — 'Nice abstraction here' costs nothing"
    - "If >5 comments, offer to pair instead"
    - "Approve with comments when nothing is blocking — trust your team"

Phase 6: Sprint & Delivery

Sprint Ceremony Cheat Sheet

Sprint Health Metrics

Track these weekly — trend matters more than absolute numbers:

Estimation Heuristic

When the team struggles with estimation:

Rule: If an estimate is >8 points (or >5 days), it's not estimated — it's a guess. Break it down further.

Phase 7: Incident Management

Incident Response Framework

incident:
  id: "INC-YYYY-NNN"
  severity: SEV1 | SEV2 | SEV3 | SEV4
  detected: "YYYY-MM-DD HH:MM UTC"
  resolved: "YYYY-MM-DD HH:MM UTC"
  duration: "Xh Ym"
  commander: "[Name]"
  
  # Severity guide
  # SEV1: Revenue impact, data loss, full outage — ALL HANDS, exec notification
  # SEV2: Degraded service, partial outage — On-call + team lead
  # SEV3: Minor degradation, workaround exists — On-call handles
  # SEV4: Cosmetic, no user impact — Normal ticket
  
  timeline:
    - time: "HH:MM"
      action: "[What happened / what was done]"
      who: "[Name]"
  
  root_cause: |
    [Technical root cause — be specific. 
     "Human error" is never the root cause. What system allowed the error?]
  
  contributing_factors:
    - "[Factor 1 — e.g., missing monitoring on X]"
    - "[Factor 2 — e.g., deployment during peak without feature flag]"
  
  action_items:
    - description: "[Specific fix]"
      owner: "[Name]"
      due_date: "YYYY-MM-DD"
      priority: P0 | P1 | P2
      status: open | in_progress | done

Blameless Post-Mortem Template

Facilitation rules:

1. Focus on systems, not individuals
2. "What" and "how," never "who"
3. Everyone involved attends (including on-call who was paged)
4. Schedule within 48 hours of resolution (memories fade)
5. Write it up and share publicly within the engineering org

Structure (60-90 min):

1. Timeline review (20 min) — Walk through chronologically. Fill gaps.
2. Root cause analysis (15 min) — "5 Whys" until you hit a systemic issue
3. What went well (10 min) — Reinforce good incident response behaviors
4. What went wrong (15 min) — Process failures, detection gaps, communication issues
5. Action items (15 min) — Each must have an owner and due date. Max 5 items — focus beats volume.

On-Call Health Guidelines

If on-call is unhealthy: This is a tech debt problem, not a people problem. Invest in reliability before adding headcount.

Phase 8: Scaling & Org Design

When to Split a Team

Splitting Protocol

1. Define boundaries clearly — What does each new team OWN? Write it down.
2. Split the backlog — Every ticket gets a home. Shared backlogs = shared ownership = no ownership.
3. Split on-call — Each team owns their services' reliability.
4. Name the teams — Sounds trivial, matters for identity.
5. Designate tech leads — Don't leave both teams looking to you for technical decisions.
6. Give it 3 months — Resist re-orging again too quickly. Turbulence is normal.

Manager-to-IC Ratio

The IC-to-Manager Transition

If you're newly managing (or coaching someone through it):

Stop doing:

• Writing code in the critical path (you're now the bottleneck)
• Solving every technical problem yourself
• Being the best engineer on the team (your job changed)

Start doing:

• Asking "who should own this?" instead of doing it yourself
• Measuring success by team output, not your output
• Having uncomfortable conversations early (feedback, performance, conflict)
• Blocking time for thinking, not just meetings

Keep doing:

• Staying technical enough to evaluate decisions (read code, review designs)
• Coding on side projects, tools, or prototypes (stay sharp)
• Having strong technical opinions (but hold them loosely)

Timeline to competence:

• Month 1-3: Imposter syndrome, everything feels slow. Normal.
• Month 3-6: Finding your rhythm, some wins, some failures. Normal.
• Month 6-12: Confident in the role, building systems. Target.
• Month 12+: Multiplying impact. If you're not here by month 18, honest conversation needed.

Phase 9: Communication & Stakeholder Management

Weekly Status Update Template

Send this to your manager and stakeholders every Friday:

# [Team Name] — Week of [Date]

## 🎯 Sprint Goal: [Goal] — On Track / At Risk / Off Track

## ✅ Shipped This Week
- [Feature/fix] — [Impact in user/business terms]
- [Feature/fix] — [Impact]

## 🔨 In Progress
- [Work item] — [Status, ETA, any blockers]

## 🚨 Risks & Blockers
- [Risk] — [What you're doing about it, what you need]

## 📊 Key Metrics
- Deploy frequency: X
- Incident count: X (SEV breakdown)
- Sprint completion: X%

## 🔮 Next Week
- [Priority 1]
- [Priority 2]

Managing Up Checklist

Cross-Functional Relationship Map

stakeholders:
  - name: "[Product Manager]"
    relationship: partner
    cadence: "Daily async + weekly 1:1"
    currency: "Scope clarity, user data, priority decisions"
    
  - name: "[Design Lead]"
    relationship: partner
    cadence: "Bi-weekly sync + ad-hoc"
    currency: "Early technical feasibility input"
    
  - name: "[Platform/Infra Team]"
    relationship: dependency
    cadence: "Monthly sync + Slack"
    currency: "Clear requirements, advance notice of needs"
    
  - name: "[Your Manager]"
    relationship: air_cover
    cadence: "Weekly 1:1"
    currency: "No surprises, clear asks, good judgment"

Phase 10: Engineering Manager Rituals

Daily (15 min total)

• Scan Slack/email for blockers — unblock before standup
• Attend standup — listen for patterns, not task updates
• Check PR queue — nudge any >24h reviews
• One piece of feedback (positive or constructive) to someone

Weekly

• All 1:1s completed (never cancel — reschedule if needed)
• Sprint metrics reviewed
• Status update sent to stakeholders
• Calendar audit — am I in meetings I shouldn't be in?
• One skip-level or cross-functional conversation

Monthly

• Team health radar updated
• Career development conversation with each report
• Tech debt review and prioritization
• On-call health review
• Update team topology doc

Quarterly

• Performance calibration (formal or informal)
• Team goals review and reset
• Architecture review — any ADRs need revisiting?
• Headcount planning — what do we need in 6 months?
• Retrospective on YOUR performance — ask your team for feedback

Phase 11: Difficult Situations Playbook

Scenario: Two Senior Engineers Disagree on Architecture

1. Let them present both approaches in a design doc (each writes their own section)
2. Define decision criteria BEFORE evaluating: reversibility, maintenance cost, team familiarity, timeline
3. Facilitate a time-boxed discussion (60 min max)
4. If no consensus: the tech lead or DRI decides. Not you (unless you must).
5. Document the decision as an ADR — the "why" matters more than the "what"
6. The person who "lost" must commit fully. Monitor for passive resistance.

Scenario: High Performer Wants to Be a Manager

1. Explore motivation: "Tell me what you think a manager does day-to-day"
2. Test with real work: lead a project, mentor a junior, run a retrospective
3. Be honest about tradeoffs: less coding, more meetings, slower feedback loops, ambiguous success metrics
4. Offer the Staff/Principal IC path as a genuine alternative, not a consolation prize
5. If they proceed: set explicit check-in at 3 months — "Is this what you wanted?"

Scenario: You Inherit a Low-Performing Team

1. Week 1-2: Listen. 1:1 with every person. Don't change anything yet.
2. Week 3-4: Identify the 1-2 systemic issues (usually: unclear priorities, no accountability, or trust deficit)
3. Month 2: Make ONE process change. Get a quick win. Build credibility.
4. Month 3: Address performance issues you've now observed firsthand
5. Never: Blame the previous manager publicly. Never say "things are going to change around here."

Scenario: Layoffs / Reorg Affecting Your Team

1. Before announcement: Prepare a plan for remaining team — who covers what?
2. During: Be honest about what you know and what you don't. "I don't know" > corporate-speak.
3. After: 1:1 with every remaining person within 48 hours. Expect anger, fear, guilt.
4. Ongoing: Workload audit — don't expect same output from fewer people. Push back on scope.
5. Self-care: This is one of the hardest parts of the job. Talk to your own manager or a coach.

Scenario: Your Best Engineer Gives Notice

1. Same day: Have a real conversation. Not a counteroffer — understand why.
2. If it's about money: Match or beat if they're worth it. If your company won't, that tells you something.
3. If it's about growth/role: Can you create what they want? Be honest if you can't.
4. If they're leaving for the right reasons: Celebrate them. Write a recommendation. Don't make it weird.
5. Immediately: Start knowledge transfer plan. Identify what only they know.
6. To the team: Transparent but positive. "X is leaving for a great opportunity. Here's our transition plan."

Scoring Rubric: Engineering Manager Effectiveness (0-100)

Scoring:

• 90-100: Exceptional — team thriving, people growing, shipping reliably
• 75-89: Strong — most things working, some areas to develop
• 60-74: Developing — foundational skills present, needs coaching
• 40-59: Struggling — significant gaps, at risk of losing team trust
• <40: Intervention needed — coaching, role change, or transition

Natural Language Commands

• "Prepare 1:1 with [name]" → Generate agenda from recent context
• "Write performance review for [name]" → Calibrate and draft using framework
• "Create job description for [role]" → Generate using template
• "Run team health check" → Walk through radar dimensions
• "Draft ADR for [decision]" → Structure architecture decision
• "Incident post-mortem for [incident]" → Generate post-mortem template
• "Sprint health report" → Analyze metrics and flag issues
• "Promotion case for [name]" → Build evidence-based promotion doc
• "Evaluate tech debt [item]" → Score using prioritization matrix
• "Flight risk assessment" → Review signals for each team member
• "Stakeholder update" → Generate weekly status from context
• "Interview scorecard for [candidate]" → Create structured evaluation