李昊：从技术到管理，如何实现螺旋上升？

作者 | 李昊    

出品 |  《》编辑部

从开发者到技术管理者应该如何提升能力？在李昊看来，开发和管理之间的“鸿沟”并非很难跨越，他将从“深入理解基层技术管理岗位角色、纠偏对技术管理者的认识误区，以及通过日常执行层真正做好管理”三个维度，给初为管理者的开发者一些入门指南。

自Marc Andreessen在2011年提出“Software is eating the world（软件正在吞噬世界）”，十余年来，在“软件+互联网”的驱动下，各个产业实现了深度融合。对于开发者来说，通过深入产业的大量实践，其设计硬件、编写软件、扩展架构等技术能力获得了迅速提升，甚至在一些核心技术上取得突破性的成就，让国产IT技术从赶超者变成了引领者。

然而，在各产业面临进一步转型升级的当下，我却产生了很强的忧患感，我们急需精进技术管理能力，但不得不面对人才稀缺，特别是基层管理人才缺失的危机。

对于刚入行管理的开发者来说，最缺乏的还是基础管理技能，这取决于对岗位的理解是否透彻、如何处理技术与管理之间的关系，以及如何正确认识管理工作。如果尚未把这三点思考清楚，很可能忙碌一天发现自己只是在处理各种被动的突发情况，很难有主动的创造性。长此以往就会有种只是在“打杂”，而非真正把控组织的管理提升之感。

我从开发岗到管理岗，也经历了一段适应期。我自己的感受是，开发和管理之间的“鸿沟”并不难跨越。一旦理解自己是管理新手，并认定这是我选择的新职业通道，就可以很好地和“我今天啥也没做全打杂了”的感受和谐相处，进而开始认真学习管理，练好“听、说、读、写”的基本功，让自己看明白、说清楚、做正确。随着自己管理的团队取得不错的成绩，我获得了比只是写代码更大的成就感。

李昊，曾在IBM、Ericsson、Myriad等公司从事嵌入式、服务器端和客户端系统的研发及团队管理工作。2013年创业，先后在TestBird、货车帮、西瓜创客等公司担任产研负责人、CTO等技术高管角色，目前在FITURE负责增长。

作为过来人，我也想把自己的思考与心得分享给更多管理新手，通过分析技术管理者这个角色的核心痛点、难点，结合我近十年在管理不同规模产研团队过程中得到的经验和教训，为大家总结从个人贡献者到基层技术管理者的职业转变中需要了解的相关知识和技巧，希望能帮助大家把管理之路的第一步，走稳、走好。

本文节选自《新程序员004》 『纸质书+电子刊』已开启预售

如何正确认识从开发者到管理者的角色转换

在进入主题讨论之前，我先简单谈谈自己的经历。

我是技术出身，进入管理岗前，在外企做到了Principal Engineer（首席工程师）。之后意识到如果想研发出更具创造性的技术必须从更多维度去了解产品和业务，于是我就开始做技术管理。一段时间之后，又转回了研发岗，就这样在做技术和做管理之间转换了几次。

后来，我发现如果真正想把产品和业务做好、做通，作为管理者最重要的是厘清技术与管理之间的关系，而首要的则是深刻理解技术管理者的角色。

理解基层技术管理岗位角色

万事开头难。作为工程师踏上管理岗位的第一站，可能会对基层技术管理工作的供需两端都存在误解。

在供给侧，大家进入管理层的机缘和意图是多种多样的。有些人因为专业能力强，在团队有话语权被推向了管理岗；有些人因为渴望服务于他人的成长而从事管理岗位；更多人则因为世俗的原因：升职，会有更多权力和收入的预期增长；甚至有些人进入管理层只是因为厌倦了被低水平的人管理，坚信自己做管理者可以做得更好。不管起心动念是什么，和以前作为个人贡献者相比，决定成为管理者的工程师将进入一个全新的、充满挑战的职业通道。

事实上，技术人在初入管理层时会面临这样的现象：只有少数公司真正愿意对管理能力进行投资和培育，特别是基层管理。它的起因主要在于有效的技术管理既需要技术能力，也需要管理能力，而这两种技能的培养需要大量的时间。于是就能看到很多企业会因为基层管理者的管理能力问题，小到出现各种各样的纠纷和摩擦，大到高层制定的技术战略无法被正确地分解和落地。

因此，要做好基层技术管理者这个岗位，首先要理解这个角色究竟意味什么。做技术管理者不是晋升，而是切换到一个全新的职业通道上，要对自己作为新手有足够预期，及时学习和补充欠缺的管理必备技能，包括：怎么提高团队效率；怎么考核团队绩效；怎么选、育、用、留人才和打造工程师文化；怎么分配自己的时间；怎么做好向上和向下的管理。每一个话题都很艰深。

技术管理离不开技术

基层技术管理的另一个难点在于软件开发的复杂度：可能在某个给定的时间点处于平衡，但长期来看软件开发仍然是动态变化的。比如，近年来容器技术带来的变化，并非出现了颠覆性的技术突破，只是一个微小的变化引发另一个微小变化，当一系列变化集中涌现时，一个新的生态系统就产生了，并被各种场景广泛使用。因此，和很多传统的工程领域相比，软件开发本身就是一个动态平衡的过程。

然而，软件开发人员很容易迷恋某种特定的技术或方法，甚至会形成技术栈的鄙视链。但现实世界中的软件构建并非二元选择，而是在各个细节上不断权衡。比如，后端用Python、Ruby这样的动态语言还是Java？CI/CD用自建的工具链还是现成的云服务？数据的采集、清洗和存储通过什么方式完成？要不要拆微服务，还是就做一个单体应用？这些问题都没有适用于任何条件的最优解，管理者必须有足够的技术判断力，才能根据项目、团队和资源的现状，选取合适的折中点来达到业务目的。

因此，要成为合格的技术管理者，不能没有扎实的技术作为保障，否则很难获得团队信任。只有让自己成为领域专家，才能参与设计讨论，发现计划中的差距或评估错误，从而解决技术冲突。同时，技术管理者还要很好地理解团队正在做的事情，并在工程师不在场时向其他人，特别是管理层阐释团队产出的价值。

还需要注意的一点是，技术管理者不一定要成为架构上的决策者（通常架构师做这件事情），但他们必须知道何时介入，以及由谁介入，便于推动问题的解决。

管理不只是“工作的一部分”

基于技术的重要性，很容易产生的误解是把“管理”当成技术管理工作的一“部分”，特别是基层管理者通常因为技术上异于常人的优势而被提拔。选择做管理之后，会有一段时间发现自己每天都被各种人和事打乱工作计划。每天精疲力竭地回家，却感觉一天下来没有做一件“有实际意义”的事，非常惶恐。这样一来，不少人会为寻找意义而回归研发一线，通过解决一个个具体问题而获得舒适感，结果让自己的管理工作变得更加脆弱，最终进入一个负循环。

这是一个没有正确理解管理工作，不具备管理技能带来的大问题。

初做管理时我也有类似的问题。于是，我记录了自己的时间分配，并且在时间块旁边记录当时的状态。很快我发现，自己还是花了很多时间参与编码，当我参与甚至负责核心模块，或者是解决阻塞性的技术问题时，我的感觉非常好。而当我花时间完成管理相关的工作，无论是按照商业目标分解团队目标，把战略分解成战术，积极推动、执行、落地，还是花时间理解员工的需求，评估员工的能力，为他们分配有挑战但又够得着的任务，打造他们的上升通道，总会感觉到疲惫，甚至是沮丧。

然后，我就开始有意识地调整自己的时间安排，一方面，系统学习管理的知识和技能，预留足够的时间完成管理工作；另一方面，逐渐退出核心模块的编码工作，只写工具或修补漏洞来保持对系统的了解。一段时间后，我发现领导团队有了更好的效果，大家都感觉到了成长，团队的成长也让我很有成就感，这就形成了正循环。

总之，管理不是技术管理工作的一部分，而是它的全部，一定要全心全意地投入支撑和服务团队的工作中来。

如何做好基层技术管理

在了解到基层技术管理岗位的角色含义后，如果你仍然有兴趣做管理，接下来需要做的就是具体执行。

从我自己做管理的经历来看，最初的问题主要是基础管理技能的缺失。可能一整天都会在安排团队工作、自己写代码，以及在各种提出意见、复盘、确认中手忙脚乱。

在这种情况下，一定要走出编码的线性思维，不能遇到什么做什么。究竟应该怎么做？我认为，分五个部分：确定时机；制定“标准动作”日历；做好一对一沟通；练好“听、说、读、写”的沟通基本功；沿螺旋轨道上升。

确定时机

基于专业知识的必要性，从事技术管理不宜过早。在我自己管理的技术团队中，P8及以下级别不单列管理岗位。假如你处于还未成为管理者的阶段，并有志于成为管理者，还是有很多事情可以做的。

首先，你可以读一些管理方面的书籍，比如Camille Fournier的The Manager's Path。然后，带着这些背景知识去识别自己所在团队管理者的管理风格和手法，从中学习。如果条件允许，你可以考虑加入公司内口碑较好的管理者所在团队，近距离学习这些管理者的管理技巧。与此同时，你还需要花时间了解公司的文化和成长阶梯，就像本文开头所说，不是每个公司都会重视基层管理者的培训。如果你发现公司搭建的通道和你想要的不太符合，要早做选择。

当你认为时机比较成熟时，就可以主动表达自己的意愿了。这里的窍门是不要等机会来了再表达，在你觉得自己准备好了的时候就可以说明。和上级大大方方地讲自己的想法和计划，同时也留意公司内其他团队的机会。

制定“标准动作”日历

成为管理者后，你的时间会被切割得很碎。这时，一定要在日历上制定一些标准动作，如每天、每周、每月的标准动作。完成这些动作后，你的管理质量就有了基础保障，就可以放心大胆地利用其他时间做其他的工作，特别是应对各种突发状况。

基层管理工作在组织、绩效、跨部门合作等方面参与较少，因此这些标准动作主要是关注流程和团队，可以按照时间段的短、中和较长期来划分。

短期：每天

• 了解团队每位成员的工作计划、进度和困难，可以通过站立会，也可以通过代码审核，当然也可以通过聊天的方式来完成，无论用什么方法，必须做到位。

• 参加至少一个技术讨论，看是否能理解并发表观点。不要组织或参与冗长无功的讨论，如果还处于定义模糊的阶段，最好线下面对面地讨论。

• 解决所有成员提出的问题和困难，这里的“解决”是说指明方向，而不是手把手教授。

• 查看团队成员提交的代码和文档，明确是不是在做“有用功”。

• 以身作则流程化，整理并跟踪所有的需求、结论、思路，多写文档。其作用是给自己捋思路，推荐用英文写技术文档，这样更简单明了，毕竟多数人的词汇量没有大到能够通篇“废话”的程度。

• 做好负载均衡，把事情均匀地分配给团队成员，确保没有人同时负责太多并发任务。每个人应该专注在一两件事情上，如果发现有人停滞不前，应该主动疏通调整。

以上这些事情因为要每天做，所以最好借助系统工具来完成，如“Jira+Confluence”或“飞书+Notion”。

中期：每周

• 审视整体进度，根据实际情况增加或延后任务。

• 和产品经理协作，做好任务的拆解，包括提前准备线框图等，确保所有人对任务的理解一致（包括界面细节）。

• 周报不要长篇大论。周报必须有结构，包括本周完成情况和归因分析、下周的计划目标，以及关键依赖或需要什么帮助。

较长期：两周

• 找到感兴趣的系统细节，深入了解和思考其中的逻辑，与负责这部分的成员深度合作，或者在自己完成框架的基础上找到这部分负责人继续完成其他细节。

做好一对一沟通

和员工定期一对一沟通，就像开车出远门检查油箱还有多少油一样，非常重要。但员工身上没有仪表盘让你能够读数，那么，一对一沟通具体怎么做呢？

一对一沟通总体有两大类，一类是跟直接汇报给自己的人沟通，一般每个月都需要做。当公司有重大变化时，则不拘于频率，按需沟通。

另一类是跨级的，这对你的管理也非常重要，特别是针对新员工和即将转正的员工。不同的沟通对象要准备不同的内容。有两个核心技巧：第一，搞清楚由谁主导对话。大多数时候你要有自己主导对话的准备，但也有些时候员工想要说更多，就应该让他们尽情表达。从一个轻松的话题开始，看看他/她是不是有表达欲望，如果有，那么本次沟通应该是你倾听为主。第二，以下我列出了一些适用于沟通的问题，但都只是纲要而不是“台词本”。你可以围绕这些问题发现背后想要了解的内容，自然轻松地聊天，同时，一定要仔细记录和跟进对方的反馈。

对所有人都适用的问题：

• 你状态还好吗？进展是否顺利？

• 在做事的层面，有什么是我可以帮忙的？

• 在和其他人协作的层面，有什么是我可以帮忙的？

对于刚加入的新同学：

• 你遇到过什么问题吗？

• 入职流程有什么可以改进的地方？

• 有没有想法想分享给所有人？

对于即将转正的成员，除评估工作进度外，核心是建立沟通模式：

• 哪些事情会让你觉得状态不好？

• 我可以通过什么办法知道你状态不好？

• 在状态不好时我可以怎样帮助你？

此外，还有针对入职一段时间的成员可以提的问题。

每次都可以提的：

• 我观察到你在做的事情，我有一些建议。

• 你的合作方对你的工作有这些反馈。

• 哪些地方做得好/不好，可以怎么改进。

• 什么样的1:1更有价值。

每个月可以提的：

• 有没有好奇或担心的变化需要我解释？

• 有没有听到或感受到的事情需要我确认？

• 让我告诉你一些可能会影响你和你团队的信息及决定。

• 让我们讨论更广泛的组织发展目标和方向，确保你的目标和公司的目标一致。

每个季度可以提的：

• 今年的目标是什么？最近三个月的目标是什么，完成得怎样？

• 需要从我这里得到什么帮助？

• 需要从团队得到什么帮助？

• 需要从团队外部得到什么帮助？

学习和成长主要有四个目的，包括有新的且更具挑战性的事情可做、能够主动和团队交流及沟通互助、营造公平向上和开放进取的团队氛围，以及定期定时、清楚明确地进行绩效反馈，确保进展顺利。

这里我需要再强调一点，一对一沟通成功的前提是双方有信任感和安全感。如果关系不熟，可以先从爱好、感受、未来规划等事情开始聊，不要强行问上面的问题，会让沟通对象有压迫感，也不会得到他们真实的想法。相信我，只要把上面这些工作做到位，你已经是相当不错的基层技术管理者了。

练好“听、说、读、写”的沟通基本功

在管理中有一个“第一团队”和“第二团队”的概念。

很多初做管理的人可能不知道，自己的平级以及汇报对象才是“第一团队”。而汇报给自己的人以及他们的下属其实是 “第二团队”。如果记录你在这两个团队中花费的时间，往往会发现，花在第二团队的时间占绝大部分。而实际上，能不能和第一团队对齐目标、协同作战，真正做好第一团队和第二团队的衔接，是在做管理岗后职业发展通道的第一道坎。

怎么迈过这道坎？我认为最重要的是提高自己面对冲突和压力的能力。大部分做基层技术管理的同学花过多时间在第二团队，说白了，是因为自己在树状结构的顶点，在里面待着比较舒适。而成熟的基层管理者，不仅要主动解决组织中的冲突，甚至常常刺激良性冲突发生，以促进组织目标的达成。

要完成这样的转变，首先要练好“听、说、读、写”的沟通基本功，提高自己获取、过滤、筛选信息并把观点简明扼要表达的能力。然后，要对如何提问、倾听、表达，以及高效达成共识等方面进行刻意练习。在这个过程中，要增强对情绪压力的认识和了解，体察自己及同事的压力和情绪状态，真正把冲突和压力转变成充分表达想法并形成团队合力的机会。

总之，只有走出自己的舒适区，与第一团队充分沟通，了解公司的战略、战术方向，清楚各种决策的上下文，才能有针对性地推动第二团队做正确的事，正确地做事。

沿螺旋轨道上升

回顾我自己和很多朋友的职业发展道路，我还想给基层技术管理者一个建议，就是技术管理和技术专家两条职业通道并不是对应关系。也就是说，并不是做了基层技术管理者，就只能沿着这条路走到黑。

正好相反，最好的工程师往往是做过一些管理工作的，因为他们更懂得沟通，更有成本意识，更注重交付。最好的管理者往往有2-3年在一线做技术的经验，因为他们更有技术手感，能和团队良好沟通，也能做更高质量的判断和决策。

因此，好的技术管理者和好的技术专家，发展都是沿着螺旋轨道上升的，看起来可能一会儿往西，一会儿往东，在两个通道中来回切换，但因为两部分的知识和技能都得到了扎实的发展，整体前进的潜力会更大，步子也会更稳。

当然，想要有这样的心智，在信奉“学而优则仕”的环境中不太容易。如果你从心底接受管理不是晋升的理念，就很容易接受从管理做回工程师不是“降级”。相信经过两、三个这样的螺旋上升，你就可以成长为驾驭复杂团队和系统的成熟管理者了。

结语

目前，我在公司内部的管理角色从产研切换到了增长，我将主要的管理规划称为“打通三套语言的目标管理体系”。实际上，无论在哪个公司，我都认为一直存在着三套语言：客户视角的语言（需求、痛点、体验）；产品视角的语言（特性、流程、版本）；业务视角的语言（获客、留存、转化、利润、收入）。

我曾有幸管理过大量异构团队，希望能通过一些方法和工具，在公司内让大家从需求的产生，到产品的设计，到最终商业结果的达成，形成一套完整的目标管理和执行跟进体系。

从微观到宏观，对于每一位想要成为技术管理专家的开发者来说，都需要从底层认知开始挖掘。本文主要面向初入管理岗位的基层管理者，该阶段需要习得很多知识和技能，也伴随着焦虑和压力。

作为一篇通识类技术管理文章，首先希望帮助大家理解管理岗位的特点和难点。然后从时机选择、日常管理动作，以及如何进入第一团队等方面，给出了一些具体建议和行动指南。

技术管理作为一门发展了上百年的学科，要融会贯通，需要相当长的学习和实践。但我相信，只要在从事基层管理时就有正确的认知，经过不断努力，每个人都可以成为一个成熟的管理者，在职业发展中收获丰硕的成果。

— END —

本文节选自《》，从MySQL之父、MariaDB创始人 Michael "Monty" Widenius，到PostgreSQL全球开发组联合创始人Bruce Momjian、阿里巴巴副总裁贾扬清、指令集创始人兼 CEO潘爱民、著名科技作者吴军，再到 Vue.js 作者尤雨溪……《》以「我们的技术时代，我的程序人生」为主题，与多位国内外知名的技术先锋和新生代程序员代表进行了深度对话，希望行业优秀人物的技术之路与人生感悟给大家带来启发。

新程序员读者俱乐部限时开放，欢迎大家扫码入群！