原文 QUESTIONABLE ADVICE: “MY BOSS SAYS WE DON’T NEED ANY ENGINEERING MANAGERS. IS HE RIGHT?”

我最近加入了一家初创公司，负责管理一个约 40 名工程师的团队，担任技术副总裁。然而，我与 CEO（之前是工程师）在是否需要雇佣专职技术经理的问题上产生了很大的冲突。目前，工程师们被分成了 3-4 人的小团队，每个团队有一个工程师头头，负责领导团队，但他们的主要职责仍然是编写代码和交付产品。

我有 HC 在未来一年雇佣更多的工程师，但没有经理的 HC。老板认为我们是初创公司，负担不起这种奢侈品。在我看来，我们显然需要技术经理，但在他看来，经理只是多余的开销，在我们的阶段所有人都应该全力编写代码。

我不知道该如何论证。在我看来这很显然，但实际上我很难用言语表达为什么我们需要技术经理。你能帮帮我吗？

—— 真的是多余的开销吗(？！)

这里有很多问题需要解答。

你的首席执行官不理解为什么需要经理，这并不奇怪，因为他似乎不明白为什么需要组织结构。🙈 他为什么要对你如何组织团队或你可以雇佣哪些角色进行微管理？他雇用了你来做这份工作，却不让你完成。他甚至不能解释为什么不让你做。这不是个好兆头。

但这个问题确实值得思考。我们假设他不是故意要刁难你。😒

我能想到两种论证雇用技术经理的方式：一种是相当复杂的，从第一性原理 (First Principle) 出发，另一种非常简单，但可能不太令人满意。

我个人对权威有一种强烈的反感；我讨厌被告知该做什么。直到最近，我才通过系统理论的视角，找到了一种对层级制度既健康又实用的理解。

为什么组织中存在层级制度？

层级制度确实带有很多负面包袱。我们许多人都有过在层级制度下与经理或整个组织打交道的不幸经历。在这些地方，层级制度被用作压迫的工具，人们通过垄断信息和玩弄权力游戏来提升地位，决策则是通过权力压制来做出。

在那种地方工作真的是一种折磨。谁愿意将自己的创造力和生命力投入到一个感觉像《呆伯特》漫画的地方，明知道自己的价值被极少认可或回报，而且这些价值会慢慢地但确实被压制掉？

但层级制度本质上并非是专制的。层级制度并不是人类为控制和支配彼此而发明的一种政治结构，它实际上是自组织系统的一种属性，是为了子系统的有效运作而出现的。事实上，层级制度对复杂系统的适应性、弹性和可扩展性至关重要。

让我们从一些关于系统的基本事实开始，为可能不熟悉的人介绍一下。

层级是自组织系统的一种属性

一个系统是「由相互依赖的组件组成的网络，这些组件共同工作以实现一个共同目标」（W. Edward Deming）。一堆沙子不是一个系统，但一辆车是一个系统；如果你把油箱取下来，车就无法运作。

子系统是一个在更大系统内有较小目标的元素集合。在一个系统中可以有很多层次的子系统，它们相互依存地运行。子系统总是为了支持更大系统的需求而工作；如果子系统只为自己的最佳利益优化，整个系统可能会挂掉（这就是「次优」(suboptimal)这个术语的由来 😄）。

如果一个系统能够通过多样化、适应和改进自身使自己变得更加复杂，那么它就是自组织的。随着系统自组织并增加其复杂性，它们往往会生成层级 —— 即系统和子系统的排列。在一个稳定、有弹性和高效的系统中，子系统在很大程度上可以自我管理、自我调节，并为更大系统的需求服务，而更大系统则负责协调子系统之间的关系并帮助它们更好地发挥作用。

层级最小化了协调成本，减少了系统中任何部分需要跟踪的信息量，防止信息过载。子系统内部的信息传递和关系比子系统之间的信息传递或关系要密集得多，延迟也少得多。

（对于任何软件工程师来说，这些应该都很熟悉。模块化，对吧？😍）

按照这个定义，我们可以说，经理的工作就是在团队之间进行协调并帮助他们的团队表现得更好。

对社会技术系统的二分是伪命题

你可能听过这个谬论：「工程师搞技术，经理搞人。」我讨厌这种说法。😊 我认为这完全误解了社会技术系统的本质。社会技术系统中的「社会」和「技术」并不是截然分开的，而是相互交织、相互依存的。事实上，很少有纯粹的技术工作或纯粹的人际工作；有大量涉及两种技能的粘合工作。

看看任何一个有效运作的工程组织除了编写代码之外还要做的一部分任务：

• 招聘、建立人脉、面试、培训面试官、汇总反馈、撰写职位描述和职业发展路径
• 每个项目或承诺的项目管理、优先级排序、管理利益相关者和解决冲突、估算规模和范围、进行回顾会议
• 召开团队会议、进行一对一交流、提供持续的成长反馈、撰写评审、代表团队的需求 架构设计、代码审查、重构；捕获 DORA 和生产力指标、管理警报量以防止倦怠

许多工作可以由工程师完成，而且通常也是如此。每家公司对这些任务的分配方式有所不同。这是一件好事！你不希望这些工作仅由经理来做。你希望个人贡献者共同创造组织，并参与其运行方式。几乎所有这些工作由有工程背景的人完成会更有效。

所以，你可以理解为什么有人会犹豫是否要把宝贵的人员编制花在技术经理上。为什么不希望技术部门的每个人的主要工作都是编写和交付代码呢？这不是从定义上说最大化生产力的最佳方式吗？

额……😉

技术经理是一层有用的抽象

理论上，你可以列出所有需要完成的协调任务，并让不同的人来负责每一项。但实际上，这是不切实际的，因为这样每个人都需要了解所有事情。记住，层级制度的主要好处之一是减少信息过载。团队内部的沟通应该是高效和快速的，而团队之间的沟通则可以少一些。

随着公司的扩展，你不能期望每个人都认识其他所有人；我们需要抽象的概念才能运作。经理是他们团队的联络点和代表，充当重要信息的路由器。

有时我把经理想象成公司的神经系统，将信息从一个部门传递到另一个部门，以协调行动。将许多或大部分功能集中到一个人身上，可以利用专业化的优势，因为经理会不断建立关系和背景知识，并在他们的角色中不断改进，这大大减少了其他人的上下文切换。

管理者 (Manager) 日程与创造者 (Maker) 日程

技术工作需要集中和专注。上下文切换的成本很高，过多的中断是挺要命的。而管理工作则是每小时左右进行一次上下文切换，并且一整天都要应对各种打断。这是两种完全不同的工作模式、思维方式和日程安排，无法很好地共存。

通常，你希望团队成员能够把大部分时间花在直接为他们负责的成果做出贡献的事情上。工程师只能做有限的粘合工作，否则他们的日程安排就会变得支离破碎，从而无法履行他们的承诺。而管理者的日程安排本身已经是支离破碎的，因此让他们承担更多的粘合工作通常不会带来太大干扰。

虽然并不是所有粘合工作都应该由管理者来完成，但管理者的职责是确保所有工作都能完成。管理者的职责是尽量让每个工程师都能从事有趣且具有挑战性的工作，但不能让他们感到过于负担重，还要确保不愉快的工作能公平分配。管理者还要确保，如果我们要求某人完成一项工作，就必须为其配备成功完成这项工作所需的资源，包括专注的时间。

管理是问责的工具

当你是工程师时，你对自己开发、部署和维护的软件负责。而作为经理，你则对团队和整个组织负责。

管理是一种让人们对特定结果（如构建具备正确技能、关系和流程的团队，以做出正确的决策并为公司创造价值）负责的方式，并为他们提供实现这些结果所需的资源（预算、工具和人员编制）。如果你不把组织建设作为某人的首要任务，那么这就不会成为任何人的首要任务，这意味着它可能不会得到很好地执行。那么，这该由谁负责呢，CEO 先生？

你对技术负责人、工程师或任何负责交付软件的人在「业余时间」能完成的任务有一个合理的上限。如果你试图让技术负责人负责构建健康的工程团队、工具和流程，那么你就是在要求他们在同一个日历里做两份时间不兼容的工作。最可能的情况是，他们会专注于自己觉得舒适的成果（技术成果），而在后台堆积组织债务。

在自然层级中，我们向上看是为了目标，向下看是为了功能。简而言之，这就是我们需要技术经理的复杂原因。

选择无趣的技术文化

更简单的论点是：大多数工程组织都有技术经理。这是默认设置。多年来，许多比你或我更聪明的人花了大量时间思考和调整组织结构，这就是我们得到的结果。

正如丹-麦金利（Dan McKinley）的名言，我们应该「选择无趣的技术」。无趣并不意味着不好，而是意味着它的能力和失败条件是众所周知的。你只能获得少数的创新点数，因此你应该明智地将这些点数用在能够成就或毁掉你业务的核心差异点上。文化也是如此。你真的想把你的点数用在组织结构上吗？为什么？

无论好坏，层级组织结构是众所周知的。市场上有很多人擅长管理或与管理者合作，你可以雇佣他们。你可以接受培训、指导，或者阅读大量的自助书籍。有各种各样的管理哲学可以围绕它们来凝聚团队或用来排除其他人。另一方面，我所知道的无经理实验（例如 Medium 和 GitHub 的全员自治，或 Linden Lab 的「选择你的工作」）都被悄然放弃或被颠覆了。在我的经验中，这并不是因为领导者疯狂追求权力，而是由于混乱、缺乏重点和执行不力。

当没有明确的结构或层级时，结果不是自由和平等，而是「非正式的、不被承认的和不负责任的领导」，正如《无结构的暴政》中详细描述的那样。事实上，这些团队往往是混乱、脆弱和令人沮丧的。我知道！我也很生气！😭

这个论点并不一定能证明你的 CEO 是错的，但我认为他的证明标准比你的要高得多。「我不想让我的任何工程师停止写代码」并不是一个有效的论点。但我也觉得我还没有完全解决生产力的核心问题，所以我们再来讨论一下这个问题。

更多代码行数 ≠ 更高生产力

简要回顾一下：我们在讨论一个有约 40 名工程师的组织，分成 10 个小组，每组有 3-4 名工程师，每组都有一个技术负责人。你的 CEO 认为，如果有人停止全职编程，这个减速将是你们无法承受的。

也许吧。但根据我的经验，由经验丰富的技术经理领导的几个较大团队，将远远优于这些小团队。这差距很明显。而且，他们可以以更高效、可持续和人性化的方式完成工作，而不是这种拼命的死命赶工。

系统思维告诉我们原因！更少的团队，但规模更大，你会有更少的整体管理开销，且大大减少了团队内慢且昂贵的协调。你可以在团队内部实现丰富、密集的知识传递，从而实现更大面积的共享。每组有7-9名工程师，你可以建立一个真正的值班轮换，这意味着更少的英雄主义和更少的倦怠。你需要进行的协调可以更具战略性，减少战术性，更具前瞻性。

五个大团队是否能比十个小团队编写更多的代码行数，即使有五名工程师成为经理并停止编写代码？可能会，但谁在乎呢？你的客户根本不关心你写了多少代码行数。他们关心的是你是否在构建正确的东西，是否在解决对他们重要的问题。关键是推动业务前进，而不是单纯地编写代码。不要忘记，单纯地编写代码会产生额外的成本和负面效应。

决定你速度的是你是否把时间花在了正确的事情上。学会正确决定构建什么是每个组织都必须自己解决的问题，而且这是一项持续不断的工作。技术经理不会做所有的工作或做出所有的决策，但根据我的经验，他们对于确保工作顺利进行并且做得很好，绝对至关重要。正如我在上篇文章中写到的，技术经理是系统用来学习和改进的反馈循环的载体。

管理人员是否会成为不必要的开销？

当然有可能。管理的核心是协调团队之间的工作并提升团队的运作效率，所以任何减少协调需求的方式也会减少对管理的需求。如果你是一家小公司，或者你的团队成员都是非常资深且习惯合作的，那么你就不需要太多的协调。另一个重要因素是变化的速度；如果你的公司在快速增长或者人员流动频繁，或者面临很多时间压力或频繁的战略调整，你对管理人员的需求就会增加。但也有许多较小的组织在没有太多正式管理的情况下运作得很好。

我不喜欢「开销」这个词，因为 a) 这有点粗鲁，b) 称管理人员为「开销」的人通常是不尊重或不重视管理这门技艺的人。

但管理实际上确实是开销😅。许多其他的粘合工作也是如此！这些工作很重要，但它们本身并不能推动业务向前发展；我们应该尽量只做那些绝对必要的工作。粘合工作的天然属性使得它很容易扩散，吞噬所有可用的时间和资源（甚至更多）。

限制是好的。感觉资源不足是好的，这应该成为常态。管理很容易变得臃肿，管理人员可能非常不愿意承认这一点，因为他们从来没有感到压力或紧张减少。（事实上，情况可能恰恰相反；臃肿的管理层可能会为管理人员带来更多工作，而精简的组织结构可能会让他们反而感到压力更小。官僚主义往往会自我发育。特别是当管理层过于关注晋升和自我时。这也是确保管理不应仅为升职或统治的又一个充分理由）

管理也很像运营工作，当它做得好的时候，是看不见的。评估管理人员的工作可能非常困难，尤其是在短期内，而决定何时创建或偿还组织债务是一个完全不同的复杂问题，远远超出了这篇文章的讨论范围。

但是，是的，管理人员绝对可以成为不必要的开销。

然而，如果你有 40 个工程师都向一个副总裁汇报，而没有其他人专门负责人员、团队和组织相关的工作，那么我可以相当肯定地说，这对你来说目前不是一个问题。

<3

💡 更多资讯，请关注 Bytebase 公号：Bytebase