如何叠加管理能力成为管理者，不是放弃技术成为管理者

2025 年 4 月 10 - 12 日，QCon 全球软件开发大会将在北京召开，我们策划了「大模型驱动的组织管理创新」专题，如果你有 AI 深度赋能帮助团队降低认知负担，提升团队效率相关实践案例想要分享，欢迎点击链接提交演讲申请。

在 2024 年 10 月 18-19 日举办的 QCon 全球软件开发大会上，同程旅行出行事业群 CTO 王晓波带来了精彩专题演讲“如何叠加管理能力成为管理者，不是放弃技术成为管理者”，他用一次系统重构为例来展开技术管理在实践过程中要做好的是哪些事情，从各个不同的视角聊技术管理。

从大部分系统问题的分析中，我们可以发现：发生问题的根源在于管理，也就是越有问题的技术团队产生的系统越容易出问题，那管理到底要管理什么？为什么技术团队的管理有别于其他类型的团队管理？技术管理的本质是在于技术，如果管理人是难题，那么管理技术是难上加难，因为技术管理不只要管人，还要管技术本身。技术管理者应该要管理什么？管理技术方案 + 研发进度 + 系统稳定性？如果只管这些，那么我们所做的系统将不只是会失败，更会变成的天坑级债务留下给后来者天天唾弃。如何做技术的管理呢？它应该是一个全方位的技术实践过程，从对业务的理解开始到技术选择，再到业务与技术螺旋式提升。

内容亮点

• 技术管理与管理的不同之处往往让人进入管理的误区。

• 技术人员如何叠加管理能力成为管理者，不是放弃技术成为管理者。

以下是演讲实录（经 InfoQ 进行不改变原意的编辑整理）。

最近一个朋友的帖子引起了讨论。帖子是讨论年底时哪个部门最稳定，点赞最多的回答说做领导最稳定，这让他的老板感到有些尴尬，半开玩笑地说是不是我们领导得太多了。但实际上，我想真正的原因可能是三年的疫情和经济下行给管理者和程序员带来了新的压力。三四年前，我们的压力来自于流量、系统和价格竞争，而现在，管理压力可能来自于降本增效，以及各种的质疑，比如“你的工作都外包出去了，你是不是也快失业了”。在这样的压力下，我们不得不思考管理和技术如何平衡的问题。管理者如果把工作都外包出去，那他们的角色又是什么呢？最近我深刻重新理解了技术管理者和普通管理者的区别。管理者可以依靠报表来决策，但技术管理者如果只依赖数据，那可能就大错特错了。大多数情况下，如果一个技术管理者只关注数据，可能已经走在了失业的路上。

我们民族常常自豪地谈论我们五千年的历史，我曾在十一假期去长城，思考为什么祖先要在北方山里修建那么一堵墙。我们有那么多的兵书、兵法，以及古代的冷兵器，但我们与外敌打了两千年，最终却不得不修建长城来防御。这让我想到了我们的管理方法论，我们用了无数的管理理论，但最终可能还不如一把弯刀和一匹战马来得直接有效。工作的本质是解决问题，无论是写代码还是修复 bug，或者是带领团队达成目标，结果才是最重要的。技术管理之所以要强调“技术”二字，是因为技术工作不能仅仅依靠标准化和抽象的数据来决策。一个程序员写 1000 行代码可能并不比写 5 行代码的效率高。所有的管理方法论在这种情况下都失去了作用，唯一管用的是你对这件事情的直接理解和判断。因此，我们今天要探讨的是技术和管理的关系，以及如何平衡这两者。

技术与管理的关系

我们可以从理论上分析技术管理的演变，以及为什么会有基层、中层、高层的技术管理者，他们各自的职责是什么。同时，我们也会讨论技术人员何时应该转向管理岗位，以及是否所有技术人员都应该升级为管理者，这一系列问题构成了职业发展的一部分。

以一个团队为例，大约有 1000 多名程序员，每十人会有一个基层的领导者。这些领导者如果技术水平不行，几乎百分百会被淘汰。为什么会这样？因为在技术领域，解决问题是最重要的，技术强者往往是最有效的领导者。如果一个不懂技术的人领导一个技术团队，那么所有的决策都将依赖于下属的汇报，这种情况下，多数服从少数的原则可能会导致技术决策上的问题。在编写代码时，我们就知道，也许只有几行代码决定了事情的成败，也许一个技术设计的思想就决定了项目的成败。有时我们需要采取直接而有效的“弯刀战马”策略，虽然简单，但效果显著。

如果一个团队只有“弯刀战马”，那么就像我们之前讨论的农耕文明与游牧民族的对比，虽然游牧民族可能一度强势，但最终他们的文化和影响力却不如农耕文明持久。同样，技术团队如果只依赖技术强者，那么随着这个英雄的离去，团队可能会迅速瓦解。这也引出了另一个问题：是给技术人员附加管理能力更简单，还是给擅长管理的人附加技术判断能力更简单？我们应该选择更简单、成功率更高的方式来进行。

从老板的角度来看，他们关心的不是简单地替换人员，而是如何排兵布阵。高层领导会考虑如何布局，而下一层领导也会在他们的层面上进行布局。这些布局是一脉相承的。从顶层来看，技术管理需要什么？是快速解决问题，还是长期稳定？如果是快速解决问题，那么他们可能会选择“弯刀战马”的方式；如果他们认为需要长期稳定，那么他们可能会更多地沉淀方法论，做长期稳定的事情。为什么会发生人员的更迭？一方面是因为岗位很重要，不能总是由一个人来担任，否则就成了瓶颈；另一方面，可能需要新的阵列布局。在新的布局前沿，人员移动不会那么快，需要提前布局准备。这种情况下，可能会将一批管理人员和技术领导者转移到其他地方，逐步撤出，而新的人逐步接手，形成新的进攻态势。

在职业生涯的发展中，如果是一个技术人员，从第一天到退休那天都不应离开技术。一旦离开了技术，那么这个人就不再与技术有关，我们不能再称他为技术管理者，而只能称他为管理者。许多创业公司的大老板都是技术出身，他们可能已经回答不出一些代码问题，蜕变为管理者。

技能要求与工作职责

从角色转换的角度来看，我们会发现让技术人员担任管理角色相对容易，而反过来则困难得多。想象一下，让一个从未写过代码但管理能力很强的人学会架构设计、判断代码的好坏，这几乎是不可能的任务。曾经有个朋友问我，是否有可能通过一个创新训练项目，从全国优秀的大学中挑选人才，用三个月时间将他们培养成 P6 或 P7 级别的程序员。我回答说，虽然我没有尝试过，但如果这真的成功了，我建议你不要卖其他商品了，而是去“卖人”，因为如果你能在三个月内将一个新手培养成 P7，那你可能是全球最赚钱的公司了。因为这种快速的成长经历是不太可能的，所以在技术领域，我们发现不是所有技术人员都适合担任管理角色。但是，如果他们具备两个前提条件，那么机会就会大得多。第一个前提是他必须善于沟通。对于那些沟通能力不强但代码写得很好的程序员，他们是否有机会呢？答案并不确定。但相对来说，沟通能力较好的人机会要大得多。第二个条件是技术能力。为什么技术 leader 能够成为 leader？因为他的技术能力非常强大家都很服他。早期所有问题都是他解决的，后期他一眼就能看出问题所在，并且能够准确判断方向。在这种情况下，大家都会服从他，因为跟着他有饭吃。所以，技术能力和沟通能力是技术人员转向管理角色的两个关键前提。

从工作特点上来说，编程和管理在本质上其实是同一件事情。我们今天写的代码，无非是在进行管理：管理计算资源、管理内存。同时，我们还管理业务流程，最终形成业务系统。而管理人也是同样的道理，我们要充分利用每个人，让他们发挥最大的价值，这就好比是充分利用每兆内存。如果没有做好管理，就像内存没有得到释放，最终就需要进行垃圾回收（GC）。用这样的比喻来说，我们自然而然会理解到，许多领导者确实是从技术能力较强的程序员中成长起来的。他们早年技术出色，后来逐渐走上了管理岗位，这确实是一个常见的现象。这些技术出身的领导者，由于对技术有深刻的理解和经验，往往能够更好地理解团队的技术需求和挑战，从而在管理上也能发挥出他们的优势。

评估标准和职业发展路径

在技术管理领域，除了管理人之外，还有一个非常重要的要素，那就是管理事务。技术管理者所管理的事务包括什么呢？其中一件非常有意义的事情就是关注团队代码的质量。这并不是说管理者要亲自写代码，而是要确保团队的代码写得怎么样。

曾经有一个讨论是关于 CTO 是否应该写代码的。我上周去成都的研发中心，那里的负责人因为还亲自写代码而被我批评了。他带领着一个一百多人的团队，却还让自己写代码到很晚。起初我批评他，但他反驳我说，如果不写代码，如何保持技术的一线能力？这让我一时语塞，因为他说得有道理。后来我告诉他，关键是要看时间和场景。从发展的角度来看，管理者应该保持对技术的敏感性，多看代码，而不是多写代码。管理者需要检查团队的代码是否正确，架构设计是否合理，业务流程是否符合要求。

在技术团队中，最大的问题是系统的技术债务。不管管理多么严格，代码最终都可能会腐化。大量的业务堆积，为了快速完成，有时不得不牺牲代码质量。如果长时间忽视团队代码的质量，那么代码就会腐化，最终可能导致系统崩溃，无法继续迭代。这时，业务 CEO 可能会说研发水平太差，制约了业务发展。从这个角度来看，控制代码腐化是一件非常重要的事情，这需要从最高领导开始，自上而下地抓起。解决代码腐化问题，一方面是平时要多看代码，更重要的是要进行重构。重构并不稀奇，但关键在于是否敢于做出重构的决策。能否重构是一个技术判断问题。重构不仅仅是代码的重写，更是对代码质量和系统架构的一次深思熟虑的决策。

叠加管理的必要性

在深入思考系统重构、更新、团队改变以及真正的管理实践时，我们会发现这些活动实际上考验的是一个人的综合管理和决策能力。无论你是程序员、团队领导、中层管理者还是高层技术管理者，最终都会面临这一挑战。

首先，最重要的考验是能否适应快速变化的环境，无论是技术环境还是市场环境。在公司环境已经处于困境时，如何决定投入多少人力和资源去改造系统，这是一个难题。比如，在产品力和市场力都不足的情况下，向老板提议进行微服务化改造，老板可能会因为不懂技术而同意，但一旦失败，最终可能会归咎于研发能力不足，导致人员更迭。

其次，商业需求和其商业价值的判断同样重要。有时人们认为技术人员不需要了解太多商业逻辑，但实际上，技术人员也需要具备一定的商业和产品思维。在中国，开发模式似乎逐渐变得类似于日本模式，即文档详细到函数定义和变量定义，然后打包发给外包的程序员实现。这种模式导致开发周期以年为单位，效率低下。

程序员有的时候地位突然的相对较低了是为什么，因为他们无法决定需求是否值得做，而是做不做由不懂程序的人（如产品经理）说了算。这些人可能是“导演系”毕业的，他们想出的大数据模型或 AI 模型可能并不切实际。如果程序员花费三天时间去实现这些不切实际的想法，那显然是没有意义的。

改变这一状况的关键在于让程序员建立商业思维和产品思维，让他们更多地接触这个世界，理解为什么要这样写代码，而不是仅仅按照要求去写。这样，整个团队的效率将会是最高的。包括创新优势和人才培养在内的所有管理实践，实际上都是基于这些基本原则的动作，需要我们在实践中不断平衡和调整。

技术和管理的平衡

机票目的地盲盒项目案例

几年前，我们做了一个引起轰动的产品。这个产品的需求量非常高，当时认为这是一个非常成功的技术管理案例。从公司对外的正面宣传来看，这是产品经理和市场运营团队想出的绝妙点子，设计了一个非常棒的产品，吸引了数亿人的注意力，并参与了进来。然而，从技术人的角度来看，这件事情其实是无意中踩到了一个坑，却意外地发现了黄金。我们为什么会无意中去看这个产品呢？因为我们做了成百上千个类似的产品，而这个突然爆红了。

大家可能会问，这和技管理有什么关系？实际上，这个产品最初的三个网页是由新人编写的，因为产品众多，成本最低的做法就是让新入职的员工练手。每天都有几个产品经理早上想出点子，下午就想上线，第二天可能就下线了。但这一次，流量突然上升，导致一个网页崩溃。作为技术管理者，你的决策是什么？是简单地修复一下，还是增加两台机器？因为当这种活动爆红时，流量的增长是指数级的，可能一天之内就从 100 个访问量激增到 100 万，甚至更多。这时，竞争对手也开始模仿，你需要在上面进行迭代和改变。

在这种情况下，技术管理者必须做出决策。如果系统不能支撑，那么就需要加班重新编写。通常都是这种情况。当时，一个活动从 100 个访问量激增到 5000，感觉这个活动要火。召集运营和产品开会，但他们都表示无法判断这个趋势。那么，我该如何决定是否增加系统资源呢？他们建议去问大老板，但作为技术，这是我的责任，我需要做出决策。

我当时的想法是，这个产品可能会爆红，现有的结构不适合，因为这个结构没有未来，只是写死了几行代码。因此，我立即在管理群中发出指令，要求团队立即回公司。那天是节日前一天，晚上 10 点，我发出了指令，各团队的负责人也回来了，他们同样发出了指令，要求部门的员工不要离开。当天晚上 11 点，我们开始重构，快速地先堵住了漏洞，第二天早上，访问量果然激增。

这个决策是基于我对业务的判断和经验。有时候，管理是有艺术的，这种艺术可能带有一定的风险。但作为技术管理者，首先要对技术有执着，要相信技术能够解决问题。如果技术能搞定，那么就要思考如何利用技术解决问题。当时我的决策是基于这个信念，我相信我们能够在一夜之间完成重构，即使从晚上 10 点开始，第二天早上也一定能成功。基于这个信念，我们做了减法，集中精力解决了关键问题。

以下是可以吹牛的内容

当然，后面这些事情都可以作为炫耀的资本，如下图所示，甚至连 AI 都派上了用场。这实际上是技术为产品赋能的一个例子，也是整个事件最终的驱动力。市场的负责人询问我们是否可以进行市场投放，因为上午已经有海量的流量，他们想要加大投放力度。我告诉他们，没关系，系统性能是 OK 的。随后，流量不断攀升。尽管外表看起来我们仍然只有三个页面，但背后的技术已经完全不同了。技术团队通过快速的技术迭代和优化，确保了产品能够支撑起巨大的流量压力。

技术与管理的失衡

在技术管理中，我们经常会遇到管理失衡的问题。有时，这种失衡表现为过分追求新技术，或者过度依赖所谓的技术驱动，这可能会导致项目失败。技术驱动本身并不是问题，但如果不结合商业逻辑，可能会导致公司走向错误的方向，甚至陷入困境。

技术驱动在某些场景下是有益的，但这种场景的选择需要基于对商业价值和公司当前状态的准确判断。只有当这些条件都满足时，才应该考虑实施技术驱动的策略。技术管理者需要理解，技术只是实现商业目标的手段之一，而不是目的本身。

面对的挑战

管理中的挑战众多，细节往往决定了成败。首先，时间管理对于技术管理者来说至关重要。例如，我的一周安排得非常紧凑：周一要评估业务的技术可行性，周二要完成所有团队的技术复盘，周三要前往另一个城市的研发中心检查技术状况，周五则要审视分管业务的进展。在这种情况下，如何有效管理时间呢？本质上，这取决于你对技术的判断力，它决定了你的时间利用率。如果对某项技术判断不下来，总是犹豫不决，那么再多的时间也不够用。真正有效的管理，是基于你对技术的深刻理解和判断力。

风险管理也是技术管理者必须面对的问题。技术人员容易陷入的一个陷阱是，当业务提出第一个产品需求时，就全盘接受并迅速投入工作。但需求中途变更，导致工作量增加，进度延误。这本质上是一个风险判断问题，你需要对业务需求的稳定性和合理性做出预判，并据此做出相应的计划。

绩效管理也是一个挑战，特别是如何公正地给予低绩效评价。一个人得到好评当然高兴，但如果得到低分，即使有 360 度的全方位考核，最终他怨恨的还是你。因此，绩效管理需要直接和坦诚，告诉员工他们的表现未达预期，并提供改进的方向。如果员工仍然无法理解或接受，那么可能需要考虑放弃他，因为团队不能等待一个人的成长。

最后，融合技术与管理，保持技术人的初心，是技术管理的最终驱动力。技术不仅是实现目标的手段，也是管理的原始动力。技术管理者需要在技术追求和商业需求之间找到平衡，确保技术投资能够带来实际的商业价值。

演讲嘉宾简介

王晓波，同程旅行出行事业群 CTO，专注于云计算，高并发互联网架构设计、分布式电子商务交易平台设计、大数据分析平台设计、高可用性系统设计。完成同程基础架构建设，私有云系统建设，主要基础中间件研发。拥有十多年丰富的业务技术架构，基础架构经验，深刻理解技术驱动力的重要性。

会议推荐

在 AI 大模型技术如汹涌浪潮席卷软件开发领域的当下，变革与机遇交织，挑战与突破共生。2025 年 4 月 10 - 12 日，QCon 全球软件开发大会将在北京召开，以 “智能融合，引领未来” 为年度主题，汇聚各领域的技术先行者以及创新实践者，为行业发展拨云见日。现在报名可以享受 8 折优惠，单张门票立省 1360 元，详情可联系票务经理 18514549229 咨询。