Engineering Manager OS

# 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.

```yaml
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.

| Dimension | Score | Signal |
|-----------|-------|--------|
| **Delivery pace** | _ /5 | Are we shipping what we committed? |
| **Quality** | _ /5 | Bug rate, incident frequency, tech debt trajectory |
| **Collaboration** | _ /5 | Cross-functional work, PR review speed, knowledge sharing |
| **Morale** | _ /5 | Energy in meetings, voluntary contributions, retention signals |
| **Learning** | _ /5 | New skills adopted, conference talks, internal tech talks |
| **Autonomy** | _ /5 | Can the team make decisions without waiting for me? |
| **Psychological safety** | _ /5 | Do people raise concerns, admit mistakes, challenge ideas? |
| **On-call health** | _ /5 | Page frequency, off-hours burden, burnout signals |

**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):

| Role | Description | Gap Impact |
|------|-------------|------------|
| **Tech lead** | Architecture decisions, code quality bar | Decisions bottleneck through you |
| **Senior IC** (2-3) | Carry complex work, mentor juniors | Velocity drops, quality suffers |
| **Mid-level** (2-3) | Reliable delivery, growing scope | No bench for senior pipeline |
| **Junior** (0-2) | Learning, fresh perspective | No talent pipeline |
| **Domain expert** | Deep knowledge of the problem space | Constantly solving wrong problems |

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

---

## Phase 2: 1:1 System

### 1:1 Cadence

| Report Level | Frequency | Duration | Focus |
|-------------|-----------|----------|-------|
| Direct reports | Weekly | 30 min | Career + blockers + feedback |
| Skip-levels | Monthly | 30 min | Team health + career + honesty check |
| Your manager | Weekly | 30 min | Priorities + asks + air cover |
| Cross-functional peers | Bi-weekly | 25 min | Dependencies + alignment |

### 1:1 Template (Direct Reports)

```yaml
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:

| Signal | Weight | Detection |
|--------|--------|-----------|
| LinkedIn profile update | 🔴 High | Someone mentions it, or you notice |
| Declining 1:1 engagement | 🔴 High | Shorter answers, less eye contact, "everything's fine" |
| Stopped volunteering for projects | 🟡 Medium | Used to raise hand, now doesn't |
| Increased PTO without travel | 🟡 Medium | Interviewing signal |
| Disengaged in meetings | 🟡 Medium | Camera off, multitasking, no opinions |
| Complaining shifted from specific to general | 🟡 Medium | "This sprint is rough" → "This place..." |
| Stopped arguing for their ideas | 🔴 High | They've mentally checked out |
| Life event (new baby, move, partner change) | 🟡 Medium | Re-evaluating everything |

**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)**
| Level | Description |
|-------|-------------|
| 1 - Below | Missing commitments, quality issues, needs close oversight |
| 2 - Meeting | Delivering assigned work reliably |
| 3 - Exceeding | Delivering beyond scope, finding better solutions |
| 4 - Outstanding | Multiplying team output, solving problems no one asked them to |

**Behaviors (How)**
| Level | Description |
|-------|-------------|
| 1 - Below | Creating friction, not collaborating, ignoring feedback |
| 2 - Meeting | Professional, collaborative, receptive to feedback |
| 3 - Exceeding | Mentoring others, proactively improving processes |
| 4 - Outstanding | Shaping culture, attracting talent, raising the entire bar |

**Calibration matrix:**

| | Behavior 1 | Behavior 2 | Behavior 3 | Behavior 4 |
|---|---|---|---|---|
| **Delivery 4** | Coach behaviors | Strong | Top performer | Superstar |
| **Delivery 3** | Coach behaviors | Solid | Strong | Top performer |
| **Delivery 2** | PIP candidate | Meets expectations | Developing | Growing |
| **Delivery 1** | Exit | PIP | Coach delivery | Coach delivery |

### 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

```yaml
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

```yaml
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

```markdown
# [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)

```yaml
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)

```yaml
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**

| Score | Action |
|-------|--------|
| 20-25 | Fix THIS sprint — it's an emergency |
| 12-19 | Schedule within 2 sprints |
| 6-11 | Add to quarterly tech debt budget (allocate 15-20% of sprint capacity) |
| 1-5 | Backlog — revisit quarterly |

### Code Review Culture Guidelines

```yaml
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

| Ceremony | Duration | Who | Purpose | Your Role |
|----------|----------|-----|---------|-----------|
| **Sprint planning** | 1-2 hrs | Team + PO | Commit to sprint goal | Facilitate, challenge estimates, protect capacity |
| **Daily standup** | 15 min | Team | Surface blockers | Listen for problems, DON'T manage tasks |
| **Backlog refinement** | 1 hr | Team + PO | Prepare future work | Ensure technical feasibility, flag risks |
| **Sprint review** | 30 min | Team + stakeholders | Demo working software | Let the team present, handle stakeholder Qs |
| **Retrospective** | 1 hr | Team only | Improve process | Facilitate, ensure psychological safety, track actions |

### Sprint Health Metrics

Track these weekly — trend matters more than absolute numbers:

| Metric | Healthy Range | Red Flag |
|--------|---------------|----------|
| **Sprint completion rate** | 80-100% of committed points | <70% for 2+ sprints |
| **Carry-over stories** | 0-1 per sprint | Same story carried 3+ sprints |
| **PR cycle time** | <48 hours open to merge | >72 hours consistently |
| **Bug escape rate** | <10% of stories create bugs | Rising trend |
| **Deployment frequency** | Daily to weekly | Monthly or less |
| **Sprint goal achievement** | Yes/No binary | No for 3+ consecutive sprints |

### Estimation Heuristic

When the team struggles with estimation:

| Certainty Level | Approach |
|----------------|----------|
| "We've done this exact thing before" | Size by comparison to past work |
| "We understand the problem but not the solution" | Spike first (timeboxed), then estimate |
| "We don't fully understand the problem" | Discovery task (1-2 days), then re-scope |
| "We have no idea" | Break it down until you reach pieces you can estimate |

**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

```yaml
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

| Metric | Healthy | Unhealthy |
|--------|---------|-----------|
| Pages per week | <5 | >10 |
| Off-hours pages | <2/week | >5/week |
| Time to acknowledge | <5 min | >15 min |
| False positive rate | <20% | >50% |
| Rotation size | 4+ people | <3 people |
| Consecutive weeks on-call | Never >2 | Regular 3+ week stretches |

**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

| Signal | Action |
|--------|--------|
| Team >8 people | Split before communication overhead kills velocity |
| Two distinct domains in one team | Split along domain boundaries |
| Standup takes >15 min | Too many threads — people are tuning out |
| PR review queue >48 hours consistently | Not enough context overlap — specialize |
| On-call covers too many services | Reduce blast radius per 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

| Team Size | Structure |
|-----------|-----------|
| 3-5 ICs | Player-coach (you're still coding ~30-40%) |
| 5-8 ICs | Full-time manager (stop coding in critical path) |
| 8-12 ICs | Split the team OR add a tech lead as force multiplier |
| 12+ ICs | Must split — you cannot manage this effectively |

### 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:

```markdown
# [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

| Do | Don't |
|----|-------|
| Bring solutions with problems | Dump problems without proposals |
| Flag risks early with mitigation plans | Surprise with bad news at the last minute |
| Quantify impact (hours, $$, users) | Use vague language ("it's kinda slow") |
| Say "I need X from you by Y" | Hope they'll figure out you need help |
| Send written updates proactively | Wait to be asked for status |
| Disagree in private | Disagree in public meetings |
| Ask for feedback regularly | Assume no news is good news |

### Cross-Functional Relationship Map

```yaml
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)

| Dimension | Weight | Indicators |
|-----------|--------|------------|
| **Team health** | 20% | Retention, engagement scores, psychological safety signals |
| **Delivery** | 20% | Sprint completion, quality metrics, stakeholder satisfaction |
| **People development** | 20% | Promotions, skill growth, 1:1 quality, mentorship |
| **Technical stewardship** | 15% | Tech debt trajectory, architecture quality, incident trends |
| **Hiring** | 10% | Pipeline health, offer acceptance rate, new hire ramp time |
| **Communication** | 10% | Stakeholder relationships, information flow, no surprises |
| **Self-improvement** | 5% | Seeking feedback, adapting, growing as a leader |

**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