作者|许晓斌
编辑|孙瑞瑞
本文由 InfoQ 整理自阿里巴巴资深工程师 许晓斌 在 QCon 全球软件开发大会(北京站)2022 上的演讲《技术领导力实战》。
大家好,我是许晓斌,目前就职于阿里巴巴技术风险与效能部,负责运维与构建基础设施平台。在软件行业从业 15 年,包括微服务架构、DevOps、云原生等领域,软件管理工作 5 年。出过一本书《Maven 实战》,做 Java 的同学应该有不少人读过。
目前我在阿里巴巴带了多年团队,在实际工作中也有一些管理上的经验,但在准备 QCon 全球软件开发大会北京站的这个演讲主题时,在官网信息及材料中刻意隐去了自己的 title,我认为如果大家只是被 title 吸引而来,那其实并没有什么意义。个人认为,这个话题在国内也很少能有非常专业的分享。因为管理和领导是一种“专业”,它跟技术专业不一样,但它也是一种专业。众所周知,当下国内整体上是一个“业务为王”的时代,只要业务增长,管理、领导,甚至技术,做得好与不好都不重要。很多时候业务好和人的技术无关,和管理也无关,只是因为你恰好在风口,所以大家得意识到这一点。假设业务不增长了,该如何去量化一个管理者?如何去评估一个管理者做的好与不好?这是一件挺有意思的事情。
那这次演讲为什么讲管理?因为我见过太多糟糕的管理者了,包括我自己。
技术领导反模式
回顾一下我刚刚开始带团队的时候,可以用“稀烂”来形容。技术领导力其实非常重要,因为好的管理,它决定了公司的战略是否能够得到执行和落地;其次,它也决定了大量工程师的成长和发展。举个例子,如果你犯个技术错误,无非是一个故障;但是如果你犯管理错误,你对一个人的一年、两年甚至更长时间,会产生一个巨大的影响。所以这是一个非常关键的事情,需要重视。
但可悲的现实是,大部分技术领导者是不称职的。以下列举的几种错误模式在技术领域随处可见,基本都可以对号入座:
延续独立贡献者的工作方法,所有方案自己做,所有代码自己写。
上级任务往下转发,任务结果收集汇报。
对上过度汇报,对下持续增加,辅以不科学的价值宣导。
不对任何需求 say no,或者决策全部下放,并让下属承担决策后果。
高度关注短期业务交付,不管工程质量。
作为管理者,你可以通过参考以上反模式来反思一下自己是否称职。如果你是一个“大头兵”,你可能感觉到自己老板不靠谱,时常被 PUA 到怀疑自己能力问题,但这些问题的根源并不是因为大家不想做好这件事情或者缺乏专业的理论,而是因为行业发展得太快了。以蓬勃发展的互联网为例,像阿里、腾讯等公司在短短十几年时间内从 100 人增长为 10W 人规模,这个时期产生了大量的技术管理者。然而,由于社会面缺乏既懂业务又懂技术、同时又懂管理的人才,只能通过内部提拔。但这些被提拔上去的人是因为管理做得好吗?大部分不是。他们成长晋升得很快,大部分是因为业务好或者技术好,但管理能力却不一定好。因此,这会导致这些人产生了一个错误的认知偏差,认为自己的成长和晋升速度很快,但其实本身的工程能力不足,实际的管理能力与其“总监”、“总裁”的 title 并不匹配。
事实上,很多时候业务的成功和他们的管理能力没有必然关系,换一个人也是同样的结果。业务的飞速增长是因为业务本身处于商业风口,或是因为商业战略、业务战略、运营战略的判断。
那么,如何进行管理呢?我自己也阅读了一些管理方面的书籍,并有一些实际管理工作中的经验和心得体会,可能不是最准确的,但应该还算靠谱。在本文中,我将删繁就简,探讨一些重要的事情。也希望能够通过本文得到一些反馈,帮助我更好地整理和思考。
人 才
我自己带团队的时间大概有五年多,总结下来,如果说技术领导者只能做好一件事的话,就是做招聘,挖掘人才。
那为什么是招人最重要?这个观点也出自于我现任的一位 Leader,大约三四年前,我们一起在杭州的 EFC 地下食堂吃饭聊到了相关的话题。当时,他问我,你觉得做管理什么事情最重要?我当时没有想好,沉默了一分钟没有说话,然后他看我笑了笑说,你傻,就是招人。
如果你正在带领一个团队或正处于一个团队中,发现团队里有一些非常棘手的或是痛苦的问题得不到解决,通常都能够最终溯源到某个人身上。比如我反思自己在团队中做得最成功的事情,我能够溯源到我招了一位正确的人,或者是我培养了一位正确的人;反思我做得比较失败的事情,或者是让我头疼的事情,都是因为这个人不是我招聘的,或者是不得不塞到我团队里的。
往往常见的情况是,老板给了业务后团队立马招人扩大规模,你想了想明年可能又可以晋升了。但实际上,一定要给团队招一个正向的人,即与团队目标一致、文化一致,能力一致。如果团队里某个人的专业素养不能支撑住在团队生存的时候,他必然会进化出一种其他方面的能力帮助自己在团队里生存。比如他可能特别“会汇报”、特别会“写 PPT”、特别会“搞东搞西”的一些事情来帮助他自己生存,因为他的专业能力无法跟上团队,为了不被踢出团队,所以需要进化其他能力。所以我后来就养成了一个习惯,就是在招聘的时候会将候选人专业素质的要求提高,我宁愿招不到人,宁愿业务不做或是做得慢一些。
那重视人才意味着什么?
在招聘比较旺盛的时候,比如校招开始时,我每天平均会花几个小时的时间来做招聘和面试,和一些 1-on-1 沟通,并且不断地告诫自己,一旦招聘一个人,如果我很喜欢但是又有点犹豫,我就会判断可能哪里存在问题,就会放弃。在招聘过程中,首先我会非常的重视工程能力,比如会进行在线笔试,在线编码能力和历史代码等,一轮两轮三轮,不断地验证候选人的代码是否足够 Solid,讨论时是否足够 Opening,还会问一些明知对方不会的问题,去看对方是直接反馈不会,还是选择绕圈回答,比如有人绕了一圈后,最后结论是虽然我不会,但是我会怎样怎样。但其实我不需要对方去回答这些问题,我需要的是职业发展目标对齐,基本能力对齐,沟通简单,逻辑清楚,这几点要求我一直非常坚持。
到目前为止,我们团队在公司每年的 360 员工满意度调研中的分数都是不错的,这并不是因为员工进来之后我带领的多好,而是因为他们进入了合适自己的团队, 并且能够开心地工作,这是我认为比较关键的。
下一步,就是如何带团队。
带团队肯定要定战略、做规划。那战略目标如何落地?阿里是用的 OKR,我每个两周或一个月,都会去看我的 OKR 进展并进行更新。很多人的规划经常变来变去,可能过去一个月后做的事情已经和规划完全无关了,但我今年的规划相比去年,有 80% 其实是一样的,这是多重原因决定的,一方面是因为我认为我做的规划比较科学清晰,另一方面是整个组织结构比较稳定,比如没有老板天天换等等,这两点其实非常重要,实际上也应该如此。
我们的业务并没有多大的变化,我们是做工程的,平时的工作就是写代码的时候做发布、做构建、做运维,以及访问各种云产品等,这些平台和业务是非常稳定的,并不会发生剧烈的变化。但如果你的规划发生剧烈的变化,证明你或者你的老板甚至公司的 CTO 并没有想清楚,这些是不应该发生的事情。
那作为管理者,如何去制定 OKR?关于 OKR 有很多相关的书籍可以学习,此处我根据自己的体感做了一些摘录和总结,主要为以下几点:
反例:一线员工看不到主管的 OKR,看不到更高层级主管的 OKR。
工程文化
接下来,讲一些被广泛低估的一件事,工程文化。
为何工程文化重要?
中国的互联网快速发展,导致大家产生了我们的工程能力赶超英美的错觉,但其实在很多方面还是会被打回原形。我们整个工程能力在性能和稳定性领域,其实和谷歌、微软等公司没有太大差距,因为我们分布式系统的用户量会要求我们的性能必须做到极致,否则便无法支撑。我们一直讨论的研发效能、代码质量等其实都是工程文化的问题,软件系统是极高复杂度的系统,工程文化一旦出现问题,复杂度失控,质量失控,会导致系统崩溃;其次,研发人员是知识工作者,是“手艺人”,良好的工程文化能激发他们的工作热情,反之则会消磨热情,增加稳定性风险。像阿里这种规模的公司,每月多人协同产出数以亿级的代码行,其实是非常复杂的,如果没有好的工程能力最后会无法维护。
除了效率问题,另外一个是激励问题。工程师其实都想在专业领域做得很好,抛开只为达成功利目的的少数人,大部分人都是希望把自己的工作给做好,代码写得漂亮舒服,被人认可,这是大家都广泛认同的东西。毕竟,谁愿意在代码“屎”山上工作呢?所以我们需要去重视工程文化。
技术管理者与其他领域的管理者之间最大的不同,就是技术管理者除了招聘、做战略规划之外,还需要关注团队的工程文化。那如何建设工程文化?以下是我的一些做法:
如果作为技术管理者不亲力亲为,工程文化往往会被牺牲。举个例子,我的老板是研究员级别,P10 级别,他每天都会花不少时间看 code review,每天挑几个看一下并给个反馈,慢慢地就形成了一个比较好的工程文化。如果团队里有工程师有事没事删个几千行代码,那他一定是佼佼者,因为降低系统复杂度是比往系统里怼功能加代码难得多的事情,以上的这些方法都很关键。
案例:故障 Review 的重要性
所有的公司都会去做故障 Review,但是我并不能确定是否所有的管理者都会去仔细 Review 团队中的每一个故障和细节。因为从中可以看到这几个方面的信息:
基本上团队的每个故障我都会去看,最近看的比较少,因为故障比较少:),在新接一些系统时故障比较多。为什么要去做这件事情?一是你会对整个技术架构有更深入的理解,因为多数故障是工程能力不足的症状表现;另外,通过观察团队对故障的处理和复盘,可以发现团队里优秀工程师,优秀的工程师在处理故障的时候,他对整个系统的全局有着清晰点认识,但如果是一个不熟悉系统的工程师,他会非常慌张,因为他不知道哪里出现了问题。因此,一方面是在看系统,一方面也是在看人,在这种过程中,看到优秀的工程师需要去给他相应的一些资源支持,鼓励他去做架构治理,去下线系统等等,这都是非常关键的细节之处。
出现故障之后,了解问题并帮助大家改进,我们宣扬 blameless,即创造安全感。如果将故障与人的绩效挂钩,那会造成相互甩锅的局面,没有人想着去改进,故障非个人主观情况造成的话,没有必要去进行追责,鼓励大家发现问题,去改进系统,给予好的正向反馈才是重要的,这也体现出管理者对技术的要求与态度。
建设开放透明的文化
团队文化的建设其实是润物细无声的一件事,很多人将文化建设停留在口头,或者理解的是一些团建聚餐活动等,导致大家认为它是“虚”的,其实不然。如果你的团队文化不注意建设开放透明的文化,那会发生一些反例:
那有哪些建设开放透明文化的方法:
有很多团队中每个人都有自己的代码库,只有在彼此系统对接合作时才会了解,我要求团队必须强制开放代码,是因为这样做可以让所有人相互了解,形成一种同行的压力。在团队管理中,尽可能地给团队信息公开,信息透明,决策透明,避免私下沟通、信息差等问题存在,能够提高团队的效率和凝聚力。
另外,公开透明的环境会让“小恶”无处遁形,创造鼓励向善的行为十分关键;其次,在团队中给予充分的信息和规则,知识工作者自己可以做最高效的判断;最后,文化的建设需要时间,不可能一蹴而就。
达尔文进化论的启发
最后聊一下管理中的激励,大家讲管理经常会提到马斯洛需求层次理论,但这里我认为达尔文的进化论在管理和激励上给我们的启发会更大。
达尔文的进化论大家都了解,这里不再赘述,我简单提炼下几个核心的信息:
我们今天所有的心理状态都是在进化过程中逐渐形成的,都旨在帮助我们生存,以上这些心理机制在今天的管理和激励上也有很大的借鉴意义,管理者需要意识到人类普遍对安全感的需求,对地位和尊重的需求。
总结一下,那如何在团队中营造一个充满安全感的工作氛围?首先,从微小之处让团队成员感受到自己的价值与意义,比如 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、数据驱动业务、工业互联网、出海的思考、金融分布式核心系统、大前端架构等角度与你探讨,欢迎你来现场打卡交流~
点击阅读原文直达大会官网,现在购票享 8 折优惠,组团购票还有更多折扣,感兴趣的同学联系票务经理:15600537884(电话同微信)。