可悲的现实，大部分技术领导者可能并不称职

大家好，我是许晓斌，目前就职于阿里巴巴技术风险与效能部，负责运维与构建基础设施平台。在软件行业从业 15 年，包括微服务架构、DevOps、云原生等领域，软件管理工作 5 年。出过一本书《Maven 实战》，做 Java 的同学应该有不少人读过。

目前我在阿里巴巴带了多年团队，在实际工作中也有一些管理上的经验，但在准备 QCon 全球软件开发大会北京站的这个演讲主题时，在官网信息及材料中刻意隐去了自己的 title，我认为如果大家只是被 title 吸引而来，那其实并没有什么意义。个人认为，这个话题在国内也很少能有非常专业的分享。因为管理和领导是一种“专业”，它跟技术专业不一样，但它也是一种专业。众所周知，当下国内整体上是一个“业务为王”的时代，只要业务增长，管理、领导，甚至技术，做得好与不好都不重要。很多时候业务好和人的技术无关，和管理也无关，只是因为你恰好在风口，所以大家得意识到这一点。假设业务不增长了，该如何去量化一个管理者？如何去评估一个管理者做的好与不好？这是一件挺有意思的事情。

那这次演讲为什么讲管理？因为我见过太多糟糕的管理者了，包括我自己。

回顾一下我刚刚开始带团队的时候，可以用“稀烂”来形容。技术领导力其实非常重要，因为好的管理，它决定了公司的战略是否能够得到执行和落地；其次，它也决定了大量工程师的成长和发展。举个例子，如果你犯个技术错误，无非是一个故障；但是如果你犯管理错误，你对一个人的一年、两年甚至更长时间，会产生一个巨大的影响。所以这是一个非常关键的事情，需要重视。

但可悲的现实是，大部分技术领导者是不称职的。以下列举的几种错误模式在技术领域随处可见，基本都可以对号入座：

• 闷头干模式

延续独立贡献者的工作方法，所有方案自己做，所有代码自己写。

• 路由器模式

上级任务往下转发，任务结果收集汇报。

• 高压模式

对上过度汇报，对下持续增加，辅以不科学的价值宣导。

• 不决策模式

不对任何需求 say no，或者决策全部下放，并让下属承担决策后果。

• 有业务无工程模式

高度关注短期业务交付，不管工程质量。

作为管理者，你可以通过参考以上反模式来反思一下自己是否称职。如果你是一个“大头兵”，你可能感觉到自己老板不靠谱，时常被 PUA 到怀疑自己能力问题，但这些问题的根源并不是因为大家不想做好这件事情或者缺乏专业的理论，而是因为行业发展得太快了。以蓬勃发展的互联网为例，像阿里、腾讯等公司在短短十几年时间内从 100 人增长为 10W 人规模，这个时期产生了大量的技术管理者。然而，由于社会面缺乏既懂业务又懂技术、同时又懂管理的人才，只能通过内部提拔。但这些被提拔上去的人是因为管理做得好吗？大部分不是。他们成长晋升得很快，大部分是因为业务好或者技术好，但管理能力却不一定好。因此，这会导致这些人产生了一个错误的认知偏差，认为自己的成长和晋升速度很快，但其实本身的工程能力不足，实际的管理能力与其“总监”、“总裁”的 title 并不匹配。

事实上，很多时候业务的成功和他们的管理能力没有必然关系，换一个人也是同样的结果。业务的飞速增长是因为业务本身处于商业风口，或是因为商业战略、业务战略、运营战略的判断。

那么，如何进行管理呢？我自己也阅读了一些管理方面的书籍，并有一些实际管理工作中的经验和心得体会，可能不是最准确的，但应该还算靠谱。在本文中，我将删繁就简，探讨一些重要的事情。也希望能够通过本文得到一些反馈，帮助我更好地整理和思考。

我自己带团队的时间大概有五年多，总结下来，如果说技术领导者只能做好一件事的话，就是做招聘，挖掘人才。

那为什么是招人最重要？这个观点也出自于我现任的一位 Leader，大约三四年前，我们一起在杭州的 EFC 地下食堂吃饭聊到了相关的话题。当时，他问我，你觉得做管理什么事情最重要？我当时没有想好，沉默了一分钟没有说话，然后他看我笑了笑说，你傻，就是招人。

如果你正在带领一个团队或正处于一个团队中，发现团队里有一些非常棘手的或是痛苦的问题得不到解决，通常都能够最终溯源到某个人身上。比如我反思自己在团队中做得最成功的事情，我能够溯源到我招了一位正确的人，或者是我培养了一位正确的人；反思我做得比较失败的事情，或者是让我头疼的事情，都是因为这个人不是我招聘的，或者是不得不塞到我团队里的。

往往常见的情况是，老板给了业务后团队立马招人扩大规模，你想了想明年可能又可以晋升了。但实际上，一定要给团队招一个正向的人，即与团队目标一致、文化一致，能力一致。如果团队里某个人的专业素养不能支撑住在团队生存的时候，他必然会进化出一种其他方面的能力帮助自己在团队里生存。比如他可能特别“会汇报”、特别会“写 PPT”、特别会“搞东搞西”的一些事情来帮助他自己生存，因为他的专业能力无法跟上团队，为了不被踢出团队，所以需要进化其他能力。所以我后来就养成了一个习惯，就是在招聘的时候会将候选人专业素质的要求提高，我宁愿招不到人，宁愿业务不做或是做得慢一些。

那重视人才意味着什么？

• 你每周花几个小时做招聘 / 面试 /1-on-1 沟通？

• 你是否对每次面试都严格要求？会不会因为项目压力降低要求？

• 你能欣赏和你不同的想法和观点吗？

• 你有信心充分地授权，并敢于为此负责吗？

在招聘比较旺盛的时候，比如校招开始时，我每天平均会花几个小时的时间来做招聘和面试，和一些 1-on-1 沟通，并且不断地告诫自己，一旦招聘一个人，如果我很喜欢但是又有点犹豫，我就会判断可能哪里存在问题，就会放弃。在招聘过程中，首先我会非常的重视工程能力，比如会进行在线笔试，在线编码能力和历史代码等，一轮两轮三轮，不断地验证候选人的代码是否足够 Solid，讨论时是否足够 Opening，还会问一些明知对方不会的问题，去看对方是直接反馈不会，还是选择绕圈回答，比如有人绕了一圈后，最后结论是虽然我不会，但是我会怎样怎样。但其实我不需要对方去回答这些问题，我需要的是职业发展目标对齐，基本能力对齐，沟通简单，逻辑清楚，这几点要求我一直非常坚持。

到目前为止，我们团队在公司每年的 360 员工满意度调研中的分数都是不错的，这并不是因为员工进来之后我带领的多好，而是因为他们进入了合适自己的团队， 并且能够开心地工作，这是我认为比较关键的。

下一步，就是如何带团队。

带团队肯定要定战略、做规划。那战略目标如何落地？阿里是用的 OKR，我每个两周或一个月，都会去看我的 OKR 进展并进行更新。很多人的规划经常变来变去，可能过去一个月后做的事情已经和规划完全无关了，但我今年的规划相比去年，有 80% 其实是一样的，这是多重原因决定的，一方面是因为我认为我做的规划比较科学清晰，另一方面是整个组织结构比较稳定，比如没有老板天天换等等，这两点其实非常重要，实际上也应该如此。

我们的业务并没有多大的变化，我们是做工程的，平时的工作就是写代码的时候做发布、做构建、做运维，以及访问各种云产品等，这些平台和业务是非常稳定的，并不会发生剧烈的变化。但如果你的规划发生剧烈的变化，证明你或者你的老板甚至公司的 CTO 并没有想清楚，这些是不应该发生的事情。

那作为管理者，如何去制定 OKR？关于 OKR 有很多相关的书籍可以学习，此处我根据自己的体感做了一些摘录和总结，主要为以下几点：

1. OKR 应该体现团队为谁服务（for who），即围绕价值阐述。很多人将 OKR 写成了一个指标，比如写“性能优化 10%”，那因此谁受益了？你是为谁服务的？比如写“构建速度提升 10%，让研发者在构建的时候得到更快的反馈”，这里写让谁发生了一个变化很关键，所以要围绕用户价值进行阐述。

2. OKR 应该体现聚焦（即取舍），资源有限，集中精力办大事。举个反例，很多人写 OKR，带了 3 个人，写了 8 个 O，20 个 KR，这样写并不知道他们在干嘛。我的团队规模大约三四十人，我的 O 应该是 4 个，专注这四个目标，明确地告诉团队我们做什么和不做什么，如果我一旦列 40 个 O，那所有人都会不明白到底需要做什么。其实也没有那么多需要做的事情，把每一件事做好是不容易的，很多人做事情是抱着“广撒网总能捞到一条鱼”的态度，但我们的目标其实是去“捞一条最好的鱼”，因此一定要做取舍，集中精力办大事。

3. OKR 应该要尽可能量化（不必 100%），用来校准方向，且量化不应被用来考核绩效。

   量化的意思，即不要全是形容词，比如写“卓越的、先进的”，如何衡量是否卓越、是否先进、是否优秀？这很难说，所以需要去尽量量化。同时，量化也是个双刃剑，因为一旦量化之后，大家很容易陷入为了“数字”而去“做数字”的局面，所以作为管理者需要去和团队强调，量化的目的是为了让大家了解方向是否正确，进展是否偏离，而不是为了进行 KPI 考核，一旦强调是在考核，那“数字”必然会变得好看，但实际上毫无用处，还可能给团队带来负担。所以作为管理者一定要谨慎地对待量化，并在团队建立起好的共识。

4. OKR 的承接应该遵循 Single Threaded Leadership 原则。OKR 的负责人没有，或者 OKR 的负责人有一堆，都是错误的。在《亚马逊逆向工作法》一书中，有个观点非常好，即你关键的 O 需要有唯一的责任人，他只对这个 O 负责，并不用对太多事情负责，权责对等。

5. OKR 应该公开，且根据实际情况沟通调整。

反例：一线员工看不到主管的 OKR，看不到更高层级主管的 OKR。

接下来，讲一些被广泛低估的一件事，工程文化。

为何工程文化重要？

中国的互联网快速发展，导致大家产生了我们的工程能力赶超英美的错觉，但其实在很多方面还是会被打回原形。我们整个工程能力在性能和稳定性领域，其实和谷歌、微软等公司没有太大差距，因为我们分布式系统的用户量会要求我们的性能必须做到极致，否则便无法支撑。我们一直讨论的研发效能、代码质量等其实都是工程文化的问题，软件系统是极高复杂度的系统，工程文化一旦出现问题，复杂度失控，质量失控，会导致系统崩溃；其次，研发人员是知识工作者，是“手艺人”，良好的工程文化能激发他们的工作热情，反之则会消磨热情，增加稳定性风险。像阿里这种规模的公司，每月多人协同产出数以亿级的代码行，其实是非常复杂的，如果没有好的工程能力最后会无法维护。

除了效率问题，另外一个是激励问题。工程师其实都想在专业领域做得很好，抛开只为达成功利目的的少数人，大部分人都是希望把自己的工作给做好，代码写得漂亮舒服，被人认可，这是大家都广泛认同的东西。毕竟，谁愿意在代码“屎”山上工作呢？所以我们需要去重视工程文化。

技术管理者与其他领域的管理者之间最大的不同，就是技术管理者除了招聘、做战略规划之外，还需要关注团队的工程文化。那如何建设工程文化？以下是我的一些做法：

• 要求代码开放，要求 code review，要求 unit test

• 搭建 CI 看板

• 技术领导者每天参加 code review绩效考核 / 晋升考核中纳入“技术素养”的要求

• 定义阶段性技术目标，降低系统复杂度（如：下线服务，架构治理）

如果作为技术管理者不亲力亲为，工程文化往往会被牺牲。举个例子，我的老板是研究员级别，P10 级别，他每天都会花不少时间看 code review，每天挑几个看一下并给个反馈，慢慢地就形成了一个比较好的工程文化。如果团队里有工程师有事没事删个几千行代码，那他一定是佼佼者，因为降低系统复杂度是比往系统里怼功能加代码难得多的事情，以上的这些方法都很关键。

所有的公司都会去做故障 Review，但是我并不能确定是否所有的管理者都会去仔细 Review 团队中的每一个故障和细节。因为从中可以看到这几个方面的信息：

1. 系统架构是否存在问题（例如：存在不合理依赖）

2. 研发流程是否存在问题（例如：代码提交没有单元测试覆盖）

3. 运维应急能力是否存在问题（例如：是否第一时间操作扩容）

基本上团队的每个故障我都会去看，最近看的比较少，因为故障比较少：），在新接一些系统时故障比较多。为什么要去做这件事情？一是你会对整个技术架构有更深入的理解，因为多数故障是工程能力不足的症状表现；另外，通过观察团队对故障的处理和复盘，可以发现团队里优秀工程师，优秀的工程师在处理故障的时候，他对整个系统的全局有着清晰点认识，但如果是一个不熟悉系统的工程师，他会非常慌张，因为他不知道哪里出现了问题。因此，一方面是在看系统，一方面也是在看人，在这种过程中，看到优秀的工程师需要去给他相应的一些资源支持，鼓励他去做架构治理，去下线系统等等，这都是非常关键的细节之处。

出现故障之后，了解问题并帮助大家改进，我们宣扬 blameless，即创造安全感。如果将故障与人的绩效挂钩，那会造成相互甩锅的局面，没有人想着去改进，故障非个人主观情况造成的话，没有必要去进行追责，鼓励大家发现问题，去改进系统，给予好的正向反馈才是重要的，这也体现出管理者对技术的要求与态度。

团队文化的建设其实是润物细无声的一件事，很多人将文化建设停留在口头，或者理解的是一些团建聚餐活动等，导致大家认为它是“虚”的，其实不然。如果你的团队文化不注意建设开放透明的文化，那会发生一些反例：

• A 同学把自己写的代码设置为 private，他人不知道其工程能力，老板也不在乎，但是他非常会写 PPT 汇报。

• B 同学找 C，D 单独沟通获取了大量的信息后，和老板单独汇报（选取对自己有益的信息），促成了老板做出对自己有利的决策。

• B 同学就某个想法找 C、D 聊完后，包装成自己的观点，和老板单独沟通，给老板造成他能力强的印象。

• X 领导在一年中多次改变团队目标，但是未和团队解释这些变化的原因，导致团队士气低落。

• 晋升季的时候，B 同学被晋升了，但是领导没有向大家清晰的公开晋升标准以及 B 同学何以满足这些标准，导致团队各种猜测。

那有哪些建设开放透明文化的方法：

1. 开放团队所有的代码和文档

2. 关键决策公开群组 / 会议讨论，鼓励离线记录讨论

3. 公开晋升 / 奖励等标准，公开其过程

4. 公开团队和个人目标（如：OKR）

有很多团队中每个人都有自己的代码库，只有在彼此系统对接合作时才会了解，我要求团队必须强制开放代码，是因为这样做可以让所有人相互了解，形成一种同行的压力。在团队管理中，尽可能地给团队信息公开，信息透明，决策透明，避免私下沟通、信息差等问题存在，能够提高团队的效率和凝聚力。

另外，公开透明的环境会让“小恶”无处遁形，创造鼓励向善的行为十分关键；其次，在团队中给予充分的信息和规则，知识工作者自己可以做最高效的判断；最后，文化的建设需要时间，不可能一蹴而就。

最后聊一下管理中的激励，大家讲管理经常会提到马斯洛需求层次理论，但这里我认为达尔文的进化论在管理和激励上给我们的启发会更大。

达尔文的进化论大家都了解，这里不再赘述，我简单提炼下几个核心的信息：

• 人类进化的 99% 时间（约 200 万年前到 3.5 万年）都处于依靠狩猎采集的社会状态。在这漫长时间内进化出来的，追逐地位和尊重的心理特点，普遍刻在每一个人的基因里。

• 在狩猎采集阶段，面对力量和速度都远超人类的野兽，人类的核心竞争力是相互协作。

• 被集体所排斥（安全感缺失）意味着高概率的死亡。

• 被集体所尊重，获取更高的地位，意味着更多的物质机会和更多的交配机会。

我们今天所有的心理状态都是在进化过程中逐渐形成的，都旨在帮助我们生存，以上这些心理机制在今天的管理和激励上也有很大的借鉴意义，管理者需要意识到人类普遍对安全感的需求，对地位和尊重的需求。

总结一下，那如何在团队中营造一个充满安全感的工作氛围？首先，从微小之处让团队成员感受到自己的价值与意义，比如 1-on-1 的沟通，鼓励团队中的正向行为，公开场合明确目标，让团队成员知晓自己的决策过程等方式，让团队成员获得安全感和价值感。

其次，理解团队成员对于“名利”看重的心理机制，作为管理者可以尽可能的去为团队成员的成长提供资源支持，但固然无法满足每个人对于“地位”和“资源”的诉求。然而，管理者可以做到对每个人的尊重，对其工作成果的尊重，不论是开庆功会还是群里发红包等形式，让团队成员感受到自己工作的价值和意义，这对促进团队成员的创造性行为是非常重要的。

定目标，找人才、建文化，这就是我们做团队管理比较关键的一些内容。有时候很多事情是很表面的，但实际上内心的一些机制、人的认知、人的心理，其实是起了一些决定性的作用的，我们是改变不了的，我们只能接受。在这些基础上，我们再思考可以去做哪些措施去不断地优化。

重新 Review 你的面试流程，是否有明确的标准要求？是否有严格的流程遵循？

和团队的关键成员安排一次 1-on-1 沟通，关注你和他 / 她是否有清晰一致的目标？

把团队所有代码设置成尽可能公开，至少团队内公开，每天至少花 2 小时 Review 代码。

思考并修订团队目标（OKR），和你上级讨论达成共识，在团队公开宣讲。

思考团队目标，如果必须要砍掉其中一个子项，你会怎么选择，写下你的思考。

整理团队的技术债务和技术风险，产出改进计划。

最后我认为很关键的一句话，做管理实际上你要在团队内建立一种氛围和文化，把每个人的善意都激发出来，我觉得这是非常值得做的一件事情，不一定是伟大，但是是非常有意义的一件事情。抛开我们对升职加薪那些功利的追求之外，每个做管理的人，不论你的团队是 10 人、 20 人、 30 人、 50 个人还是 100 人，每个人产生的影响都是巨大的，这也可能是对技术更有价值的一件事情。

许晓斌，阿里巴巴工程师，技术管理者，目前负责阿里巴巴集团运维及构建基础设施平台，《Maven 实战》作者。

5 月 26 日 -5 月 27 日，QCon 全球软件开发大会即将落地广州，从下一代软件架构、研发效能提升、DevOps vs 平台工程、AIGC、数据驱动业务、工业互联网、出海的思考、金融分布式核心系统、大前端架构等角度与你探讨，欢迎你来现场打卡交流～

点击阅读原文直达大会官网，现在购票享 8 折优惠，组团购票还有更多折扣，感兴趣的同学联系票务经理：15600537884（电话同微信）。