本文改编自我为 Anthropic 写的一份内部文档。
最近我进行了很多关于「如何搭建团队、如何配备人手」的讨论。我反复引用的一个框架，是把团队领导拆成几类不同的职责。
这之所以有用，有几个原因。其一，它帮你更具体地理解「带团队」到底包含什么；对新任管理者来说，有一份详尽的职责清单，有助于确保自己没有遗漏任何一项。
但更重要的是，我们常常希望把这些职责在多人之间拆分。团队领导涵盖的范围极广——从这篇文章的长度你就能看出来——而想找到一个人在所有这些方面都很出色，往往是在猎杀独角兽。即便你找到了一个各方面都「够用」的人，他们也通常在 1–2 个领域特别突出，让他们全力聚焦那些领域，撬动的杠杆反而更高。
下面是我常用的一个拆解框架。1
分类
总体方向
团队领导最重要的职责，是确保团队正朝着正确的方向前进——也就是说，他们是否在朝正确的顶层目标努力，是否有实现它的可行计划。总体方向往往会收到团队内外的许多输入，但谁对它负最终责任可以有所不同（见下文「职责划分的实例」）。
总体方向涉及的工作包括：
- 设定团队的使命、愿景或章程
- 选择团队的目标、计划和路线图
- 在团队可能承接的诸多项目中排优先级
- 把以上内容传达给团队成员和外部人士
做好这件事最重要的技能，是拥有良好的预测模型（既针对团队所在的领域，也针对整个组织）——因为排优先级归根结底是问「如果我们做这个项目，会有什么影响」。此外，把这些预测模型、以及团队的优先级和目标清晰地传达给其他干系人，也很重要。
好的团队方向，大体表现为团队持续产出一连串大胜仗。糟糕的方向最常见的表现是「被打个措手不及」或「掉队」——即误判了哪些工作最重要、做得太少，例如起步太晚、招人不足，或没有把人培养到合适的技能或角色。糟糕方向的其他信号包括：团队成员不理解自己为什么在做某件事；团队在做价值极低的项目；与兄弟团队发生摩擦或就职责范围争吵；或者重要项目在团队之间的缝隙里被漏掉。
人员管理
人员管理意味着对团队里的人的成长负责，通常包括：
- 辅导人们改进、在职业上成长
- 为团队设计并监督招聘流程
- 设定并传达绩效期望，并据此评估
日常层面，这里最重要的职责是定期的一对一沟通（是辅导型的那种，不是进度汇报型的那种）。其他还包括写职位描述、搭建面试流程、寻找候选人、收集反馈、写绩效评估、帮人应对组织政策、提供职业辅导等等。
人员管理最重要的技能是「理解人」——既包括传统的「高情商」意义（有同理心、善于站在他人角度看问题），也包括「知道一个领域里什么造就高绩效」的意义（比如什么造就一名优秀的工程师或研究员）。同样重要的是，要擅长以富有同情心但坚定的方式进行棘手的谈话。
人员管理的主要产出，是团队里的人是否高效且快乐。人员管理最好的团队，招到优秀的人，对任何不奏效的地方快速给予反馈，迅速纠偏，帮助他们随时间提升影响力，并总体上让他们在工作中有愉快的体验。糟糕的人员管理，表现为人们长期表现不佳或士气低落。
这里一个常见的问题是：人员管理者需要多懂技术？意见分歧很大。我通常建议的底线是：人员管理者不必拥有团队里最深的技术功底，但需要有足够的功底，能跟上大多数讨论而不拖慢节奏，能在多数争论中不必依赖信任就知道谁是对的，并且总体上能轻松保持方向感。
人员管理者负责确保下属在需要时得到指导和反馈，但他们不必自己就是提供指导或反馈的主要人。通常，领域专属的指导来自负责技术方向的人，但也可能来自团队里其他资深的成员，少数情况下来自组织里的其他地方。
项目管理
项目管理意味着确保团队执行得好：即每个人都在高效地朝着团队的顶级优先级努力，同时不被阻塞、并对周围发生的事保持感知。短期来看，它是团队生产力的关键决定因素。
日常层面，项目管理表现为：
- 设定并运转团队的「运作节奏」，即一套帮助完成工作的固定会议/仪式（站会、规划/排优先级会议、回顾会等）
- 搞清如何在团队里拆分工作，把它委派给相应的人，并监控进度确保不被阻塞
- 通过让工作可见来保持团队的方向感，比如整理好 Slack 频道、维护任务跟踪器等
- 作为团队与公司其他部门之间的联络点——来回传达重要更新等
项目管理不只是行政性的；做好它需要相当多的领域专业知识（才能跟上项目讨论、理解状态更新、跟踪依赖等）。除此之外，有条理、注重细节有帮助，还需要对人有良好的心智模型（谁擅长哪类工作？什么样的协调仪式对这个团队有用？）。
好的项目管理几乎不可见——感觉就像「事情在顺滑地运转」。它出问题时反而更显眼，主要表现为低效的工作：有人被阻塞、因为优先级来回摇摆而频繁切换上下文、因为被派去做不适合自己的项目而瞎折腾、因为不理解根本目标而做错事、因为重要信息发在了错误的 Slack 频道而错过，等等。
团队变大后，项目管理是最容易委派和拆分的领域之一。例如，当 Anthropic 的推理团队达到 10 人以上时，我们把它拆成多个专注于不同领域的「小组」，每个小组有一个「小组长」负责该小组的项目管理。
技术领导
技术领导意味着对团队技术工作的质量负责。在整合多种技术技能的复杂组织里，你可以认为团队常常在每个技能方向都需要一定量的技术领导——例如，Anthropic 的研究团队既需要研究领导，也需要工程领导，尽管具体配比因团队而异。
具体工作包括：
- 设定技术方向（例如某课题的研究议程，或某系统的架构）
- 对照该方向评审执行情况（评审实验设计与结果、技术设计文档、代码评审等）
- 对团队里的独立贡献者进行其他技术辅导，例如一对一、结对等
- 常常还有一定量的亲自执行，尽管这取决于技术负责人有多忙
由于技术领导从「亲自动手执行」所带来的详细上下文和反馈回路中获益良多，技术负责人由独立贡献者担任相当常见。2 在实践中，许多团队的覆盖面足够广，最终会在不同领域有多个技术负责人——要么按项目「纵向」拆分，要么按技能「横向」拆分，要么两者结合。
也许显而易见，技术负责人最重要的技能是领域专业知识。技术沟通大概是第二重要的，也是这一「资深独立贡献者」原型区别于他人的地方。
技术领导出问题时，最常见的表现是债台高筑或其他拖慢执行的摩擦：站不住脚的研究结果、无信息量的实验、吱呀作响的系统、频繁的故障等。
职责划分的实例
下面是一些现实世界中如何划分这些职责的例子。3
「技术负责人型经理」（TLM）
当一家新公司引入第一批技术管理者时，他们常常把最强的技术人才（一个或几个）提拔到管理岗位，并指望他们履行全部四项职责。有些人在这种角色里做得挺好，但更常见的是，新任管理者在一项或多项职责上并不擅长——最常是人员管理——并且由于还担着其他一堆事而难以改进。（延伸阅读：《Tech Lead Management 角色是个陷阱》）
尽管 TLM 角色有一些坑，但并非不可能成功。下面几个保护性因素能提高成功率：
- 团队小或压力低，让他们有更多时间专注自己的成长短板
- TLM 有一位高度投入的「经理的经理」，能在需要处给予支持
- 团队所在领域足够简单，或独立贡献者足够资深，使技术监督的需求有限
- TLM 在技术领导和人员管理两方面都有很强的既往经验
- TLM 愿意长时间工作（当然，这是描述性的，不是规范性的）
工程经理 / 技术负责人
这种拆分在较大的科技公司很常见：工程经理（EM）负责总体方向、人员与项目管理，技术负责人（TL）负责技术领导（并可能也为总体方向出力）。「技术负责人」在这里不必是正式头衔，有时一个团队在不同领域会有多个技术负责人。
在 Anthropic，我们的推理团队是一个好例子：那里的经理自己并不怎么设定技术方向，而是专注于招聘、组织、辅导、确立优先级，以及充当团队与众多客户团队之间的「胶水」。由于该领域高度复杂、团队又资深扎堆，技术领导由多位不同的独立贡献者分别为服务（模型实现、服务器架构、请求调度、容量管理等）的不同部分来提供。
产品经理 / 技术负责人
这是一个较不常见的拆分例子。在 Wave，我们用的划分方式类似上面描述的 EM/TL 拆分，但团队经理（我们称之为产品经理，虽然它是个略显非典型的 PM 角色）往往来自非技术背景。
PM 被期望充当某个产品领域（例如我们的账单支付产品、代理网络等）的「迷你 CEO」，在该领域内拥有相当广泛的自主权。由于「迷你 CEO」角色涉及一堆其他能力，我们决定他们不必像普通工程经理那样懂技术。
尽管不寻常，这套做法行之有效，主要归功于几个原因：
- Wave 在技术上相对简单，但在运营和产品层面复杂，所以对「对总体方向负责的人」来说，技术技能相对不那么重要，运营/产品技能相对更重要。
- 我们给 PM 岗位招了非常强的人，主要是从其他团队内部把最强的人转岗过来。
- 每个团队的 PM 和 TL 都有非常牢固的工作关系，因此他们能就「速度与技术质量之间的权衡」这类问题有效沟通，而不会靠 PM 的一纸命令来拍板解决。
值得注意的是，这打破了我前面「人员管理者应该相当懂技术」的建议。它之所以行得通，主要是因为我们在人员管理里需要技术上下文的那部分，能重度依赖技术负责人。技术负责人是正式角色，间接汇报给一位工程经理的经理；虽然 PM 最终对人员管理负责，TL 也扮演了重要角色。他们两人都会与每位团队成员进行一对一，绩效评估由 PM 和 TL 共同撰写。
人员经理 / 研究负责人
Anthropic 有几个把人员管理与研究领导拆开的例子；运行最久的一个在可解释性团队：Chris Olah 负责总体方向和技术领导，Shan Carter 负责人和项目管理。（现在可解释性已有多个子团队，情况有所变化。）
在这种拆分里，不同于工程团队的 EM/TL 拆分，让研究负责人对总体方向负责更合理，因为总体方向极度依赖高上下文的直觉判断——判断该走哪条研究方向（例如在「叠加假设」上重注，并由此得到多个重大结果）。许多（尽管不是所有！）工程团队的优先级判断，对这种高度技术性的直觉判断依赖较少。
这个例子有趣之处在于：人员经理并不（主要）对总体方向负责。这在某种程度上类似于一些科技公司里的 CTO / 工程副总裁（VPE）拆分——CTO 对总体方向负责，而大部分人员领导职责落在向其汇报的 VPE 身上。
感谢 Milan Cvitkovic 和许多 Anthropic 同事阅读本文草稿。
这些分类是思考「如何拆分团队领导工作」的一个好起点，但现实当然更模糊、更混乱，职责不会恰好沿着这些轴切开。而且，对某个领域负责，并不意味着你是唯一出力的人；以上每一项都从他人的输入中获益良多！
不过值得指出的是，技术领导并不是独立贡献者实现高影响力的唯一途径！关于其他原型的、专门针对软件工程的拆解（部分而非全部适用于其他技术领域），参见 Will Larson 关于「Staff 工程师原型」的文章。
这些例子极不穷尽，也仍然是一个过度简化的示意图——在任何具体团队里，确切的划分取决于相关领导者的技能组合，而且会有大量的模糊与重叠！