Engineering Manager OS

---

name: Engineering Manager OS description: Complete engineering management system — team building, 1:1s, performance, hiring, architecture decisions, incident management, and scaling. From IC-to-manager transition through director-level operations. metadata: {"clawdbot":{"emoji":"⚙️","os":["linux","darwin","win32"]}}

---

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.

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

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

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

| 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

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

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:

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

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