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

展开全文

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

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

人 才

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

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

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

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

那重视人才意味着什么？

你每周花几个小时做招聘 / 面试 /1-on-1 沟通？ 你是否对每次面试都严格要求？会不会因为项目压力降低要求？ 你能欣赏和你不同的想法和观点吗？ 你有信心充分地授权，并敢于为此负责吗？

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

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

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

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

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

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

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

工程文化

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

为何工程文化重要？

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

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

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

要求代码开放，要求 code review，要求 unit test 搭建 CI 看板 技术领导者每天参加 code review绩效考核 / 晋升考核中纳入“技术素养”的要求 定义阶段性技术目标，降低系统复杂度（如：下线服务，架构治理）

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

案例：故障 Review 的重要性

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

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

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

建设开放透明的文化

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

A 同学把自己写的代码设置为 private，他人不知道其工程能力，老板也不在乎，但是他非常会写 PPT 汇报。 B 同学找 C，D 单独沟通获取了大量的信息后，和老板单独汇报（选取对自己有益的信息），促成了老板做出对自己有利的决策。 B 同学就某个想法找 C、D 聊完后，包装成自己的观点，和老板单独沟通，给老板造成他能力强的印象。 X 领导在一年中多次改变团队目标，但是未和团队解释这些变化的原因，导致团队士气低落。 晋升季的时候，B 同学被晋升了，但是领导没有向大家清晰的公开晋升标准以及 B 同学何以满足这些标准，导致团队各种猜测。

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

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

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

达尔文进化论的启发

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

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

人类进化的 99% 时间（约 200 万年前到 3.5 万年）都处于依靠狩猎采集的社会状态。在这漫长时间内进化出来的，追逐地位和尊重的心理特点，普遍刻在每一个人的基因里。 在狩猎采集阶段，面对力量和速度都远超人类的野兽，人类的核心竞争力是相互协作。 被集体所排斥（安全感缺失）意味着高概率的死亡。 被集体所尊重，获取更高的地位，意味着更多的物质机会和更多的交配机会。

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

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

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

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

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

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

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

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

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

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

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

作者介绍：

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

百度回应文心一言“套壳”质疑；TikTok在美经历生死时刻；IT外包行业面临最大规模裁员，埃森哲将暴力裁员1.9万人 ｜ Q资讯

集成GPT-4的编程神器来了，GitHub发布Copilot X：编程30年，突然就不需要手敲代码了？！

八年“老网红”Flink：揭秘实时流计算引擎全球化落地的演进历程

我在GitHub 黑市买“水军”：一万颗star只要4000多元，人人都能“一夜爆火”

活动推荐：

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