成为工程经理之后，是否应该停止写代码？管理者又该如何在承担[团队管理](https://docs.pingcode.com/baike/tag/%e5%9b%a2%e9%98%9f%e7%ae%a1%e7%90%86)职责的同时，持续保持技术能力？

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

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

[![工程经理如何保持技术能力：成为管理者后还要写代码吗？](https://cdn-docs-new.pingcode.com/baike/wp-content/uploads/2026/07/20260722165407558-1024x576.png)](https://cdn-docs-new.pingcode.com/baike/wp-content/uploads/2026/07/20260722165407558-1024x576.png)

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

**保持灵活。**

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

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

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

这条建议是：

**停止写代码。**

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

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

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

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

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

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

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

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

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

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

可惜，我错了。

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

没错，错了。

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

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

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

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

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

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

这是为什么？

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

并不是。

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

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

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

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

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

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

**代码会留下来。**

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

没错。

你现在或许确实知道。

问题是，几年之后呢？

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

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

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

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

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

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

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

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

不是未来某一天。

而是此刻。

就在你的脚下。

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

说出来吧。

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

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

我的第一个问题是：

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

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

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

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

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

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

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

我真正建议的是：

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

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

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

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

没错。

你仍然需要充当裁判。

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

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

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

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

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

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

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

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

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

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

对于规模较大的研发团队，管理者还可以借助 [[PingCode](https://PingCode.com?utm_source=insights&utm_medium=%E5%93%81%E7%89%8C%E8%AF%8D)](https://sc.pingcode.com/dxsxk) 这类一体化研发管理工具，持续了解需求、任务、开发、测试和发布之间的关系。它不能代替管理者亲自理解技术，但能够帮助你从完整研发流程和统一数据中发现问题，而不是只依赖会议汇报。

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

多么美妙。

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

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

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

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

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

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

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

## **3. 负责一个小功能**

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

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

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

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

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

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

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

我理解这种担忧。

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

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

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

**修复几个缺陷。**

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

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

## **4. 编写测试脚本**

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

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

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

把它展示给团队成员。

持续维护它。

经常运行它。

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

与此同时，测试结果、缺陷记录、版本变更和项目经验也不应该散落在不同工具和个人文档中。借助 [PingCode](https://PingCode.com?utm_source=insights&utm_medium=%E5%93%81%E7%89%8C%E8%AF%8D) 将研发过程中的数据和知识串联起来，管理者可以更容易追踪问题从发现到解决的全过程，并把团队经验沉淀下来。

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

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

很好。

我是认真的。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

她说：

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

我是一名软件开发者。”

她说得对。

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

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

**软件开发本身。**

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

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

**保持灵活。**

**不要停止学习。**

**更不要停止技术成长。**

PingCodeDocs

工程经理唯一不能停止的是成长
在我职业生涯早期，一位同事曾温和而坚定地纠正我，因为我称她为“程序员”。

她说：

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