什么是 工程经理操作系统 (Engineering Manager OS)？

工程经理操作系统（Engineering Manager OS）是专为从个人贡献者转向管理及总监级别岗位的工程领导者设计的专业级指南。它为处理现代工程管理的复杂性提供了一套结构化系统，包括团队拓扑评估、绩效校准和组织设计。通过利用这些 Openclaw 技能，领导者可以摆脱泛泛而谈的建议，实施具体的、数据驱动的工作流程。

该系统围绕可操作的模板和评分标准构建，涵盖了高效团队的整个生命周期。无论您是在管理技术债、进行越级会议，还是应对关键系统事故，此技能都能提供必要的结构，确保在快节奏的软件工程领导工作中不会忽略任何细节。

下载入口:https://github.com/openclaw/skills/tree/main/skills/1kalin/afrexai-engineering-manager

安装与下载

1. ClawHub CLI

从源直接安装技能的最快方式。

2. 手动安装

将技能文件夹复制到以下位置之一

优先级：工作区 > 本地 > 内置

3. 提示词安装

将此提示词复制到 OpenClaw 即可自动安装。

工程经理操作系统 (Engineering Manager OS) 应用场景

• 运行具有自动议程生成和流失风险检测功能的高影响力 1:1 会议。
• 从心理安全感、交付速度和值班负担等维度评估团队健康状况。
• 使用 SBI-I（情境-行为-影响-意图）框架和 PIP 模板校准绩效。
• 通过结构化 ADR 和技术债优先级矩阵管理架构决策。
• 利用职位描述模板和非锚定汇报协议构建可扩展的招聘机器。

1. 系统首先进行团队拓扑评估，以了解服务所有权和认知负荷边界。
2. 经理使用 YAML 模板实施标准化的 1:1 节奏，追踪能量趋势和职业成长话题。
3. 绩效管理通过聚焦交付影响和文化行为的双轴校准矩阵进行。
4. 技术领导力通过架构决策和冲刺健康指标的标准化文档来强化。
5. 组织扩展通过团队拆分和经理与 IC 比例坚控的定义协议进行管理。

工程经理操作系统 (Engineering Manager OS) 配置指南

要在本地工作流或 AI 代理环境中部署此管理系统，请按照以下步骤操作：

# 进入您的管理工作区
cd ~/management-docs

# 初始化工程经理操作系统结构
npx openclaw-cli install engineering-manager-os

# 生成您的首份团队健康雷达图
openclaw run "generate team health radar --team 'Platform Engineering'"

工程经理操作系统 (Engineering Manager OS) 数据架构与分类体系

工程经理操作系统将领导力数据组织为多个关键 Schema，以确保在 Openclaw Skills 中的一致性和可搜索性：

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.

Action rules:

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

Team Composition Model

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

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

Phase 2: 1:1 System

1:1 Cadence

1:1 Template (Direct Reports)

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

1:1 Question Bank

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

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

Career development (monthly deep-dive):

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

Team health (probe with care):

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

Feedback solicitation (for YOU):

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

Flight Risk Detection

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

Retention conversation framework:

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

Phase 3: Performance Management

Performance Calibration Framework

Rate on two axes (both matter):

Delivery Impact (What)

Behaviors (How)

Calibration matrix:

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

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

Examples:

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

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

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

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

Performance Improvement Plan (PIP) Template

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

PIP rules:

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

Promotion Case Template

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

Phase 4: Hiring Machine

Hiring Pipeline

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

Target: <21 days from first screen to offer

Job Description Template

# [Role Title] — [Team Name]

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

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

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

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

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

Interview Scorecard (Per Interviewer)

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

Debrief Protocol

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

Closing Candidates

The 3 things that close engineers:

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

Offer call structure (15-20 min):

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

Phase 5: Technical Leadership

Architecture Decision Record (ADR)

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

Tech Debt Prioritization

Score each debt item on two axes:

Impact of fixing (1-5):

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

Cost of NOT fixing (1-5):

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

Priority = Impact × Cost-of-not-fixing

Code Review Culture Guidelines

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

Phase 6: Sprint & Delivery

Sprint Ceremony Cheat Sheet

Sprint Health Metrics

Track these weekly — trend matters more than absolute numbers:

Estimation Heuristic

When the team struggles with estimation:

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

Phase 7: Incident Management

Incident Response Framework

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

Blameless Post-Mortem Template

Facilitation rules:

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

Structure (60-90 min):

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

On-Call Health Guidelines

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

Phase 8: Scaling & Org Design

When to Split a Team

Splitting Protocol

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

Manager-to-IC Ratio

The IC-to-Manager Transition

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

Stop doing:

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

Start doing:

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

Keep doing:

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

Timeline to competence:

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

Phase 9: Communication & Stakeholder Management

Weekly Status Update Template

Send this to your manager and stakeholders every Friday:

# [Team Name] — Week of [Date]

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

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

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

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

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

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

Managing Up Checklist

Cross-Functional Relationship Map

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

Phase 10: Engineering Manager Rituals

Daily (15 min total)

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

Weekly

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

Monthly

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

Quarterly

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

Phase 11: Difficult Situations Playbook

Scenario: Two Senior Engineers Disagree on Architecture

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

Scenario: High Performer Wants to Be a Manager

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

Scenario: You Inherit a Low-Performing Team

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

Scenario: Layoffs / Reorg Affecting Your Team

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

Scenario: Your Best Engineer Gives Notice

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

Scoring Rubric: Engineering Manager Effectiveness (0-100)

Scoring:

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

Natural Language Commands

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