工程经理如何保持技术能力：成为管理者后还要写代码吗？

成为工程经理之后，是否应该停止写代码？管理者又该如何在承担团队管理职责的同时，持续保持技术能力？

在我的管理规则手册中，给新任经理列出的“必做事项”非常少。

清单之所以这么短，是因为“必须”意味着绝对，而在人与管理这件事上，真正绝对的规则少之又少。一种对某个人行之有效的管理方法，换到另一个人身上，可能会变成一场灾难。

因此，管理者必做事项清单中的第一条是：

保持灵活。

管理中唯一不变的事实是：一旦你认为自己已经见识过所有情况，麻烦往往就要来了。

既然变化才是唯一不变的事情，那么保持灵活，就是管理者唯一可靠的选择。

矛盾的是，清单上的第二条却显得异常绝对。但过去很长一段时间里，它一直是我最喜欢的一条，因为我相信，这项要求能够帮助新经理为提升管理能力打下基础。

这条建议是：

停止写代码。

工程经理为什么要停止写代码？

这条建议背后的逻辑是：如果你想成为一名真正的管理者，就必须学会信任团队，让下属承担编写代码和交付产品的责任。

对于刚刚晋升的工程经理来说，这条建议尤其难以接受。

他们之所以能够成为管理者，往往正是因为自己曾经是一名高效、可靠的开发者。当项目陷入困境时，他们的第一反应通常是重新拿起那些曾经帮助自己建立信心的工具——亲自写代码。

过去，每当我看到新经理重新投入编码工作时，我都会对他说：

“我知道你会写代码。问题是，你会不会管理？

你现在不再只对自己的工作负责，而是要对整个团队负责。我希望看到的，是你找到一种方法，让团队在你不亲自写代码的情况下解决问题。

你的任务，是设法扩大团队的能力。我需要的不是一个像你这样的人，而是很多个像你这样的人。”

听起来像是一条不错的建议，对吧？

规模、管理、责任——这些词都很符合现代管理话语体系。

可惜，我错了。

“停止写代码”这条建议错了吗？

没错，错了。

虽然并非完全错误，但确实错得相当严重。严重到我可能应该给过去的一些同事打电话道歉：

“还记得我以前说过‘不要再写代码’吗？那条建议不对。真的。重新开始写吧，可以从 Python、Ruby 或其他常用语言入手。我是认真的，因为这可能关系到你未来的职业发展。”

我刚开始从事软件开发时，所在的是一家海外软件公司的大型桌面应用团队。仅应用开发团队就有十多名开发者。

如果再算上数据库引擎、图形引擎、基础服务以及其他核心技术团队，直接参与产品研发的工程师大约有数十人。

此后，我再也没有加入过规模如此庞大的产品团队。

事实上，随着时间推移，为我所负责的产品作出贡献的工程团队，规模一直在持续缩小。

这是为什么？

难道是因为开发者的个人能力整体提高了？

并不是。

更重要的原因是，我们开始共享和复用彼此的工作成果。

过去几十年里，开发者编写了海量代码。代码之多，几乎可以堆成一座山。

后来，人们开始意识到：既然这么多人都在解决相似的问题，为什么不把代码开放出来，让其他人直接使用？

互联网的普及让代码共享变得极为容易。今天，许多开发者都能在公开代码托管平台上找到自己多年前写下、甚至已经遗忘的项目。

这件事多少有些令人不安。

你可能以为，那些年轻时写下的代码总有一天会消失，但它们往往不会。

代码会留下来。

优秀的代码不仅能够长期存在，还会不断生长。真正重视它的人，会持续维护、修复和升级它，避免它随着时间推移而失效。

正是这些高质量、维护良好的代码，帮助工程团队不断缩小规模。

我们不再需要从头编写所有东西，而是可以把更多精力投入现有组件的选择、集成和改造，从而用更少的人、在更短时间内完成过去需要大型团队才能完成的工作。

当然，这套逻辑也可能导向一种令人沮丧的结论：

开发者不过是一群拿着“胶带”，把各种现成零件拼接在一起的集成人员，最终制造出彼此略有不同、但本质相似的产品。

正是这种想法，让不少管理层对外包充满兴趣：

“既然只要会搜索资料、会组合现成组件就能完成工作，那为什么还要花高价雇用本地开发团队？”

当然，我们还花了不少钱，请管理者提出这些糟糕的主意。

但这也引出了另一个现实：

这个世界上有大量充满热情、才华横溢的开发者。即使他们没有接受过正规的大学教育，也依然能够快速学习、持续创造。

而且，这样的人还在不断涌现。

我并不是说，你应该担心某个远在海外的聪明人正在觊觎你的岗位。

我真正想说的是，你应该警惕另一件事：

软件开发方式的变化速度，可能比你适应变化的速度更快。

你可能已经从业十年，其中五年都在担任管理者，于是你会想：

“我知道软件是怎么开发出来的。”

没错。

你现在或许确实知道。

问题是，几年之后呢？

工程经理脱离代码，就可能脱离创造

如果你听从“停止写代码”的建议，彻底退出编码工作，那么你很可能也会逐渐退出创造过程。

这也是为什么我并不特别担心外包或自动化。

自动化程序不会真正创造，它们只会执行流程。

优秀的流程当然可以节省大量成本、提高效率、减少错误，但流程本身不会给世界带来任何真正的新事物。

在工程团队规模越来越小、承担的工作越来越多的情况下，完全脱离代码，在我看来是一种糟糕的职业选择。

即使你身处一家被制度、流程和组织政治层层包围的大公司，也不能忘记软件究竟是如何被开发出来的。

因为软件开发方式正在发生变化。

不是未来某一天。

而是此刻。

就在你的脚下。

我知道，你可能有很多疑问。

说出来吧。

“我的目标是成为总监，还需要写代码吗？”

“我的目标是成为总监。如果我还在写代码，别人会不会觉得我无法承担更大的责任？”

我的第一个问题是：

当你成为总监，坐在那个位置上时，你认为公司内部的软件开发方式正在发生变化吗？

如果答案是肯定的，那么下一个问题就是：

它正在发生怎样的变化？你准备如何应对？

如果你的答案是否定的，那你恐怕真的应该换一个位置观察问题。

因为我可以向你保证，软件开发此刻就在持续变化。

如果你已经逐渐忘记软件究竟是如何被开发出来的，又怎么可能判断团队应该如何扩张、技术体系应该如何演进，以及组织应该在哪些方面投入资源？

我的建议，并不是让你在下一个版本中给自己安排一长串功能开发任务。

我真正建议的是：

采取实际行动，持续了解团队的软件开发过程。

即使你已经成为总监或副总裁，也完全可以做到这一点。

“管理者总得有人负责方向”

“可总得有人充当裁判吧？总得有人负责愿景和方向。如果我也开始写代码，我还怎么保持全局视角？”

没错。

你仍然需要充当裁判。

你仍然需要作出判断、协调冲突、决定优先级。

你仍然需要在周一早上抽出半个小时，陪那位工程师绕着街区走上几圈，听他完成每周一次的“我们彻底完了”式抱怨。

但与此同时，你也需要偶尔放下管理者的全知视角，重新进入具体问题之中。

而要做到这一点，你并不需要重新成为一名全职程序员。

对于希望保持技术能力、又担心失去全局视角的工程经理，我有以下几个建议。

1. 使用团队的开发环境构建产品

你应该能够使用团队的真实开发环境完成一次产品构建。

这意味着，你需要熟悉团队正在使用的工具，包括构建系统、版本控制系统、开发框架和编程语言。

这项工作能让你继续使用团队理解工作、讨论问题时所依赖的语言。

当工程师提到构建失败、依赖冲突、分支策略或开发环境问题时，你不至于只能礼貌地点头。

对于规模较大的研发团队，管理者还可以借助 PingCode 这类一体化研发管理工具，持续了解需求、任务、开发、测试和发布之间的关系。它不能代替管理者亲自理解技术，但能够帮助你从完整研发流程和统一数据中发现问题，而不是只依赖会议汇报。

顺便说一句，这还意味着你可以继续使用自己最喜欢的文本编辑器。

多么美妙。

2. 能够画出详细的产品架构图

你应该能够随时在白板上画出一张足够详细的产品架构图。

我说的不是那种只有三个方框和两根箭头的高层示意图。

你真正需要掌握的，是一张详细、复杂、不太美观，甚至有些难以解释的架构图。

它应该包含产品的主要模块、系统边界、关键依赖、数据流向以及核心技术关系。

这张图就是你理解产品全貌的地图。

随着时间推移，它一定会发生变化，而你应该理解这些变化为什么发生，又会带来什么影响。

3. 负责一个小功能

写到这里，我仍然觉得有些不安，因为这项建议确实隐藏着风险。

但我认为，如果你没有一个真正属于自己的小功能，就很难认真做到前面两点。

负责一个功能，会迫使你参与真实的开发过程。

它还会暂时改变你的角色：你不再是那个“对所有事情负责的管理者”，而只是一个“对某项功能负责的人”。

这种谦逊而具体的视角，会重新提醒你，那些看似微小的决策究竟有多么重要。

我几乎可以听到有人冲我喊：

“经理怎么能亲自负责产品功能？”

我理解这种担忧。

你毕竟仍然是一名经理，因此只负责一个足够小、边界清晰、不会阻塞团队的功能。

别忘了，你还有大量管理工作要做。

如果你实在无法想象自己拥有一个完整功能，那么备选方案是：

修复几个缺陷。

修复缺陷不会给你带来完整交付功能的成就感，但它会让你深入了解产品的真实架构。

而这些信息，是你在办公室里来回走几圈、参加几场会议永远学不到的。

4. 编写测试脚本

即使在产品开发后期，整个团队都快要崩溃时，我仍然会做这件事。

编写一个简单的测试脚本，在每次构建完成后运行。

你可以把它看作一份关于产品核心能力的自动化检查清单。

把它展示给团队成员。

持续维护它。

经常运行它。

它不仅能帮助你理解产品当前是如何工作的，也会帮助你发现产品在不知不觉中发生了哪些变化。

与此同时，测试结果、缺陷记录、版本变更和项目经验也不应该散落在不同工具和个人文档中。借助 PingCode 将研发过程中的数据和知识串联起来，管理者可以更容易追踪问题从发现到解决的全过程，并把团队经验沉淀下来。

“工程经理写代码，会不会让团队困惑？”

“如果我开始写代码，我的团队会感到困惑。他们会不知道我到底是经理，还是开发者。”

很好。

我是认真的。

我很高兴你愿意重新加入开发者的行列，并且愿意让团队暂时感到一点困惑。

事实是，软件开发中清晰、固定的角色边界正在逐渐消失。

前端开发者需要理解交互设计，设计师开始理解组件和技术约束，后端工程师需要关注用户体验，测试人员也开始参与自动化建设和工程实践。

所有人都在彼此交流，从他人的错误中学习，借鉴别人的代码，也不断拓展自己的能力边界。

管理者没有理由拒绝参与这场大规模的信息交流。

更何况，你真正希望拥有的，应该是一支成员之间能够相互补位的团队。

这种能力不仅会让团队更加灵活，也会让每个人获得机会，从截然不同的角度理解产品和公司。

当你真正读过那位沉默寡言的构建工程师写下的优雅脚本之后，你或许会对他的能力产生全新的认识。

我并不是希望你的团队陷入角色混乱。

我希望的是，他们能够开展更多真实、深入的交流。

当你参与产品开发，亲自操作系统、验证功能、理解代码时，你会与团队建立更紧密的联系。

更重要的是，你也会更清楚地理解，公司内部的软件开发方式究竟正在发生怎样的变化。

工程经理唯一不能停止的是成长

在我职业生涯早期，一位同事曾温和而坚定地纠正我，因为我称她为“程序员”。

她说：

“程序员听起来像一台没有思想的机器，或者一只只会敲键盘的猴子。程序员只是机械地写出枯燥、没有意义的代码。

我是一名软件开发者。”

她说得对。

如果她听到我曾经建议新经理停止写代码，大概一定会非常不满。

并不是因为我把他们称作程序员，而是因为我主动建议他们忽略自己工作中最重要的部分之一：

软件开发本身。

所以，我修改了过去的建议。

工程经理可以停止把编程当作自己的主要工作，但是——

保持灵活。

不要停止学习。

更不要停止技术成长。