为什么你（或任何人）应该成为一名研发经理？

原始链接: https://charity.wtf/2023/12/15/why-should-you-or-anyone-become-an-engineering-manager

我写的第一篇关于研发管理的文章是《工程师/经理钟摆》 (The Engineer/Manager Pendulum)。当时，我的一位朋友在一家快速发展的大型初创公司担任研发总监，但他工作得不开心。他怀念做工程师写代码的日子，但又害怕放弃管理岗会失去现有的影响力和地位。他为此纠结了很久。

在我看来，如果他回归技术岗位，凭借他积累的信誉和人脉，他的影响力只会增加。于是我为他写了那篇文章，没想到引起了巨大共鸣，至今仍是我阅读量最高的文章。

那是 2017 年的事。此后我很长一段时间写的文章，似乎都带有明显的"反管理、拥抱纯技术"的倾向：

现在回头看这些文章，那种普遍的"反经理"倾向让我有些不安，因为如今的行业环境已经大不相同了。

痛苦的经理带出痛苦的团队

早些年，很多人转管理根本不是因为喜欢这份工作，而是因为：

这是唯一的晋升渠道。
经理赚得更多。
这是获得话语权的唯一方式。
不想再听人使唤。

这导致了大量不开心、充满怨气且缺乏培训的经理出现，他们其实更想写代码。

但现在情况变了。Staff+ 工程师模式崛起（过去五年出版了两本新书甚至举办了专门的会议）。行业已经广泛接受了工程师职级概念，平行的技术领导者路线变得非常普遍。

同时，我们意识到传统的"指令与控制"管理模式非常脆弱。现在的软件系统极其复杂，你需要员工发挥主观能动性、充满好奇心并持续学习。你也无法靠"领 Jira 任务"的自动驾驶模式来构建伟大的软件。

因此，我们对经理的期望大幅提高。我们更清楚糟糕的经理会带来多大破坏，并越来越期望经理不仅懂技术，还要具备极高的同理心和支持力。

随之而来的疫情更是让许多夹在上下级不切实际期望中、得不到支持的经理们心力交瘁，纷纷逃离这个岗位。

现在，愿意做经理的人越来越难找了。一方面，人们不再为了贪婪或权力而被迫做管理，这是件大好事。另一方面，研发经理极其重要，我们迫切需要他们。

优秀的研发经理是"效能倍增器"

一个有优秀经理的团队，其表现会彻底碾压没有好经理的团队。组织越复杂、你想走得越快，这一点就越明显。

这不仅是情绪价值，而是直接转化为研发速度和质量。阻碍研发效能的最大因素从来不是写代码慢，而是：

把精力花在错误的事情上。
陷入无休止的争论和犹豫不决。
等待其他团队的配合或代码审查。
糟糕的新人入职体验，或维护不熟悉的代码。
员工情绪低落、分心或缺乏动力。
烂尾的系统迁移，或必须长期维护多个旧系统。
生产系统不透明，导致天天"救火"。
糟糕的流程和无休止的会议剥夺了专注时间。
团队成员拒绝互相沟通。
任由表现不佳的人无限期留在团队中。

工程师负责交付产品，而经理负责构建让交付得以实现的系统和结构支撑。

经理不亲自做所有决定，但他们确保决定被落实。他们争取资源，关注跨团队协作，在各个层面为团队发声，并将战略与执行连接起来。

在系统理论中，层级的出现是为了服务子系统。层级负责协调各个子系统，帮助它们改进功能。从本质上讲，经理就是系统对齐目标、持续改进所需的反馈循环的具象化。

那么，为什么你应该尝试做经理？

通常有以下几个好理由：

让你更接近业务运转的本质，了解决策是如何做出的，这会让你的工作显得更有意义。
满足指导和培养下一代的内在渴望。
你可能受够了糟糕的管理，想用自己学到的知识建立快乐的团队，并在行业内推广更好的实践。
让优秀的资深工程师做 2-3 年管理，是培养顶尖 Staff 工程师的好方法。

但我最想强调的、也是很少有人提前告诉你的一个理由是：做管理可以在极大程度上让你变得更懂生活、更擅长处理人际关系。

管理工作从外部看是发号施令，从内部看则是深刻认识自己和他人的局限性与动机。优秀的管理工作建立在一些非常基础的底层技能之上：

这些是你在心理咨询中才会学到的技能，而不是在课堂上：

自我调节 (Self-regulation)：你能持续照顾好自己吗？作为工程师，你偶尔可以透支自己；但作为经理，这属于玩忽职守。你必须始终保持能量，因为你不知道团队什么时候会需要你。

自我觉察 (Self-awareness)：在激烈的情绪中识别自己的感受，分析它们的来源，并决定如何应对。不是压抑情绪，更不是把你的情绪变成别人的麻烦。而是让你的行动受到真实情感的启发，但不被其支配。

理解他人 (Understanding other people)：你要学会读懂别人。建立一个心理模型：了解什么能激励他们、什么会困扰他们，并在各种情况下判断可以在多大程度上信任他们的判断力。

设定良好边界 (Setting good boundaries)：支持、鼓励、推动下属，与代替他们承担责任的界限在哪里？如何处理工作表现不达标时的问责？

对权力动态保持敏感 (Sensitivity to power dynamics) ：作为经理，别人对待你的方式和以前不同了。你曾经可以随便说的话，现在可能被视为施压或不当。

艰难的对话 (Hard conversations)：告诉别人他们不想听的话（这可能会让他们生气或害怕），然后坦然面对他们的反应，忍住想要把话收回、粉饰太平的冲动。

掌握"站在同一战线"的艺术 ：当你给出建设性反馈时，很容易引发对方的防御心理。你必须营造一种你们肩并肩、面对共同问题的动态：你给出反馈是因为你在乎，你是站在他们这一边的。

我在成长过程中学过这些吗？绝对没有。

我在一个非常"友善"的家庭长大，大家相亲相爱，但从不探讨棘手的问题。长大后，我完全不知道如何在不舒服时表达自己的想法，别人一生气我就崩溃。而且我很晚才培养出成长型思维（聪明孩子很容易把批评当成世界末日）。

直到我成为经理，我才被迫开始刻意练习给予反馈、接受批评和发起艰难对话。一旦开始练习，我就变得越来越好。

其实，工作是练习人生技能的完美沙盒，因为这里的社会契约非常明确。 你们聚在一起的目的是为了业务、项目和薪水。这种关系比面对父母、伴侣或孩子时更容易抽离，试错成本也更低。

人际技能是永久保值的

我想说的最后一点是------技术技能会衰退和过时，但人际技能不会。一旦你锻炼出了这些肌肉，它们将伴随你一生，极大地提升你在工作和生活中的沟通与建立信任的能力。

无论你未来决定做什么，这些技能都会增加你的选择权，让你变得更高效。这就是我认为你应该考虑成为研发经理的原因。如果你去问那些做了五年、十年管理的人，他们往往都会得出类似的结论。

最后一个警告

作为工程师，你可以在一家你不认同其领导团队或产品的公司工作，日子也能过得去。

但作为经理，你不能，也不应该这么做。 这种内心的冲突会吞噬你。

你的工作就是代表管理层，让团队与公司目标对齐。对于团队来说，你就是公司的代言人。你不能游离在组织之外推卸责任，比如对下属说："他们让我这么说的，但我其实不同意。" 这种做法只会削弱你和公司的威信。

因此，如果你决定做经理，请慎重选择你要加入的公司。

------ Charity

P.S. 文章开头提到的那位朋友，后来克服了担忧，重新做回了工程师，而且从未后悔。他的职业生涯一路高歌猛进，后来自己创办了公司。他作为经理期间培养的技能，为他本就出色的职业生涯提供了巨大的助力。📈