技术人穿越周期的生存之道是转型管理？｜展望技术管理者的 2023

2022 年，似乎裁员事件很少涉及到管理层，而且职场中年，做管理比做技术更安全？那么我们应该不应该转型管理？另外，在 2023 年里，对于已经在管理岗位上的人员来说，应该如何审视自己的职业发展和定位才能走的更顺？

在 InfoQ 一年一度的《年度技术盘点与展望》系列节目中，我们邀请到了戴尔科技集团软件工程高级总监滕昱，畅聊技术管理者的技术成长路线与职业发展路径等话题。

完整内容可点击查看回放视频：

https://www.infoq.cn/video/vPs34zSoBK2Yku08Iyme

滕昱：首先欢迎大家今天来参加我的直播，回顾我自己的职业生涯，算到 2022 年末我已经从业了整整 20 年了。而整个经历可大概分为三段：2002 年加入 Konami 公司，大家如果玩电子游戏会知道这家公司开发了魂斗罗 / 合金装备等一系列大名鼎鼎的游戏。不过入职大概一年后，我发现自己并不适合游戏开发这个领域，于是果断跳槽；2003 年加入 LSI logic，这是一家半导体芯片公司而我当时选择的是 Firmware 开发方向。大概 3 年以后我在 2007 年加入 EMC(现戴尔科技集团) 开始第三段长达 16 年的工作经历。我在戴尔科技集团主要经历是设计开发分布式对象存储并支持产品的全球商业化运作。

现在我们回头去看，大家都会把 2006 年当作云计算的元年，而对于存储界来说最重要就是 AWS 发布了 S3 存储服务，所以从那时候起一大批优秀的对象存储产品就逐步出现在业界之中，其中就包括我所参与的戴尔科技集团前后三代产品，并一直保持 Gartner“分布式文件和对象存储”的魔力象限领导者地位。

而我的“额外”任务是在 2016 开始拥抱流处理领域开源浪潮，加入了戴尔科技集团的流存储 (Streaming Storage) 开源项目 Pravega。并和同事一起最终将该项目贡献给了 CNCF 基金会。在这个过程中，我学习到了开源的理念并也结识了很多开源界的朋友，比如 Flink/Iceberg 社区一些早期开发人员。同时也开展了一些 Pravega 中文社区工作。

滕昱：首先纠正一下，作为全球化开发团队的一员并且直接负责支持大客户的我来说，其实也是无法避免在 8 小时之外上线救火，毕竟作为一家面向 500 强企业解决方案的公司来说，保证 SLA 的执行是最重要的事情之一，而这就包括在半夜紧急上线去响应 S1 的 Case(30 分钟内必须响应)。所以为了保障对客户“n 个 9”的承诺，我们是不可能 100% 避免在八个小时之外工作的。

所以我理解这个问题其实想问的是如何看待“制度化”加班这个现象的。先给出我的答案，这取决于你的公司或项目处于哪个发展阶段而定。其实软件开发活动和所有其他人类经济活动一样，也是要遵循基本客观规律的。当公司或者项目处于初创阶段，所谓 0 到 1 的阶段，比如才拿到第一个大客户，那么万事草创，个人和团队投入更多时间是有非常大的边际效用的，即使是多投入一个小时，所带来的回报也是能看得到的。

但是天下所有的产品或者项目最终都会只有两种结果。一种是转变成一种成熟产品 / 商业模式 (如按照华尔街的说法，就是是否有 10 亿美元的营收)。另一种结局就是死掉。所以成熟模式不仅做到是 0 到 1，而更是要完成 1 到 10 的蜕变。然而在 1 到 10 阶段，如果只投入更长的劳动时间的话，带来却是的是边际效益的急剧下降。因为这阶段项目 / 产品的客户基数变的非常大，而增长实际上每年变的只能能有 20%-30% 甚至更低。所以此时遇到的问题大多是无法用简单堆人力就可以解决的。

鼓励“投入更多时间来工作”是解决特定阶段问题的“银弹”。但盲目使用地在本不该使用的阶段，最终可能导致整个团队分崩离析 (毕竟人不是机器) 和商业模式的失败。也就是我们反反复复说到的“没有银弹”这句老话。如果大家去稍微了解下业界那些大型的软件公司，大家其实都心照不宣的区分了这两个阶段，也算是业界的一点共识。

具体到我自己的经验来说，有两点可以和大家分享：

1. 我会给我团队的所有成员设置一个共同的 KPI，那就是每年除公共假期外，每个人至少计划 2 周不带电脑的休假。

2. 减少会议，每周最长会议控制在一小时之内，80% 控制在半小时。每周五下午不安排会议 (这其实是全球整个工程师团队的最佳实践)。为什么要这样呢？因为我们作为一个普通人是被潜意识中的期望所管理的。我们的焦虑很多时候来自于对未来的无法计划和掌控。一旦设置了正确的休假期望值，把时间控制权交还给员工后，假以时日，你会发现大部分员工潜移默化地提高了自己的效率。例如控制好会议时间后，员工会自觉的在会议前做好充足的 homework(家庭作业)，甚至已经私下就大部分内容进行沟通并达成共识，这样会上就不会过度发散，从而最终提高了会议效率。而这其实就是明确好 8 小时以外时间归员工所有带来的“看不见”的效率提升。

而更神奇的是，我不止一次的发现，很多工程师在休完假后，会提出很多“out of box”的想法和设计。而这些想法往往是天天埋在办公室里，并奔波于会议中的工程师无法得到的意外之喜。也许完全放松后，人们更容易灵感一现，说个笑话，牛顿是在苹果树下 (很有可能是下午茶时间) 而不是办公室里 (这样也没办法被苹果砸到) 发现的万有引力规律。

要知道，休假在口语中我们都习惯都用 Recharge, 重新充电来表达。也就是意味着放松心态跟自己 / 家人在一起，而我们都明白家人是我们最大的心理安全感和未来确定性的的来源，如果不将足够的时间给到家庭和自己，长此以往，他们 / 她们真的能很持续不停的高质量输出吗？我个人觉得这个答案是否定的。

滕昱：我首先回答难在哪里吧，因为大家处于细分行业，以及产品项目具体的阶段不经相同，所有到底需要做那些事情和那些能力在细节差距会比较多，但是难点却是放之四海而皆准。

真正的难点其实就是大家一提到技术管理，自然把注意力集中在“管理”这个词之上，进而认为一旦自己被赋予了“管理者”这个角色，会自动获得一种神奇的魔力，即所有事情只要自己计划好，执行中亲力亲为，最终这个项目或是产品就一定会大概率获得成功。但非常不幸这是错误的理解，而明白这点这就是技术管理最难的一点。

在现实中，由于我们身处一个高速发展的产业，技术产品理念迭代可能远超其他领域，在我看来技术管理更像在惊涛骇浪上航行的船长 / 舵手，只拥有一张航海图和罗盘是远远不够的，更重要是技术领导力，即如何带领你的团队在各种变化中不停修正方向，最终到达原设定目标。即通常意义上项目或产品营收增长。

所以在我个人经验中，解决这个所谓难点的一个可能办法是要将“管理”这个带有从上往下俯视概念的词从我们的脑海中划出去，而把自己转变成平行的团队技术领导者。既不是“身处高位”只发号施令，也不是陷入细节泥潭的控制者，而是转变成技术方向的领导者，带领大家去完成目标。这样的技术领导者的作用就和船长和舵手一样，能为团队指引一条路，并发动每个人朝着这个目标一起努力。并且放手让准备好的成员成为新的领导者，达到技术团队的成长壮大。

软件行业本质是千变万化，许多一开始非常好的项目往往都只是昙花一现，一旦做错了一次技术选择，衰落起来是非常快的。所以作为一个技术领导者，如果不能敏锐的看到行业未来几年的发展，做前瞻性的领导力预测，是不能为团队做好指引的，也就谈不上给团队成员带来成长机会。

下面举个我职业生涯中一个具体的例子去分享一下我如何做技术前瞻性预测并帮助提升技术领导力的：

我做了 16 年的分布式对象存储，其实在 2016 年~2017 年时候有一个很大的难题摆在我的面前，也就是对象存储的未来在哪？要知道业界那个时候对象存储还主要被定位于“二级存储”，“冷存储“，虽然可扩充性很好，但基本上用于存储海量图片或是历史数据归档这样的用例。但是这样的定位，是很难帮助客户产生大量的商业价值，从而导致对象存储本身也是不温不火。所以当时我面临的最大的需要回答两个问题是:

一是你是否相信对象存储会变成大数据处理领域的主存储，服务于最“热”那部分数据。

二是你要在在技术产品上要做哪些准备来迎接这个趋势的到来

第一个问题的答案是肯定的，因为我相信任何一种技术的成功与否，最终取决使用它的人数。开发人员总是倾向于自己最开始接触的技术是这个世界心照不宣的秘密。对象存储在 2016-2017 年时，离开 AWS 发布 S3 已经过去了整整 10 年，第一代使用 S3 开发应用程序的程序员正在成为我们的客户，并且成为我们的企业客户中具有技术选型话语权的的 Tech Leader，VP 甚至 CTO。

所以对象存储这个技过去了十年并且没有消亡，并也有了一定的发展。当时我按照第一性原理判断，既然有那么多的技术人员熟悉它，那么它大概率会成为未来大数据或非结构化数据的主存储。这里的第一性原理也是大家为什么投入开源社区的原动力。精炼成一句话：你只要抓住了技术人员，实际上就等于你就抓住了未来的商机和客户。因为这些技术人员在他们公司产品选型的时，他 / 她总是会偏向于自己熟悉并投入时间学习过的技术。

那么对象存储是否具有成为主存储的潜力呢？我当时两个分析是：

1. S3 是基于 HTTP 协议的，具有最完全的网络访问潜力。

2. 相比较 POSIX，S3 移除了很多传统存储接口语义上对于“并行”的限制，具有天生“scale-out“的潜力。

所以我认定对象存储在技术和语义上是满足成为大数据处理领域主存储要求的。而唯一的缺点就是基于当时的商业用例，业界并没有把适当的硬件加速功能用在对象存储上。所以我开玩笑说，2014 年 -2015 年 Kafka 兴起就完全是打了一个对于对象存储的时间差，因为那时候的对象存储没有办法支持对于海量尾数据低延迟的读写，所以我们不得不用 2 套存储系统来把实时数据和历史数据区分对待，而留下的历史问题 (lambda 架构) 直到今天也没 100% 解决完。

那么基于以上两个原因，在肯定对象存储会成为大数据领域的主存储这个前提下，我要做是让前瞻性的预测顺利在产品中技术落地。那么我同时注意到最近 10 年一个非常重要转变就是外设速度和 cpu 速度差距的极速靠近，以至于最终诞生了 arm 架构的 DPU 这个趋势，而此趋势在 2016 年 -2017 年瓜熟蒂落的结果是 2017 的 AWS re:Invent 上宣布的明星产品 Nitro。所以我也一拍即合判断出这个技术完全可复用在分布式对象存储上加速 IOPS 和吞吐量。而后来用户态编程，RDMA/NVMe 技术发展也完全验证了我的判断，在网络速度从 25Gb 到 100Gb 甚至现在展望 400Gb 过程中，对象存储也伴随着一飞冲天了。

如果我们事后诸葛亮一下的话，Snowflake 差不多也是在 2016 年开始使用对象存储做为数仓的“Primary storage”，大家可谓是所见略同。而且这几年开始大家甚至可以开始看到 HTAP 系统也会开始转向使用多云架构下的对象存储了。

而在这一过程中，“管理”其实就变成了技术领导力的一个附带 buff 了，难题迎刃而解。

滕昱：这个问题其实在技术管理难点那里已经回答了，我的答案就是不要成为这两种类型中的任何一种，而是要成为一个技术领导者。不过还是让我们稍微分析下这个两种类型的管理者各有什么问题

1. 任务分包者 / 进度整合者：这是一种常见的团队管理方式，以至于我们一提到管理工作就会想到这个类型。这类管理者会将任务分配给每一个成员，列出具体计划，设定任务的提交期限，最终将团队成员的成果合并起来并及时汇报。毋庸置疑，这样的管理者还承担对外沟通工作并根据结果再次用任务分配来“管理”团队。但是这样的管理者可以被称为合格的“技术”管理者么？实际上任务分包者 / 进度整合者的价值只是所管理的组内成员价值的总和，而对企业而言的他 / 她自己的附加价值则很难体现，最终导致工作虽然很繁重但可替代性很强，离开平台后价值可能急剧下降。

2. 细节掌控管理者：细节掌控管理者会将自己与每个团队成员捆绑在一起，每件事情都要百分百的参与和掌控，将自己很大部分的精力都花费在审阅甚至直接接管下属的工作上。诚然这样管理者可能不容易被取代，但是当需要管理的人数多起来后，细节掌控类型管理者很容易被“管理工作”压垮，因为这本质上不是个可扩展 (scale out) 的领导方式。但职场中这种类型的管理者也是相当多数，特别是工程师出身并转向技术管理的管理者都需要渡过这个阶段的考验。甚至有相当一部分管理者最后被管理工作压垮只能被迫放弃管理道路。同时因为这样的团队中每个团队成员发展都会受到这样领导者“带宽“的限制，很多情况下会影响团队士气，最终造成离职率居高不下。毕竟，没有人在职场中喜欢一直被当作“新手”，也不会喜欢一个“保姆”型上级。

滕昱：首先，我可以非常清楚明确的告诉大家，10X 程序员是普遍存在的。但是可能和大部分人理解不一样的是，我所认识 10X 程序员全是在有扎实技术能力之外，还有着超强的沟通能力和超强亲和力的人，而是不是那种大家脑海中那种只埋头写代码不交流的代码狂人。

让我们回到软件行业的本质: 一种人类经济活动，其根本在于如何成为人类世界和计算机世界的桥梁 (bridge) 去解决问题。涉及到如何理解你所面对市场和客户，如何说服你的合作伙伴、投资方、VC 或者你的上级。一个合格的 10X 程序员往往会将 80% 时间花在和人的沟通上，20% 时间留给计算机。因为相对于人类沟通的复杂性，计算机世界容易掌控的多了。《人月神话》中有一个经典的论断：往一个落后的项目中投入更多的人会造成这个项目更加落后。为什么？其实道理是加入更多开发人员之后，人与人之间沟通变得更复杂了，指数级消耗后最终造成整个项目进度更加的落后。这也侧面佐证了软件行业中沟通所占比重之大。

甚至在我们刻板印象中觉得一些在生活中有可能并不善于沟通 (当然只是我们觉得) 开源社区的程序员，但是你会发现在他 / 她在所有参加的开源社区里面活动中，比如的 PR review/Issue review 里面其实都是非常健谈的一个沟通者。在这里我举一个例子大家都熟悉的 10x 甚至是 100x 程序员的例子：Linus Torvalds:Linux 和 Git 的这两个最伟大的开源产品的创造者。但我认为实际上他是这个星球上最成功的项目管理者之一了，我自己曾经比较深度的参与过 2.4 到 2.6 内核那段时间的 LKML 的讨论。我非常佩服他的沟通协调能力，用他自己方式将横跨这个星球不同组织 / 公司的开发人员管理起来，带领 Linux 这个奇迹从一个成功走向下一个成功。

滕昱：其实回答这个问题，我认为更重要的是要搞清楚技术管理是否真正适合自己，实际上如果你对整个业界在 2023 年的展望不是特别有把握的话，那么在这个时候贸然选择管理路线其实是有降低自己的职业安全感 (job security) 的风险，因为公司对于管理人员的期望和技术人员是不一样的。我这边有测试自己是否适合做技术管理者的 3 个小问题：

1. 是不是能接受“不可控性”才是唯一的的常态。这点对技术出身的我们来说其实挺有挑战，因为我们的潜意识是觉得程序一定会按照自己设计好的样子完美的运行。所以我作为管理者，团队也必然会按照我设计好的方案去运行。可惜的是这个想法完全错误。一个最直接的例子是每个技术管理者都会面临核心人员流失的问题。员工离职原因千奇百怪，这是你无法控制的甚至无法知道背后真正的原因的，而由此带来项目的不确定性，你真的准备好了么？

2. 是不是有很好的心态去持续接受负面情绪。随着你在管理岗位上越走越远，你每天接受 60%-70% 信息都会偏向负面，因为有问题都会找船长 / 舵手。那是否有强大的内心驱动力一直专注于目标也是很高难度的挑战。

3. 是不是在人群中有很强的主观意识成为讨论的焦点和中心。是不是有比较强烈的公开演讲的冲动，因为作为一个技术领导者，如何包装和推销你自己和你团队的故事是需要一定的人格魅力的。

以上 3 个问题以我的经验来说至少得有 2 项答案是“yes”，我才会建议你可以开始考虑转型做管理者。当然我们不否认有些技能是可以后天习得的，但是你需要先想清楚自己真的准备好了么？要知道，一旦转型失败重新做回技术人员的挫折对于大部分人来说是相当巨大的。

滕昱：这是个千人千面的问题，我不能给大家一个在所有的领域都适用的答案，但也许下面 2 点可能有一定的参考意义:

1. 最最最重要的是，是放弃看待技术管理者的魔力 buff 加持。With great power comes great responsibility。在业界流行多年的双线职业路线就说明，理论上管理岗位需求量更少，要求也更高。最重要一点是你会直面整个组织的不确定性，从本质上挑战人类潜意识中的安全感。此外，技术岗越到后面比管理岗可能更容易升职。管理者的升职，必须要有一个与之匹配的团队 /scope 去支撑，而不仅仅是技术能力的提高。所以在我观察到的不少海外同事中，是有相当部分的技术人员有意识不选择管理岗这条职业路线的。

2. 对于我们技术人员来说，也请有意识提高一下自己对于人与人之间沟通能力。尤其是面对面的沟通能力。首先，作为技术管理者需要和关键客户的面对面交流，理解最重要问题是什么，在软件开发领域我的理解是“店大欺客”是不存在，本质上唯一的护城河是性价比和沟通服务好坏。同时，技术管理者也需要与销售部门，产品部门面对面交流，这样才能了解业界需求的全部；并且，技术管理者更需要与上级、上级的上级面对面交流， 打造属于你和你团队的故事和位置并得到他们 / 她们的支持；最后，技术管理者更需要与架构师团队、技术骨干面对面交流，获得他们的支持 / 她们以及项目执行的第一手状态。所以我一直反复强调的是，软件开发本质是人类的经济活动一种，做为技术管理者，最重要的是和人的交流能力，而并不“只是”超强的编程能力。

滕昱：我非常幸运的旁观过 (但没有被直接波及到)2001 年 -2003 年间第一次互联网泡沫破灭全过程，感慨很多, 建议可能就是：

不管任何情况首先得“活下去”。可以自己做个简单的 review，比如看看自己团队平均每个人创造的营收到 1M(100w) 美元的安全线没有。这数字来自华尔街收购初创公司的不成文的行规，同时也被大家认为是一个项目大概率有资格活下去的安全数字线。只要能活下去，业务会好起来，股价也会好起来的。而现在很多伟大的大公司都是挺过了 2001 年的互联网泡沫破灭最后生存下来的，如亚马逊和 Google。

经济总是有 up 和 down，人生的机会也不是只有一次，所以在 2023 年的巨大不确定面前，永远不要放弃希望，不停地提高自己技术能力和管理能力，只要技术过硬，总是会找到下一步的机会。

滕昱：

1. 最重要是活下去，产品和商业模式都要活下去。

2. 保持一个好心态。把时间放短，人们看到的都很悲观，而把时间放长，其实看到更多就是乐观了。所以不要太焦虑，顺势而为。

3. 把时间更多的投入到生活和家庭中。因为你无法控制经济走向和工作好坏，但是你可以很大程度上掌控和你家人共处时间的质量。而我一直坚信家庭才是我们前进的力量和内心确定感的最重要来源。

滕昱：我想说的一个观点是：其实每个人都是人才 (talent)，但是都需要一个合适的舞台去展示。而一个好的技术管理者会尽可能给每个人找到 / 定制一个适合他 / 她的舞台，而在我过往的经验中，有很多次真的需要要给到他 / 她足够时间后，才会看到他 / 她真正的潜力。(当然这个时间一般也不会超过 2 年)。所以这里的关键是基于工程师这个群体大部分人自驱力比较高的前提下，你和你的组织有没有足够的耐心给员工提供足够的空间 / 时间去展现他们 / 她们的实力。

如果你对本文感兴趣，欢迎在文末留言，或加入 InfoQ 写作平台话题讨论。迷你书、专题已集合发布于 InfoQ 官网，登录 InfoQ 官网注册并将 InfoQ 添加进收藏夹，精彩不错过。

点击底部阅读原文访问 InfoQ 官网，获取更多精彩内容！