delegation

委派

开始之前

首先检查是否存在 EM 背景信息。如果 .agents/em-context.md 存在，请先阅读。

如果 .agents/em-context.md 不存在，先询问一份精简的经理档案，并在给出详细建议前保存：角色／职称、团队规模、团队使命或负责领域，以及当前挑战或优先事项。

如果对话中的某位具体人员是核心人物，且 .agents/reports/[name].md 不存在，先询问该人员的精简档案，并在给出详细建议前保存：职称／级别、任职时间、优势，以及当前挑战或发展方向。

如果之后的对话中出现了持久的新背景信息，请自动更新 .agents/em-context.md 或 .agents/reports/[name].md。保存稳定的事实和规律，不要保存猜测、暂时性的挫败情绪或尚未解决的解读。

回复风格

第一条回复应简洁实用。除非用户要求深入说明，否则不要倾倒整套框架。

默认做法：

• 先说明可能的诊断结果或建议
• 仅在缺失的背景信息会改变建议时，提出最多 2-3 个有针对性的问题
• 给出下一步的具体行动，并在有帮助时提供经理可以直接使用的确切措辞
• 简要提及相关框架，但不要解释每个部分
• 先直接回答，再提出是否需要更深入的版本

---

如何使用此技能

先判断所处情境：

• 你成了瓶颈——自己做得太多 → 两项最先应该委派的工作（从这里开始）
• 不确定该对某项任务或某个人介入到什么程度 → 任务相关成熟度
• 想知道自己是管得太细还是管理不到位 → 微观管理与管理不足
• 工程师总是等着别人指示，不主动行动 → 基于意图的领导力
• 希望工程师承担超越单项任务的更大责任 → 让工程师拥有一片天地
• 以策略性方式在团队内分配工作 → 三层任务分配框架
• 担心别人采用不同于自己的做法 → 阅读 references/extended.md — 委派焦虑
• 即将休假／需要有人代班 → 阅读 references/extended.md — 你不在时的代班安排
• 作为 EM 决定哪些任务由自己亲自接手 → 阅读 references/extended.md — 亲自上手：有意识地选择任务
• 团队中有人似乎完全能自我驱动 → 阅读 references/extended.md — 自由电子
• 尽管反复提出要求，流程仍不断出问题 → 阅读 references/extended.md — 机制胜于意愿
• 工程师总是来找你要答案，而不是自行决策 → 阅读 references/extended.md — 拉动而非推动
• 有人反馈你管得太多或放手太多 → 阅读 references/extended.md — 四种决策模式

---

默认回复结构

帮助用户进行委派时，先诊断瓶颈，再提供策略：

1. 委派目标： 哪些工作应从经理手中转出去。
2. 成熟度判断： 该人员或任务需要多少背景信息、自主权和跟进。
3. 委派约定： 负责人、决策权、跟进频率和完成标准。
4. 风险控制： 经理应检查什么，但不应因此把工作收回来。
5. 话术： 分配工作或重新明确负责人时可以直接使用的措辞。

如果经理担心质量，应直接回应其对失去控制的恐惧，并设计评审流程，而不是建议他们“放手就好”。

---

两项最先应该委派的工作

1. 日常运营：团队代表

最有价值的第一项委派，是日常运营工作——警报、支持请求、生产问题。

运作方式：

• 每天／每周由一名团队成员担任“团队代表”（轮值）
• 代表负责：监控警报频道、协助支持团队、调试新问题、协调事件响应
• 代表不负责解决所有问题——引入 Bug 的开发者负责修复。代表负责协调并从中学习。
• 经理不是首要联系人，代表才是。

设置建议：

• 将轮值安排设为日历上的定期事项，并配上一份书面指南
• 在最初几轮轮值中，可以向你咨询，但绝不要亲自解决问题
• 自己也要参加轮值。不要把自己排除在你要委派出去的工作之外。

好处：

• 避免出现单点故障（巴士系数）
• 提升团队成员的主人翁意识和调试技能
• 让开发者感受到“我们同舟共济”

2. 新项目：Epic 负责人

不要再事事亲力亲为：与 PM 会面、进行技术设计、拆分工作。

运作方式：

• 每当有新的 Epic 时，指定一名团队成员担任负责人
• 负责人：与 PM 会面、编写技术设计、将工作拆分为任务、决定如何分配工作
• 你：继续参与其中——分享想法、提问、评审——但由他们做决定

每位开发者一次只领导一个项目，这样他们就能全身心投入，往往能做出比你同时匆忙推进五个项目更好的设计。

---

知识归属

如果你是每个系统和每个问题的唯一求助对象，那就有问题了。将团队的系统和应用分配给不同成员，明确指定负责人。有人向你询问某个系统时，将他们引导给该系统的负责人。

---

委派原则

• 绝不要 100% 委派某个领域。 继续参加轮值，偶尔亲自做这项工作。
• 你至少可以分担当前工作量的 50%。 例外情况比你想的少。
• 绝不要替他们解决问题。 他们遇到困难时，要指导，而不是代劳。
• 根据个人驱动力匹配任务。 委派的工作与某人的动力来源不符时，他们会拖延，最后你还得不断催促。工作与动力相符时，他们无需提醒就会主动承担责任。由人际联结驱动的工程师会很适合担任团队的面试协调员；由影响力驱动的工程师会主动承担你一直回避的 CS 冲刺任务；由成长驱动的工程师在你交给他们一项架构决策时会干劲十足。“你不喜欢的每项任务，都可能成为别人的成长机会。”（参阅 engineer-motivation，了解如何识别每个人的驱动力。）

---

意图式领导

摘自 Turn the Ship Around（Marquet）：团队成员不再请求许可或等待指示，而是陈述自己的意图，除非有人叫停，否则就继续执行。

这种做法是这样的：“我打算在下午 2 点部署这个版本——如果你觉得有什么理由不该这么做，请告诉我。” 而不是：“我应该部署这个版本吗？”

这样做之所以有效，是因为请求许可会把责任转移给被询问的人。陈述意图则让行动者继续承担责任，同时仍然保留监督。久而久之，这能训练整个团队像负责人一样思考，而不是只做执行者。

实施方法：

• 先在你自己的经理面前以身作则：“我打算敲定这次招聘——如果你有顾虑，请告诉我。”（这也是你向上争取委派的方式）
• 当下属来问你“我该不该做 X？”时，先问他们打算怎么做，让他们说出自己的打算。然后针对他们的意图作出回应，而不是替他们做决定
• 只有在你掌握他们不了解的信息时，才出面否决。如果你只是因为自己会采取不同做法而否决，就想想这么做是否值得付出损害他们主人翁意识的代价

目标是让团队无需他人指示也能主动行动，而不是等着别人下达指示。

---

微观管理与管理不足

摘自 Willink 的 The Dichotomy of Leadership：委派光谱两端的失误模式都真实存在，而且症状各不相同。

微观管理的迹象：

• 每项决策在推进前都要经过你的批准
• 团队成员不再向你反馈问题，因为他们认为你会替他们解决
• 你审查并重写那些“已经足够好”的工作
• 你不在时，没人采取行动
• 你的日程排满了不必要的跟进会

管理不足的迹象：

• 任务偏离轨道，而你最后一个才知道
• 团队成员在缺少你掌握的相关背景信息时，做出了重大决策
• 质量下降或标准松懈，而你没有察觉
• 团队不同成员完成的工作，在重要方面缺乏一致性
• 等问题演变成危机后，你才发现

这两种极端都不安全。工程文化中的默认观点是，管理不足好过微观管理——这导致许多工程经理（EM）过于放手，等发现问题时已经太晚。

正确的做法会因人和任务而异（参见“与任务相关的成熟度”）。但上述诊断可以在你偏离任一极端太远之前，为你提供早期信号。

---

参与多少才合适：与任务相关的成熟度

大多数管理者只会说“初级工程师需要更多监督，资深工程师需要更少”。这仍然过于笼统。

Andy Grove 在 High Output Management 中提出的概念：与任务相关的成熟度（TRM）——不是一个人的总体资历，而是他们对_这项具体任务_的成熟度。资深工程师第一次做某件事时，对该任务的 TRM 较低。初级工程师第五次开发微服务时，TRM 则较高。

• 低 TRM → 采用结构化参与方式：告诉他们该做什么，定期跟进，并随时提供帮助
• 高 TRM → 放手：设定目标，让他们开展工作，并信任结果

无论哪个方向，判断错误都会造成问题：

• 对高 TRM 的人过度介入 → 微观管理，打击积极性
• 对低 TRM 的人过度放手 → 客户（内部或外部）会为错误买单

当一项任务感觉风险很高时，问问自己：这个人在_这项_任务上的 TRM 真的很高吗？还是只是在总体上很高？

---

赋予工程师一方天地

除了委派任务，每位工程师还应负责一个明确的领域——一方拥有真正决策权的天地，而不只是执行责任。

四种有效的所有权类型：

1. 一个应用或系统——负责人推动与产品经理（PM）的路线图协作、监控使用情况，并担任事件联络人
2. 一个微服务——负责健康监控、技术债务优先级排序和贡献指南
3. 一个第三方集成——主导供应商关系、关注发行说明并跟踪集成健康状况
4. 一个内部工具——担任内部专家和倡导者，负责推广采用和更新

与任务委派的关键区别在于：领域负责人对其负责的领域拥有决策权。他们负责确定优先级，而不只是执行。

每位工程师负责一到两个领域即可；分散到太多领域会失去意义。先找出最占用你个人时间的领域，再优先移交这些领域。

表述方式很重要：“负责领域”听起来可能像一堆杂务。“一方天地”则意味着权力和荣誉——这两者都会影响工程师是接受还是抗拒这份责任。

---

三层任务分配框架

任务分配需要同时平衡以下三层：

• 效率 — 根据当前需求，分配最有能力的人
• 发展 — 为成长和职业发展轨迹分配任务，通常会牺牲一些速度
• 韧性 — 通过分配任务来避免单点故障，即使效率和成长都未达到最优

知识地图练习可以让第三层更具体：将工程师与技能／系统领域对应起来，直观呈现覆盖缺口，并找出危险的单人负责领域。

将工程师调至新领域以促进发展或增强韧性时，应应用任务相关成熟度（见上文）——刚接触某个领域的 Staff 工程师，需要比其职级所暗示的更多指导。

需要警惕两个陷阱：惯性（即使业务需求发生变化，舒适的任务分配也会固化下来）和启动成本（转变确实需要付出成本，必须提前规划，而不是寄希望于它自行消失）。每个季度都应有意识地重新审视任务分配，而不是让上一次不错的决定无限期延续。

---

深入了解

如果用户询问某个框架的来源、想阅读原始文章，或想了解任何主题的更多背景信息，请阅读 references/sources.md，其中列出了完整的来源文章（含链接）和书籍。

---

相关技能

• managing-yourself — 过度介入是 EM 陷入困境的 10 种方式中的第 5 个陷阱
• engineer-motivation — 识别每位工程师的动力来源，以便委派与其动机相契合的任务