为什么工程经理不该审代码了

观察这台机器 — Midjourney v5.1

当谈到团队组织时，我经常被问到：“为什么不让技术负责人管理团队？”对此我的反应就像是吸血鬼遇到圣水一样，忍不住发出嘶嘶声。紧接着有人问：“既然你希望团队中有经理，经理还能做代码审查吗？”我顿时就火冒三丈了。

这个问题经常有人问。但是，让我们再仔细想想这个问题（以及我对此的回答），想得深一点。

• 为什么不让技术主管管理团队？
• 为什么不让工程经理执行代码审查？

就像技术领域的所有事情一样，答案取决于具体的情况。这里我试着回答一个常被问起的问题：“为什么技术领导不应该领导团队，为什么一个拥有足够团队规模的工程经理不应该进行代码审查？”

我们从三个方面来回答这个问题：角色定义、团队沟通的复杂性以及团队规模。让我们通过一些有用的图表来解释我的理由。注意：接下来会用一点简单的数学知识。

首先，让我们来谈谈角色定义。工程经理和技术负责人是两个不同的角色，拥有不同的技能组合。一个人可能适合其中一个角色，但不一定适合另一个（反之亦然）。比如，团队中最好的程序员并不总是最适合来统筹所有事情的人。

然而，团队需要这两个角色才能发挥最佳作用。所以，我们来比较一下这两个角色。

TL与EM的角色和职责差异

这张表就是原因，当工程师想要成为经理时，我就会开始一轮这样的询问——因为这两个角色非常不同。

这张表格反映了技术负责人和工程经理之间的合作——在组织和沟通与实际技术深度思考之间的一种分工。这两个角色在团队中级别和职责范围上是平等的，但他们执行的是不同类型的活动，来支持团队的成功。

要想经理与领导之间的合作顺利进行，他们需要建立彼此间的信任。

• 经理应该将团队的技术领导权委托给技术负责人，并且别再操心这些琐事。经理不应忽略他们几十年的技术背景。然而，管理本质上是一个政策工作，管理者应该尊重边界。任何其他行为都是过度干预，会破坏信任。
• 技术负责人应该将职业发展、团队成长、沟通和协调等工作事务委托给工程经理，并专注于架构和技术选择、技术方向以及帮助推动实施。

然而，在团队人数未达到4人之前，经理和领导的角色区别不需要存在。职责界限会变得模糊。一旦团队人数达到4人或更多，角色会开始分工，工程经理应该专注于整个团队的整体表现，并且与技术负责人建立信任伙伴关系。

让我们看看为什么 size >= 4 是一个转折点。

其次，我们来谈谈沟通。一个管理者通过坚实的基础沟通建立起高效运作的团队。当我们向团队中添加成员时，沟通渠道会增多。我们直觉上认为团队沟通的复杂度随着人数的增加呈 O(n) 增长，但在这一点上，《人月神话》（The Mythical Man-Month）的观点完全正确。

随着每次有新成员加入，团队中的沟通复杂度会增加 (n * (n-1))/2 — 或 O(n²)，即二次时间复杂度。

• 刚开始，你是团队中唯一的人，所以你一整天都在自言自语。0条沟通路径，记得要定时休息，保持健康。
• 你增加了一个成员A。现在你和A开始交流，1条沟通路径。
• 你再增加一个成员B。现在你管理着3条沟通路径——你和A，你和B，A和B。
• 再增加一个成员C。现在你管理着6条沟通路径了。
• 以此类推。

让我们看看团队成员间的沟通方式吧——每个人都要和其他人沟通！

一旦我们建立了一个由5人组成的团队（总共6人，包括你和5名工程师），再加入一名产品经理和一名数据科学家，团队经理必须确保*26（(87)/2）**条团队内部沟通渠道畅通无阻，以确保团队高效运作。再加上一些合作伙伴团队，并与市场、销售和客服团队互动——管理团队突然变得需要全职投入。

所有这些交流环节都代表着一项时间投资。经理就像是一个复杂交流网络中的蜘蛛，这一角色涉及等等。

• 清晰地沟通优先级，
• 推动团队执行任务，
• 与相关方协调状态和发布，
• 确保团队流程顺畅，
• 沟通团队和个人目标、期望和表现，助力职业发展，
• 解开团队沟通的疙瘩，
• 等等。

仅仅管理团队的会议就变得复杂，随着团队的增长。团队增长的负面效应被称为 规模不经济效应 —— 随着系统规模的增加，系统变得越来越僵化，复杂性成本也不断上升。这就是为什么站会会随着参会人数的增加而逐渐变得效率低下。

而且团队无法无限扩展——无限增加团队成员会导致团队崩溃。当沟通连接达到或超过Dunbar 数量时，管理者就无法独自应对沟通的复杂性了。在大约有17个人（136个连接）之前，管理者必须开始优先处理人际关系或重组团队，或者进一步委派。

复杂性的激增并不能解释为什么管理者不需要亲自写代码，但它确实描述了当团队达到一定规模时，管理者的日程会变成那种典型的“管理者日程”，并且时间变得尤为珍贵。

我们来画一下这个，看看它是什么样的。

第三点，我们要讨论一下团队规模和沟通的事项。我们这里的人都是工程师。如果我们能做任何事情，那就是关于数据分析或绘图的工作。

我们绘制互联通信的复杂度和团队规模，以确定经理应在何时退出技术工作，专注于团队沟通所需的额外努力。（需要注意的是，这里的统计数字包括了经理，所以人数是经理加上工程师。）

团队规模与沟通联系图

在 1–3 名团队成员的情况下，沟通联系是小组可以管理的。团队仍然很小且负担不重。在这个规模下，团队领导可以担任技术负责人的角色——一个小技术团队的领导者，仍然可以编写代码并处理技术事务，同时保持许多管理角色的方面：培养工程师、进行绩效评估、管理与周边团队合作的负担等。沟通负担尚未变得令人难以承受，同时承担这两项角色是可行的。

当团队人数达到四人时，问题开始显现，当有 6 条路径需要维持协调时。6 条路径似乎并不算多，但开始思考增长、性能、优先级和对齐这四个方面的四人时间时，这需要大量的时间投入，技术产出开始下降，必须做出取舍——特别是当一个人需要扮演双重角色时，要么是产出，要么是沟通的质量。工程师的成长停滞。代码的输出停滞。团队在最重要的事情上感到迷茫。

当TLM必须在技术负责人和项目经理之间做出选择（但不能同时担任）时，4就成了关键的数字。

当团队成员达到5人时，TLM方式就不再适用了。如果没有人主动承担团队沟通的角色会怎样？通常情况下，团队会陷入混乱，无法继续推进他们的优先事项。团队及其利益相关者会感到困惑。必须有人建立清晰的流程，让工程师能够专注于他们最擅长的事情：创造出色的东西。这个角色需要全职的人来做。

相互连接的通信的复杂性也是为什么大型团队会自然分成1到3人的小组来专注于一个项目上的原因。在团队规模为1到3人时，沟通变得容易管理，技术工作也能顺利进行。但是，一旦团队成员增加到第4个人，我们进入了团队规模曲线的领域……

看来TLM角色是个理想的选择，既可以让领导者进行人员管理，又可以让他们做技术工作，结合了两方面的优势。此外，对于小公司来说，让技术负责人转为TLM是快速组建团队的一个便捷方式。

但是TLM不是一个长期职位，因为最终，技术领导和技术经理的角色是不同的。因此，TLM是一个死胡同：同时做得不好两份工作，无法像专注于单一角色的人那样推动技术或团队的发展。最后，TLM将需要选择一个专攻的方向，要么投入100%的时间专注于一个角色，否则他们将停滞不前，无法进一步扩展其职责范围。

注：此处的翻译更准确地表达为：“为什么工程师经理不应该进行代码审查”，这样表达更加自然和贴近中文日常用语。

最后，把这些信息汇总起来，我们已经确认了两个事实：

• 技术主管和项目经理是两个互补的角色，共同促进团队协作。因此，他们应该有明确的职责分工，并相互配合。
• 当团队规模达到大约4人时，必须有人专门负责沟通协调，以确保团队能有效运作。否则，团队将陷入一团糟。

在团队规模达到 >= 4 时，经理应该专注于他们的核心职责——管理团队内部和外部的沟通，关注工程师的成长，这同样涉及沟通，并理解团队优先级。技术主管应该专注于架构、技术选择以及团队的技术工作。分而治之是团队获得成功的方法。

拆解我们如何走到终点

• 工程经理的核心职责是管理团队内外的沟通——包括职业发展、绩效、计划以及设定团队流程。这一沟通工作需要投入大量的时间。
• 当团队规模足够大时，经理必须在技术专长和投入对齐与沟通之间做出权衡，因为这时沟通的复杂性很高。
• 当团队规模足够大时，沟通负担可能变得非常高，以至于经理必须有所取舍，否则会因沟通工作过于繁重而无法应对，因为它的复杂性。
• 工程经理审查代码不仅忽略了他们的核心职责，还是一种对技术主管的微观管理。这种行为会破坏信任关系。
• 这不仅是一种微观管理，还表现出对技术主管的轻视。
• 这并不意味着工程经理不能参与技术讨论（特别是架构审查），但是技术方向应由技术主管主导。

因此，当一个工程经理拥有足够规模的团队时，他就不应该亲自审查代码了。信任、授权和沟通才是他的核心工作，这才是关键所在。