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.

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. DimensionScoreSignalDelivery pace_ /5Are we shipping what we committed?Quality_ /5Bug rate, incident frequency, tech debt trajectoryCollaboration_ /5Cross-functional work, PR review speed, knowledge sharingMorale_ /5Energy in meetings, voluntary contributions, retention signalsLearning_ /5New skills adopted, conference talks, internal tech talksAutonomy_ /5Can the team make decisions without waiting for me?Psychological safety_ /5Do people raise concerns, admit mistakes, challenge ideas?On-call health_ /5Page 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): RoleDescriptionGap ImpactTech leadArchitecture decisions, code quality barDecisions bottleneck through youSenior IC (2-3)Carry complex work, mentor juniorsVelocity drops, quality suffersMid-level (2-3)Reliable delivery, growing scopeNo bench for senior pipelineJunior (0-2)Learning, fresh perspectiveNo talent pipelineDomain expertDeep knowledge of the problem spaceConstantly solving wrong problems Rule of thumb: Never have >60% of team at same level. Mix creates natural mentorship.

1:1 Cadence

Report LevelFrequencyDurationFocusDirect reportsWeekly30 minCareer + blockers + feedbackSkip-levelsMonthly30 minTeam health + career + honesty checkYour managerWeekly30 minPriorities + asks + air coverCross-functional peersBi-weekly25 minDependencies + 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: SignalWeightDetectionLinkedIn profile update🔴 HighSomeone mentions it, or you noticeDeclining 1:1 engagement🔴 HighShorter answers, less eye contact, "everything's fine"Stopped volunteering for projects🟡 MediumUsed to raise hand, now doesn'tIncreased PTO without travel🟡 MediumInterviewing signalDisengaged in meetings🟡 MediumCamera off, multitasking, no opinionsComplaining shifted from specific to general🟡 Medium"This sprint is rough" → "This place..."Stopped arguing for their ideas🔴 HighThey've mentally checked outLife event (new baby, move, partner change)🟡 MediumRe-evaluating everything Retention conversation framework: Name it: "I've noticed [specific behavior change]. I want to check in." Listen: Let them talk. Don't interrupt. Don't get defensive. Understand: "What would make this the best job you've ever had?" Act: Make a concrete commitment within 48 hours — title, comp, scope, flexibility Follow up: Check back in 1 week. Did what you promised make a difference?

Performance Calibration Framework

Rate on two axes (both matter): Delivery Impact (What) LevelDescription1 - BelowMissing commitments, quality issues, needs close oversight2 - MeetingDelivering assigned work reliably3 - ExceedingDelivering beyond scope, finding better solutions4 - OutstandingMultiplying team output, solving problems no one asked them to Behaviors (How) LevelDescription1 - BelowCreating friction, not collaborating, ignoring feedback2 - MeetingProfessional, collaborative, receptive to feedback3 - ExceedingMentoring others, proactively improving processes4 - OutstandingShaping culture, attracting talent, raising the entire bar Calibration matrix: Behavior 1Behavior 2Behavior 3Behavior 4Delivery 4Coach behaviorsStrongTop performerSuperstarDelivery 3Coach behaviorsSolidStrongTop performerDelivery 2PIP candidateMeets expectationsDevelopingGrowingDelivery 1ExitPIPCoach deliveryCoach 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."]

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

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

Closing Candidates

The 3 things that close engineers: The problem — "Here's the specific hard problem you'd work on" The people — Connect them with future teammates before offer The growth — "Here's where this role leads in 18 months" Offer call structure (15-20 min): Express genuine excitement (2 min) Present offer details — base, equity, bonus, start date (3 min) Explain equity/comp philosophy (3 min) Ask: "How does this compare to what you were expecting?" (listen) Address concerns immediately if possible Set a decision deadline (3-5 business days, not open-ended) Ask: "Is there anything that would make this a clear yes?"

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 ScoreAction20-25Fix THIS sprint — it's an emergency12-19Schedule within 2 sprints6-11Add to quarterly tech debt budget (allocate 15-20% of sprint capacity)1-5Backlog — 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"

Sprint Ceremony Cheat Sheet

CeremonyDurationWhoPurposeYour RoleSprint planning1-2 hrsTeam + POCommit to sprint goalFacilitate, challenge estimates, protect capacityDaily standup15 minTeamSurface blockersListen for problems, DON'T manage tasksBacklog refinement1 hrTeam + POPrepare future workEnsure technical feasibility, flag risksSprint review30 minTeam + stakeholdersDemo working softwareLet the team present, handle stakeholder QsRetrospective1 hrTeam onlyImprove processFacilitate, ensure psychological safety, track actions

Sprint Health Metrics

Track these weekly — trend matters more than absolute numbers: MetricHealthy RangeRed FlagSprint completion rate80-100% of committed points<70% for 2+ sprintsCarry-over stories0-1 per sprintSame story carried 3+ sprintsPR cycle time<48 hours open to merge>72 hours consistentlyBug escape rate<10% of stories create bugsRising trendDeployment frequencyDaily to weeklyMonthly or lessSprint goal achievementYes/No binaryNo for 3+ consecutive sprints

Estimation Heuristic

When the team struggles with estimation: Certainty LevelApproach"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.

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: Focus on systems, not individuals "What" and "how," never "who" Everyone involved attends (including on-call who was paged) Schedule within 48 hours of resolution (memories fade) Write it up and share publicly within the engineering org Structure (60-90 min): Timeline review (20 min) — Walk through chronologically. Fill gaps. Root cause analysis (15 min) — "5 Whys" until you hit a systemic issue What went well (10 min) — Reinforce good incident response behaviors What went wrong (15 min) — Process failures, detection gaps, communication issues Action items (15 min) — Each must have an owner and due date. Max 5 items — focus beats volume.

On-Call Health Guidelines

MetricHealthyUnhealthyPages per week<5>10Off-hours pages<2/week>5/weekTime to acknowledge<5 min>15 minFalse positive rate<20%>50%Rotation size4+ people<3 peopleConsecutive weeks on-callNever >2Regular 3+ week stretches If on-call is unhealthy: This is a tech debt problem, not a people problem. Invest in reliability before adding headcount.

When to Split a Team

SignalActionTeam >8 peopleSplit before communication overhead kills velocityTwo distinct domains in one teamSplit along domain boundariesStandup takes >15 minToo many threads — people are tuning outPR review queue >48 hours consistentlyNot enough context overlap — specializeOn-call covers too many servicesReduce blast radius per team

Splitting Protocol

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

Manager-to-IC Ratio

Team SizeStructure3-5 ICsPlayer-coach (you're still coding ~30-40%)5-8 ICsFull-time manager (stop coding in critical path)8-12 ICsSplit the team OR add a tech lead as force multiplier12+ ICsMust 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.

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

DoDon'tBring solutions with problemsDump problems without proposalsFlag risks early with mitigation plansSurprise with bad news at the last minuteQuantify 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 helpSend written updates proactivelyWait to be asked for statusDisagree in privateDisagree in public meetingsAsk for feedback regularlyAssume 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"

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

Scenario: Two Senior Engineers Disagree on Architecture

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

Scenario: High Performer Wants to Be a Manager

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

Scenario: You Inherit a Low-Performing Team

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

Scenario: Layoffs / Reorg Affecting Your Team

Before announcement: Prepare a plan for remaining team — who covers what? During: Be honest about what you know and what you don't. "I don't know" > corporate-speak. After: 1:1 with every remaining person within 48 hours. Expect anger, fear, guilt. Ongoing: Workload audit — don't expect same output from fewer people. Push back on scope. 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

Same day: Have a real conversation. Not a counteroffer — understand why. If it's about money: Match or beat if they're worth it. If your company won't, that tells you something. If it's about growth/role: Can you create what they want? Be honest if you can't. If they're leaving for the right reasons: Celebrate them. Write a recommendation. Don't make it weird. Immediately: Start knowledge transfer plan. Identify what only they know. 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)

DimensionWeightIndicatorsTeam health20%Retention, engagement scores, psychological safety signalsDelivery20%Sprint completion, quality metrics, stakeholder satisfactionPeople development20%Promotions, skill growth, 1:1 quality, mentorshipTechnical stewardship15%Tech debt trajectory, architecture quality, incident trendsHiring10%Pipeline health, offer acceptance rate, new hire ramp timeCommunication10%Stakeholder relationships, information flow, no surprisesSelf-improvement5%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