Engineering Manager OS 工程经理操作系统你的完整工程领导手册。不是通用的管理建议——这是高效能工程经理日常运行的具体系统。

第一阶段：团队架构

团队拓扑评估

在管理人之前，了解他们工作的系统。

team_topology:
  name: "[团队名称]"
  type: stream-aligned | platform | enabling | complicated-subsystem
  mission: "[一句话——这个团队存在是为了做什么？]"
  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: "[其他团队]"
      mode: collaboration | x-as-a-service | facilitating
      friction: low | medium | high
      notes: "[什么工作/不工作]"
  current_headcount: N
  ideal_headcount: N
  skill_gaps: ["observability", "mobile", "ML"]

团队健康雷达（每月）

为每个维度打1-5分。随时间追踪趋势。

维度	分数	信号
交付速度	_ /5	我们是否交付了我们承诺的？
质量	_ /5	错误率，事故频率，技术债务轨迹
协作	_ /5	跨职能工作，PR审核速度，知识共享
士气	_ /5	会议中的能量，自愿贡献，留存信号
学习	_ /5	采纳的新技能，会议演讲，内部技术讲座
自主权	_ /5	团队能否在不等待我的情况下做出决策？
心理安全	_ /5	人们是否提出担忧，承认错误，挑战想法？
值班健康	_ /5	页面频率，非工作时间负担，倦怠信号

行动规则：

任何维度 ≤2 → 本周解决（这是火警）
任何维度为3 → 在2周内制定改进计划
总体平均 <3.5 → 团队正在挣扎，阻止新承诺直到修复
逐季度追踪——任何维度持续下降 = 系统性问题

团队组成模型

理想的团队有这些角色被覆盖（不一定是1:1与人对应）：

角色	描述	差距影响
技术领导	架构决策，代码质量标准	通过你决策瓶颈
高级IC (2-3)	承担复杂工作，指导初级	速度下降，质量受损
中级 (2-3)	可靠的交付，扩大范围	没有高级人才储备
初级 (0-2)	学习，新鲜视角	没有人才管道
领域专家	对问题空间有深入的了解	不断解决错误的问题

经验法则： 不要让团队超过60%的人处于同一水平。混合创造自然的指导。

第二阶段：1:1系统

1:1节奏

报告级别	频率	持续时间	焦点
直接报告	每周	30分钟	职业+阻碍+反馈
跳级	每月	30分钟	团队健康+职业+诚实检查
你的经理	每周	30分钟	优先事项+请求+空中掩护
跨职能同行	每两周	25分钟	依赖项+对齐

1:1模板（直接报告）

one_on_one:
  date: "YYYY-MM-DD"
  person: "[姓名]"
  role: "[头衔]"
  tenure: "[X个月在团队]"
  
  # 他们的议程首先 — 总是
  their_topics: []
  
  # 签到（2分钟）
  energy_level: 1-10  # "你这周对工作感觉如何？"
  energy_trend: up | stable | down
  
  # 交付（5分钟）
  current_work: "[他们正在做的工作]"
  blockers: []
  help_needed: "[我能解什么？]"
  
  # 成长（10分钟 — 如果紧急主题占主导，跳过，但绝不超过3周）
  career_conversation: "[讨论的主题]"
  feedback_given: "[具体行为 → 影响 → 请求]"
  feedback_received: "[他们告诉我的]"
  stretch_opportunity: "[当前或即将到来的]"
  
  # 行动项目
  my_actions: []  # 我承诺做的
  their_actions: []  # 他们承诺做的
  
  # 信号（私有 — 不要分享这些）
  flight_risk: low | medium | high
  performance_trajectory: improving | stable | declining
  notes: "[任何值得注意的]"

1:1问题库

开场（轮换这些 — 绝不要连续三周使用相同的开场白）：

“你在想什么？”
“这周最好/最坏的部分是什么？”
“如果你能改变我们工作的一件事，那会是什么？”
“这周有什么值得骄傲的事情我不知道的吗？”
“从1-10的量表来看，你的精力如何？什么能让这一点提高？”

职业发展（每月深入探讨）：

“两年后你想在哪里？这里和那里的差距是什么？”
“你有什么技能没有使用但想更多使用的？”
“组织中（或行业中）有谁的角色你想拥有？具体是什么？”
“你最近解决的最难的技术问题是什么？你学到了什么？”
“如果你明天离开，你会后悔没有在这里做什么？”

团队健康（谨慎探询）：

“你从团队中谁那里学得最多？最少？”
“有没有你不愿意审查的工作的人？”
“团队避免谈论什么？”
“如果你是我，你会改变这个团队的运作方式吗？”

反馈征求（针对您）：

“我有什么不同的做法会最帮助你？”
“我是不是给你太多方向或者太少？”
“有没有我没有分享的上下文会对你有帮助？”
“我上次让你沮丧是什么时候？发生了什么？”

飞行风险检测

监控这些信号 — 如果3+出现，请在一周内进行留存对话：

信号	权重	检测
LinkedIn个人资料更新	🔴 高	有人提到，或者你注意到
1:1参与度下降	🔴 高	简短的回答，减少眼神接触，“一切都好”
停止志愿参与项目	🟡 中	过去举手，现在不
增加无旅行的PTO	🟡 中	面试信号
在会议中不参与	🟡 中	相机关闭，多任务处理，无意见
抱怨从具体变为一般	🟡 中	“这个冲刺很艰难” → “这个地方…”
停止为他们的想法辩护	🔴 高	他们已经精神上签出了
生活事件（新生儿，搬家，伴侣变化）	🟡 中	重新评估一切

留存对话框架：

命名它：“我注意到[具体的行为变化]。我想检查一下。”
倾听：让他们说话。不要打断。不要防御。
理解：“什么会让这是你有过的最好的工作？”
行动：在48小时内做出具体承诺 — 头衔，薪酬，范围，灵活性
跟进：1周后再检查。你承诺的事情有区别吗？

第三阶段：绩效管理

绩效校准框架

在两个轴上评分（都重要）：

交付影响（什么）

级别	描述
1 - 低于	错过承诺，质量问题，需要密切监督
2 - 满足	可靠地交付分配的工作
3 - 超过	超出范围交付，找到更好的解决方案
4 - 杰出	增加团队产出，解决没有人要求他们解决的问题

行为（如何）

级别	描述
1 - 低于	创建摩擦，不合作，忽视反馈
2 - 满足	专业，协作，接受反馈
3 - 超过	指导他人，主动改进流程
4 - 杰出	塑造文化，吸引人才，提高整个标准

校准矩阵：

	行为1	行为2	行为3	行为4
交付4	教练行为	强	顶级表现者	超级巨星
交付3	教练行为	坚实	强	顶级表现者
交付2	PIP候选人	满足期望	发展中	成长中
交付1	退出	PIP	教练交付	教练交付

反馈框架：SBI-I（情境-行为-影响-意图）

模板： “在[situation]中，当你[specific behavior]时，影响是[concrete effect]。我想看到[specific change]，因为[intent/why it matters]。”

示例： ✅ 好：“在昨天的设计审查中，当你对API模式提出版本控制问题时，它捕获了我们将要发货的破坏性变更。这正是我想看到更多的技术领导力。”

❌ 坏：“你做得很好。继续。”（太模糊了 — 他们什么也学不到）

✅ 好：“在过去的两个冲刺中，PR已经在审查中停留了3天以上。影响是功能合并较晚，我们错过了冲刺承诺。我想我们承诺在<24小时内进行第一次审查，因为速度取决于审查速度。”

❌ 坏：“你需要更快地审查PR。”（没有情境，没有影响，没有合作）

绩效改进计划（PIP）模板

pip:
  employee: "[姓名]"
  role: "[头衔]"
  manager: "[你的名字]"
  start_date: "YYYY-MM-DD"
  end_date: "YYYY-MM-DD"  # 30-60天，绝不超过90
  
  context: |
    [具体的绩效不佳模式，带日期和例子。
     必须参考之前的反馈对话和发生日期。]
  
  expectations:
    - area: "[Specific skill/behavior]"
      current_state: "[现在发生了什么 — 带例子]"
      target_state: "[成功看起来像什么 — 可测量的]"
      measurement: "[我们如何衡量 — PR指标，冲刺完成等]"
      support: "[我会提供什么 — 配对，培训，减少范围]"
  
  check_ins:
    frequency: weekly
    day: "[Day]"
    format: "[30分钟1:1书面总结]"
  
  outcomes:
    success: "[如果目标达成 — 返回正常绩效管理]"
    failure: "[如果目标未达成 — 通常是终止]"
  
  # CRITICAL: Have HR review before sharing. Document every check-in.
  hr_reviewed: false
  hr_reviewer: "[姓名]"

PIP规则：

PIP永远不应该是惊喜 — 如果是，您在反馈方面失败了
PIP适用于能力差距，而不是态度问题（态度 = 更快地管理出去）
70%的PIP以终止结束 — 对自己诚实，这是否是发展工具还是文档练习
每周检查是不可谈判的 — 书面记录一切
如果绩效在PIP期间提高然后在之后下降：第二次PIP很少值得

晋升案例模板

promotion_case:
  candidate: "[姓名]"
  current_level: "[级别]"
  target_level: "[级别]"
  manager: "[你的名字]"
  date: "YYYY-MM-DD"
  
  # 已经在下一个级别运营（过去6个月+）
  evidence:
    - dimension: "Technical complexity"
      examples:
        - "[具体项目/决策，可衡量的影响]"
        - "[另一个例子]"
    - dimension: "Scope & ownership"
      examples:
        - "[拥有X端到端，以前需要指导]"
    - dimension: "Influence & leadership"
      examples:
        - "[指导Y，领导Z倡议，塑造团队方向]"
    - dimension: "Business impact"
      examples:
        - "[收入/效率/可靠性改进，带数字]"
  
  peer_feedback:
    - from: "[姓名，角色]"
      quote: "[具体表扬，带例子]"
  
  # 为什么现在，而不是6个月后？
  timing_justification: |
    [他们已经连续在下一个级别运营X个月。
     延迟创建留存风险，并向团队发送错误的信号。]
  
  # 有什么差距？（要诚实 — 校准委员会会找到它）
  growth_areas: |
    [他们仍在发展的领域。将其框架为"成长进入"而不是"缺乏"。]

第四阶段：招聘机器

招聘管道

角色开放 → 职位描述 → 寻找（5-7天）
→ 简历筛选 → 招聘人员筛选（30分钟）
→ 技术电话筛选（60分钟） → 带回家或现场编码（2-4小时）
→ 现场/虚拟循环（3-4小时） → 简报 → 报价 → 关闭

目标：从第一次筛选到报价<21天

职位描述模板

# [职位名称] — [团队名称]

## 你将做什么
[3-5个实际工作的要点，不是通用责任]
- 发布[特定功能/系统]，[特定影响]
- 拥有[特定领域]端到端
- [这个人最近会解决的具体问题的例子]

## 你将需要
[只有必须有的 — 每一个都必须是真正的过滤器]
- X年构建[特定技术/领域]
- 有[特定技术要求]的经验
- [真正区分候选人的技能]

## 锦上添花（真正好，不是秘密需要）
- [会加速入职的东西]
- [增加价值的相邻技能]

## 我们提供
[具体 — "有竞争力的薪水"没有意义]
- 薪资范围：$X-$Y（基于[位置/级别]）
- [对工程师重要的具体福利]
- [团队/文化的事情，实际上是真实的，区别于其他]

## 我们如何招聘
[时间线和预期 — 尊重他们的时间]
1. [步骤]：[持续时间] — [我们正在评估什么]
2. [步骤]：[持续时间] — [我们正在评估什么]
总投资时间：~X小时

面试评分卡（每位面试官）

scorecard:
  candidate: "[姓名]"
  interviewer: "[姓名]"
  interview_type: "technical | system design | behavioral | culture"
  date: "YYYY-MM-DD"
  
  # 每个维度1-4分（不允许3 — 迫使做出决定）
  dimensions:
    - name: "Technical depth"
      score: _  # 1=不雇佣，2=倾向于不，4=倾向于是，5=强烈是（跳过3）
      evidence: "[面试中的具体例子]"
    - name: "Problem solving approach"
      score: _
      evidence: "[他们如何分解问题，处理提示]"
    - name: "Communication clarity"
      score: _
      evidence: "[他们能解释他们的想法吗？他们问好问题了吗？]"
    - name: "Collaboration signals"
      score: _
      evidence: "[他们如何应对反驳？他们是否建立在想法上？]"
  
  # 总体
  hire_recommendation: strong_no | no | yes | strong_yes
  level_recommendation: "[你会把他们放在什么级别？]"
  concerns: "[让你犹豫的任何事情]"
  highlights: "[给你印象最深的是什么]"

简报协议

无预先讨论 — 在简报会议之前提交评分卡
保持招聘标准的人最后发言 — 防止锚定
讨论每个维度，而不是总体氛围 — “告诉我他们的系统设计方法"而不是"你怎么看？”
任何strong_no是否决 — 除非面试官可以被说服他们的信号被误读
在房间里决定 — 不要"睡在上面"除非真的犹豫不决（那么可能是不）
在报价之前确定级别 — 首先同意级别，然后补偿遵循乐队

关闭候选人

关闭工程师的3件事：

问题 — “这里有你将工作的特定难题”
人 — 在报价之前将他们与未来的队友联系起来
成长 — “这个角色在18个月内会带你去哪里”

报价电话结构（15-20分钟）：

真诚地表达兴奋（2分钟）
提供报价细节 — 基础，股权，奖金，开始日期（3分钟）
解释股权/补偿理念（3分钟）
问：“这与你预期的相比如何？”（倾听）
如果可能，立即解决顾虑
设置决策期限（3-5个工作日，不开放）
问：“有什么会让它成为一个明确的是吗？”

第五阶段：技术领导力

架构决策记录（ADR）

adr:
  id: "ADR-NNN"
  title: "[决策标题]"
  date: "YYYY-MM-DD"
  status: proposed | accepted | deprecated | superseded
  superseded_by: "ADR-NNN"  # 如适用
  
  context: |
    [我们处于什么情况？有什么力量在起作用？
     包括约束：时间表，团队技能，预算，规模要求。]
  
  options:
    - name: "[选项A]"
      pros: ["pro 1", "pro 2"]
      cons: ["con 1", "con 2"]
      effort: "[T-shirt size]"
      risk: low | medium | high
    - name: "[选项B]"
      pros: ["pro 1"]
      cons: ["con 1", "con 2", "con 3"]
      effort: "[T-shirt size]"
      risk: low | medium | high
  
  decision: |
    [我们决定的和为什么。"为什么"是最重要的部分。
     未来的读者需要理解推理，而不仅仅是选择。]
  
  consequences: |
    [这个决定的后果是什么？什么变得更容易/更难？
     我们需要监控什么？]
  
  review_date: "YYYY-MM-DD"  # 何时重新审视这个决定

技术债务优先级

每个债务项目在两个轴上评分：

修复影响（1-5）：

5：解除多个团队或关键功能的阻塞
4：对我们的团队有显著的速度提升
3：适度改进，防止未来问题
2：最好有，轻微改进
1：化妆品或理论上的好处

不修复的成本（1-5）：

5：将导致事件或数据丢失
4：阻止招聘/入职（无法解释代码）
3：减慢每个功能超过20%
2：偶尔的摩擦，存在变通方法
1：烦人但无害

优先级 = 影响 × 不修复的成本

分数	行动
20-25	这个冲刺修复 — 它是紧急情况
12-19	在2个冲刺内安排
6-11	添加到季度技术债务预算（分配15-20%的冲刺容量）
1-5	积压 — 每季度重新审视

代码审查文化指南

code_review_standards:
  sla:
    first_review: "< 4小时工作时间内"
    follow_up: "< 2小时"
    max_pr_size: 400  # 行更改 — 更大的需要预先审查或分割
  
  what_to_review:
    always:
      - "正确性 — 它是否做到了它所声称的？"
      - "边缘情况 — nil/empty/max/concurrent时会发生什么？"
      - "安全性 — 认证检查，输入验证，秘密暴露"
      - "命名 — 6个月后有人会理解这个吗？"
    sometimes:
      - "性能 — 只有在热路径或O(n²)+风险时"
      - "风格 — 只有当它显著影响可读性时"
    never:
      - "伪装成改进的个人偏好"
      - "过早优化建议"
      - "重写为您风格的工作代码"
  
  tone_rules:
    - "提问而不是下命令：'如果X为nil怎么办？'而不是'处理nil案例'"
    - "用'nit:'或'optional:'前缀意见 — 明确严重性"
    - "赞扬好代码 — '这里有很好的抽象'不需要花费任何东西"
    - "如果>5个评论，提供配对而不是"
    - "如果有评论，批准时没有阻碍 — 信任你的团队"

第六阶段：冲刺与交付

冲刺仪式备忘录

仪式	持续时间	谁	目的	你的角色
冲刺计划	1-2小时	团队+PO	承诺冲刺目标	促进，挑战估计，保护容量
每日站立	15分钟	团队	表面阻碍	倾听问题，不要管理任务
待办事项细化	1小时	团队+PO	准备未来的工作	确保技术可行性，标记风险
冲刺回顾	30分钟	团队+利益相关者	演示工作软件	让团队展示，处理利益相关者问题
回顾	1小时	团队	改进过程	促进，确保心理安全，跟踪行动

冲刺健康指标

每周跟踪这些 — 趋势比绝对数字更重要：

指标	健康范围	红旗
冲刺完成率	80-100%的承诺点数	2+冲刺<70%
待办事项延续	每个冲刺0-1	同一个故事连续3个冲刺
PR周期时间	<48小时开放到合并	一致>72小时
错误逃逸率	<10%的故事创建错误	上升趋势
部署频率	每天到每周	每月或更少
冲刺目标实现	是/否二进制	连续3个冲刺没有

估计启发式

当团队在估计上挣扎时：

确定性水平	方法
“我们已经做过这个确切的事情”	与过去的工作比较大小
“我们理解问题但不了解解决方案”	首先进行突击（有时间限制），然后估计
“我们不完全理解问题”	发现任务（1-2天），然后重新调整范围
“我们一点都不知道”	将其分解，直到你能达到可以估计的部分

规则： 如果估计>8点（或>5天），它不是估计 — 这是一个猜测。进一步分解。

第七阶段：事件管理

事件响应框架

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: "[姓名]"
  
  # 严重性指南
  # SEV1：收入影响，数据丢失，完全中断 — 所有人，高管通知
  # SEV2：降级服务，部分中断 — 在职+团队领导
  # SEV3：轻微降级，存在变通方法 — 在职处理
  # SEV4：化妆品，无用户影响 — 正常票务
  
  timeline:
    - time: "HH:MM"
      action: "[发生了什么/做了什么]"
      who: "[姓名]"
  
  root_cause: |
    [技术根本原因 — 要具体。
     "人为错误"从来不是根本原因。什么系统允许错误？]
  
  contributing_factors:
    - "[因素1 — 例如，X上缺少监控]"
    - "[因素2 — 例如，高峰期间部署没有功能标志]"
  
  action_items:
    - description: "[具体修复]"
      owner: "[姓名]"
      due_date: "YYYY-MM-DD"
      priority: P0 | P1 | P2
      status: open | in_progress | done

无责任事后分析模板

促进规则：

专注于系统，而不是个人
“什么"和"如何”，从来不是"谁"
所有相关人员参加（包括被呼叫的在职人员）
在解决后48小时内安排（记忆消退）
写下来并在工程组织内公开分享

结构（60-90分钟）：

时间线审查（20分钟） — 按时间顺序走过。填补空白。
根本原因分析（15分钟） — "5个为什么"直到你遇到系统问题
进展顺利（10分钟） — 加强良好的事件响应行为
出了什么问题（15分钟） — 流程失败，检测差距，沟通问题
行动项目（15分钟） — 每个必须有一个所有者和截止日期。最多5项 — 专注胜过数量。

值班健康指南

指标	健康	不健康
每周页面	<5	>10
非工作时间页面	<2/周	>5/周
确认时间	<5分钟	>15分钟
误报率	<20%	>50%
轮换大小	4+人	<3人
连续值班周数	绝不>2	常规3+周

如果值班不健康： 这是技术债务问题，不是人的问题。在增加人手之前投资可靠性。

第八阶段：扩展与组织设计

何时拆分团队

信号	行动
团队>8人	在沟通开销杀死速度之前拆分
一个团队中有两个不同的领域	沿领域边界拆分
站立会议>15分钟	太多线程 — 人们正在调出
PR审查队列>48小时一致	不够上下文重叠 — 专业化
值班覆盖太多服务	减少每个团队的爆炸半径

分裂协议

明确定义边界 — 每个新团队OWN什么？写下来。
拆分待办事项 — 每个票都有一个家。共享待办事项 = 共享所有权 = 没有所有权。
拆分值班 — 每个团队拥有其服务的可靠性。
命名团队 — 听起来微不足道，对身份很重要。
指定技术领导 — 不要让两个团队都指望你做技术决策。
给它3个月 — 抵制重新组织的冲动。动荡是正常的。

经理到IC比例

团队大小	结构
3-5 ICs	球员教练（你仍然编码约30-40%）
5-8 ICs	全职经理（停止在关键路径上编码）
8-12 ICs	分拆团队或添加技术领导作为力量倍增器
12+ ICs	必须拆分 — 你不能有效地管理这个

IC到经理过渡

如果你最近管理（或指导某人经历）：

停止做：

在关键路径上编写代码（你现在是瓶颈）
自己解决每一个技术问题
成为团队中最好的工程师（你的工作变了）

开始做：

问"谁应该拥有这个？"而不是自己做
通过团队产出衡量成功，而不是你自己的产出
尽早进行不舒服的对话（反馈，绩效，冲突）
阻止时间进行思考，不仅仅是会议

继续做：

保持足够技术以评估决策（阅读代码，审查设计）
在副项目，工具或原型上编码（保持敏锐）
拥有强烈的技术意见（但持有它们松散）

能力时间表：

月份1-3：冒名顶替综合症，一切都感觉慢。正常。
月份3-6：找到你的节奏，一些胜利，一些失败。正常。
月份6-12：在角色中自信，建立系统。目标。
月份12+：增加影响力。如果你在18个月还没有到这里，需要进行诚实的对话。

第九阶段：沟通与利益相关者管理

每周状态更新模板

每周五向你的经理和利益相关者发送这个：

# [团队名称] — [日期]周

## 🎯 冲刺目标：[目标] — 正在轨道上/有风险/偏离轨道

## ✅ 本周发货
- [功能/修复] — [以用户/业务术语影响]
- [功能/修复] — [影响]

## 🔨 进行中
- [工作项] — [状态，ETA，任何阻碍]

## 🚨 风险与阻碍
- [风险] — [你正在做什么，你需要什么]

## 📊 关键指标
- 部署频率：X
- 事件计数：X（SEV分解）
- 冲刺完成：X%

## 🔮 下周
- [优先级1]
- [优先级2]

管理上级清单

做	不做
带着问题带来解决方案	没有提案地倾销问题
提前标记风险和缓解计划	在最后一刻用坏消息惊喜
量化影响（小时，$$，用户）	使用模糊的语言（“它有点慢”）
说"我需要X从你那里到Y"	希望他们能自己弄清楚你需要帮助
主动发送书面更新	等待被要求状态
私下不同意	在公共会议上不同意
定期寻求反馈	假设没有消息就是好消息

跨职能关系图

stakeholders:
  - name: "[产品经理]"
    relationship: partner
    cadence: "每日异步+每周1:1"
    currency: "范围清晰，用户数据，优先事项决策"
    
  - name: "[设计领导]"
    relationship: partner
    cadence: "每两周同步+临时"
    currency: "早期技术可行性输入"
    
  - name: "[平台/基础设施团队]"
    relationship: dependency
    cadence: "每月同步+Slack"
    currency: "明确要求，提前通知需求"
    
  - name: "[你的经理]"
    relationship: air_cover
    cadence: "每周1:1"
    currency: "没有惊喜，明确要求，好判断"

第十阶段：工程经理仪式

每日（15分钟总计）

[ ] 扫描Slack/电子邮件以获取阻碍 — 在站立会议之前解除阻塞
[ ] 参加站立会议 — 倾听模式，而不是任务更新
[ ] 检查PR队列 — 推动任何>24小时的审查
[ ] 向某人提供一条反馈（正面或建设性）

每周

[ ] 完成所有1:1（绝不取消 — 如果需要，重新安排）
[ ] 审查冲刺指标
[ ] 向利益相关者发送状态更新
[ ] 日历审计 — 我是否在不应该参加的会议中？
[ ] 一次跳级或跨职能对话

每月

[ ] 更新团队健康雷达
[ ] 与每个报告进行职业发展对话
[ ] 审查和优先级技术债务
[ ] 审查值班健康
[ ] 更新团队拓扑文档

每季度

[ ] 绩效校准（正式或非正式）
[ ] 审查和重置团队目标
[ ] 架构审查 — 有任何ADR需要重新审视？
[ ] 人员规划 — 6个月后需要什么？
[ ] 反思你的绩效 — 向你的团队寻求反馈

第十一阶段：困难情况剧本

场景：两位高级工程师在架构上意见不一

让他们在设计文档中呈现两种方法（各自编写自己的部分）
在评估之前定义决策标准：可逆性，维护成本，团队熟悉度，时间表
促进时间限制的讨论（最多60分钟）
如果没有共识：技术领导或DRI决定。不是你（除非你必须）。
将决策记录为ADR — "为什么"比"什么"更重要
"输了"的人必须全力以赴。监控被动阻力。

场景：表现优异者想成为经理

探索动机：“告诉我你认为经理每天都在做什么”
用真实工作测试：领导一个项目，指导一个初级，运行一个回顾
对权衡诚实：编码更少，会议更多，反馈循环更慢，成功指标模糊
提供Staff/Principal IC路径作为一个真正的替代方案，而不是安慰奖
如果他们继续：设置明确的3个月检查 — “这是你想要的吗？”

场景：你继承了一个表现不佳的团队

第1-2周： 倾听。与每个人1:1。现在不要改变任何东西。
第3-4周： 确定1-2个系统性问题（通常是：不清晰的优先事项，没有问责制，或信任赤字）
第2个月： 只做一个流程变更。快速获胜。建立信誉。
第3个月： 处理你现在已经亲眼目睹的性能问题
绝不： 公开指责前经理。绝不说"事情将在这里改变"。

场景：裁员/重组影响你的团队

公告前： 为剩余团队准备一个计划 — 谁覆盖什么？
期间： 对你所知道的和你不知道的要诚实。“我不知道” > 公司话。
之后： 在48小时内与每个剩余的人进行1:1。预计会有愤怒，恐惧，内疚。
持续： 工作量审计 — 不要指望少数人有相同的产出。推动范围。
自我照顾： 这是工作中最难的部分之一。与你自己的经理或教练交谈。

场景：你最好的工程师辞职

同一天： 进行真正的对话。不是一个反要约 — 了解为什么。
如果是因为钱： 如果他们值得，匹配或击败。如果你的公司不愿意，那告诉你一些事情。
如果是因为成长/角色： 你能创造他们想要的吗？如果你不能，要诚实。
如果他们因为正确的原因离开： 庆祝他们。写推荐信。不要让它变得奇怪。
立即： 开始知识转移计划。确定只有他们知道的东西。
对团队： 透明但积极。“X正在离开一个伟大的机会。这是我们的过渡计划。”

评分标准：工程经理效能（0-100）

维度	权重	指标
团队健康	20%	留存，参与度得分，心理安全信号
交付	20%	冲刺完成，质量指标，利益相关者满意度
人员发展	20%	晋升，技能增长，1:1质量，指导
技术管理	15%	技术债务轨迹，架构质量，事件趋势
招聘	10%	管道健康，报价接受率，新员工入职时间
沟通	10%	利益相关者关系，信息流动，没有惊喜
自我提升	5%	寻求反馈，适应，作为领导者成长

评分：

90-100：卓越 — 团队繁荣，人员成长，可靠发货
75-89：强 — 大多数事情工作，一些领域发展
60-74：发展 — 基础技能存在，需要指导
40-59：挣扎 — 重大差距，失去团队信任的风险
<40：需要干预 — 指导，角色变化，或过渡

自然语言命令

“准备与[name]的1:1” → 根据最近的上下文生成议程
“为[name]撰写绩效评估” → 使用框架进行校准和起草
“为[role]创建职位描述” → 使用模板生成
“运行团队健康检查” → 走过雷达维度
“为[decision]起草ADR” → 结构化架构决策
“为[incident]进行事件事后分析” → 生成事后分析模板
“冲刺健康报告” → 分析指标并标记问题
“为[name]制定晋升案例” → 构建基于证据的晋升文件
“评估技术债务[item]” → 使用优先级矩阵进行评分
“进行飞行风险评估” → 审查每个团队成员的信号
“向利益相关者更新” → 根据上下文生成每周状态
“为[candidate]进行面试评分卡” → 创建结构化评估