技术领导力实战-许晓斌.pdf

《技术领导力实战-许晓斌.pdf》由会员分享，可在线阅读，更多相关《技术领导力实战-许晓斌.pdf（23页珍藏版）》请在三个皮匠报告上搜索。

1、技术领导力实战阿里巴巴工程师/许晓斌/2023.02自我介绍软件行业从业 15 年，包括微服务架构、DevOps、云原生等领域软件管理工作 5 年目前就职于阿里巴巴-TRE（技术风险与效能部）负责运维与构建基础设施平台Maven实战作者它非常重要！技术领导力可悲的现实：大部分技术领导者是不称职的。技术领导反模式闷头干模式延续独立贡献者的工作方法，所有方案自己做，所有代码自己写。路由器模式上级任务往下转发，任务结果收集汇报。高压模式对上过度汇报，对下持续增加，辅以不科学的价值宣导。不决策模式不对任何需求 say no，或者决策全部下放，并让下属承担决策后果。有业务无工程模式高度关注短期业务交付，

2、不管工程质量。不称职领导力的根源互联网行业蓬勃发展经济上升期&技术开放产生大量技术管理者总结“成功经验”虽然成功与他们的管理能力基本没什么关系 被新的技术管理者学习如果技术领导者只能做好一件事重视人才意味着什么？你每周花几个小时做招聘/面试/1-on-1沟通？你是否对每次面试都严格要求？会不会因为项目压力降低要求？你能欣赏和你不同的想法和观点吗？你有信心充分地授权，并敢于为此负责吗？我的面试 Tips：工程能力（在线编码，历史代码等）职业发展目标对齐沟通简单，逻辑清晰战略目标如何落地OKROKR 应该体现团队为谁服务（for who），即围绕价值阐述。反例：罗列技术指标和用户会有什么变化无关。

3、OKR 应该体现聚焦（即取舍），资源有限，集中精力办大事。反例：罗列 8 个 O，20 个 KR。OKR 应该要尽可能量化（不必 100%），用来校准方向，且量化不应被用来考核绩效。反例：全是形容词，看不到数字。反例：主管拿着 OKR 告诉员工做到 xxx 绩效就是 yyy。OKR 的承接应该遵循 Single Threaded Leadership 原则。反例：OKR 的负责人没有，或者 OKR 的负责人有一堆。OKR 应该公开，且根据实际情况沟通调整。反例：一线员工看不到主管的 OKR，看不到更高层级主管的 OKR。何为 OKR被广泛低估的一件事工程文化为何工程文化重要？软件系统是极高复杂

4、度的系统，复杂度失控，质量失控，会导致系统崩溃。研发人员是知识工作者，是“手艺人”，良好的工程文化能激发他们的工作热情，反之则会消磨热情。毕竟，谁愿意在代码 山上工作呢？建设工程文化的方法要求代码开放，要求 code review，要求 unit test。搭建 CI 看板。技术领导者每天参与 code review。绩效考核/晋升考核中纳入“技术素养”的要求。定义阶段性技术目标，降低系统复杂度（如：下线服务，架构治理）如果技术管理者不亲力亲为，工程文化往往会被牺牲。案例：故障 Review 的重要性技术管理者应该仔细 Review 团队中的每一个故障，因为从中可以看到：1.系统架构是否存在问

5、题（例如：存在不合理依赖）2.研发流程是否存在问题（例如：代码提交没有单元测试覆盖）3.运维应急能力是否存在问题（例如：是否第一时间操作扩容）即：多数故障是工程能力不足的症状表现。润物细无声的一件事建设开放透明的文化不开放透明的例子：A 同学把自己写的代码设置为 private，他人不知道其工程能力，老板也不在乎，但是他非常会写 PPT 汇报。B 同学找 C，D 单独沟通获取大量了信息后，和老板单独汇报（选取对自己有益的信息），促成了老板做出对自己有利的决策。B 同学就某个想法找 C，D 聊完后，包装成自己的观点，和老板单独沟通，给老板造成他能力强的印象。X 领导在一年中多次改变团队目标，但是

6、未和团队解释这些变化的原因，导致团队士气低落。晋升季的时候，B 同学被晋升了，但是领导没有向大家清晰的公开晋升标准以及 B 同学何以满足这些标准，导致团队各种猜测。建设开放透明文化的方法1.开放团队所有的代码和文档。2.关键决策公开群组/会议讨论，鼓励离线记录讨论。3.公开晋升/奖励等标准，公开其过程。4.公开团队和个人目标（如：OKR）。1.公开透明的环境会让“小恶”无处遁形。2.给予充分的信息和规则，知识工作者自己可以做最高效的判断。3.文化的建设需要时间。达尔文给我们的