前言
史海峰，曾在神州数码、亚信联创长期从事电信行业业务撑持系统集成工作，参加中国移动、中国联通多个我的项目，具备丰盛的大型业务零碎研发施行教训。
曾在当当负责总体架构布局、技术规范制订和技术预研推广，参加多个重点项目的方案设计，在我的项目中对系统架构进行继续革新优化。负责技术委员会组织管理工作，挖掘最佳实际、推动技术革新、开源产品，组织内外部技术交换。
曾负责饿了么技术创新部产品研发团队，实现多个创新性业务我的项目及技术产品。
曾在贝壳金服负责小微企业生态金融服务产品布局、技术团队治理、零碎建设。
屡次加入业界技术大会，包含 ArchSummit、QCon、SACC、TOP100、SDCC、GITC、MPD、GIAC、CSDI 等，任讲师及出品人。
在声网开发者守业讲堂 • 第 5 期中，咱们特地邀请到了史海峰老师，以「 成为技术领导者，从技术到治理的必经之路 」为主题进行了分享。
本文基于演讲内容整顿，为不便浏览略有删改。
01 技术领导者的挑战
1、Manager 和 Leader
守业有不同的分工和维度，有的人可能是单打独斗，而有的人可能在初期就曾经组建了团队。在技术维度也是如此，有的公司可能一开始就有肯定规模的团队，这种状况下资源是比拟富余的，解决问题的效率就会更高。而对于所有从头开始的技术团队来说，这个过程就很艰巨了。在这个过程中，leader 的能力就显得尤为重要。如果在没有做过 leader 的状况下组建守业公司会面对很多问题，比方怎么分配任务和提要求？是否抉择新技术？产出不给力的状况下加班有用么？对于负能量坏消息，说还是不说？下级和业务到底想要什么？团队外部问题怎么解决？等等。
可见，要想做好一个 leader 是存在很多艰难的，那么如何解决这些艰难，顺利率领团队走向胜利呢？首先要明确 manager 和 leader 有什么区别，有很多同学在刚开始的时候并不能理清两者的关系。区别具体如图 1 所示，简略来说，做 leader 就是要让其他人可能被动追随，而不是仅仅因为级别，但 manager 则是级别驱动的。当然，这并不代表治理是谬误的，这只是一个概念的辨别。
■图 1
2、什么人不适宜带团队
理解了 manager 和 leader 的区别后，咱们就要思考什么样的人不适宜带团队，每个人都有本人的特点，不适宜带团队的人次要具备以下几种特质：
- 不善于、无志愿沟通
- 喜爱单打独斗、不长于合作
- 自我认知偏差
- 以自我为核心，刚愎自用，性情偏激
- 技术牛但讲不进去
- 犹豫不决、心太软
- 唯技术论
- 德不配位
- 人格魅力有余
3、什么人适宜带团队
既然有的人不适宜带团队，为了团队的倒退，咱们就要抉择适宜的人来做这项工作，那么一个胜利的技术领导者须要什么样的特质呢？具体包含以下几种：
- 承担责任，不找借口
- 谋求卓越，高标准要求
- 平等、服务心态
- 负能量本人消化
- 习惯不完满
- 疾速决策
- 以德服人
- 守正出奇
4、使命是什么
明确了 leader 的特质之后，还要理解团队的 leader 的使命，我总结下来就是：成就公司，成就团队。那么带团队须要做哪些事件呢？对于一个技术团队来说，基本上就是管人和理事。对于个体来说，管人就是选用育留；对于组织来说，则是要有很强的组织效力。理事包含产品布局、项目管理、零碎架构和技术规范。这些都是体系化的工作，要把它们都做好很不容易，很多公司都只在某些方面达到了规范，但只有实现了最终业务，就能够漠视掉其余问题，因而要习惯不完满。
02 从技术到治理
1、技术 vs. 业务
一般来说，leader 是团队的技术代表，但在很多状况下 leader 面对的问题不是技术，而是业务，因而 leader 须要明确本人的地位。技术 leader 要把本人作为一个技术的商人来采购本人的技术，使客户了解其技术价值，进而为该技术付费。因而，咱们要首先理解技术跟业务的关系，具体如下：
- 技术为业务服务，业务策略决定技术策略，业务架构决定 IT 架构
- 技术撑持业务的前提是业务需要明确
- 技术驱动业务的前提是技术了解业务，要使业务信赖技术
2、康威定律
康威定律其实是一篇文章，大家感兴趣能够去搜一下。这篇文章介绍了很多观点，然而其中有一句话是比拟出圈的，所以就是成为了一条定律。这条定律说的是，设计零碎的组织，最终产生的设计等同于组织之间和之内的沟通构造。因而，设计零碎的组织，最终产生的设计等同于组织之内、之间的沟通构造。假如有四个部门，常见的做法是将零碎分为四个子系统，别离提供给这四个部门应用，而后将其再串联起来。如果你想突破这种模式，就得先调整组织，因为需要都是组织产生的。这里给大家展现图 3 的漫画。漫画中的人物正在思考，依据康威定律，零碎架构是由组织决定的，而组织是人力资源决定的，原来是人力资源部在设计组织架构，最终决定了零碎架构。尽管是个笑话，但也有肯定情理。
■图 3
3、零碎 vs 团队
既然了解了康威定律，那么零碎和团队有哪些异同呢？如果你的零碎设计教训比拟多，做技术的工夫比拟长，就会有一个零碎的概念，发现团队也是一个零碎，只不过组成成分是不同的，两者的关系能够总结为以下几点：
- 团队是由人组成的，而零碎则由软硬件组成。然而每一个人都有本人的职责边界和本人的性能，所以这是有共性的。
- 零碎包含 CAP 原理、分布式、自适应等理念，绝对应的团队也有人月神话，自组织、补位等说法，因而两者是比拟靠近的。
- 零碎强调高可用、稳定性，因而须要做冗余、备份，团队也是一样的，人员也有 A/B 角之分。
- 零碎有标准、设计准则，相应的团队也有流程、机制、文化。
- 零碎须要监控，而团队也有本人的治理经营数据。尽管某些团队的数据可能有点少，然而我认为不论是什么数据，有总比没有强。
- 零碎有 MQ、SOA 或者 RPC，而团队之间也须要沟通合作。
- 不论是团队还是零碎，它们都是有生命周期的。团队的生命周期不是指人的生命周期，它由企业的生命周期决定。
- 零碎是死的，但人是活的，所以零碎是确定的，但人是不确定的，不确定不是好事，也可能超常发挥。
4、技术专家 / 架构师 vs. 技术领导者
作为一个技术专家或者架构师和做一个技术的 leader 有什么关系呢？次要包含以下几点:
- 面对的对象是不同的。技术专家更多的是对事，leader 更多的是对人。
- 面对的危险都是不确定的。不确定性是世界的常态，然而咱们须要用确定性的形式进行收敛，可能让不确定性变成可控的形式。不论是人还是零碎，都是一样的，只不过零碎没有那么大的弹性，所以很多时候零碎更可信。然而这不代表人不牢靠，人在极其状况下可能做进去极其的事件，可能发明奇观，也可能带来十分大的毁坏。
- 责权是不同的。leader 要做资源的调配和奖惩，然而技术专家或者架构师，更多时候是靠本人的影响力率领共事一起做工作。
- 规范掂量工作的胜利与否。这要求技术和 leader 要有成熟的技术解决方案和领导力。
5、组织倒退对组织治理的要求
理解了专家和 leader 的异同之后，咱们再来看一下组织须要什么样的 leader。方才说到企业有本人的生命周期，所以它在不同的阶段有不同的要求，图 4 中列出了几张图，从中能看出不同的规模，对于治理的要求有微小的差异。
■图 4
换句话说，几个人的小团队和十几万人的团队，CEO 的治理能力要求是不一样的。此外，大家要对组织的倒退周期有一个概念，作为组织的 leader，在组织从成长到成熟再到施展状态的过程中，不同的阶段其施展的作用是不一样的，leader 也不能解决所有的事件。
03 领导力进阶
1、能力构造分层
如何进步 leader 率领团队的程度呢？首先各层次的治理要求的能力是有区别的，如图 5 所示。高级的管理人员个别要求的是业务知识 / 技能，中级的管理人员则更多开始要求企划力，高级的管理人员的要求是有先见性。先见性是指看得更远，可能料想将来的事件。所以公司的领导可能很多时候都在看十年当前的事件，眼前的事很早以前就曾经决定了，除非遇到异常情况须要紧急解决。
■图 5
技术条线也是一样，一开始基层看重的是工程能力、解决问题的能力，对于形象能力、布局和决策能力的要求是没有那么高的，越高级别的管理人员对于前面提到的这些特质的要求越高。管理人员须要靠团队，最终能疾速决策，找到解决问题的门路，这些是综合能力的体现。带团队（做技术也一样）的路肯定是越走越窄的，因为要求越来越高，能走进去的那条路越来越窄。
2、领导力成长
对于领导力的成长我分成了四个局部，那就是心态、套路、聚焦和成长，接下来我将对这四局部进行具体的介绍。
1）心态
首先如果没有一个良好的心态，那么当 leader 的压力就会显得十分大，因为以前只须要管好本人就能够了，当初的状况则不同，成员须要 leader 的领导。
要想领有好的心态，就要敢于担当，能信赖成员，能放权，可能承受缺憾，关键时刻可能做取舍，可能从小的中央发现大的问题，可能果决决策，做到真挚、平等、保持。这些看起来有的时候是心态，其实也是人所展示进去的低劣品质，它可能让他人感触到 leader 的领导力，进而违心追随。如果 leader 本人的心态没有调整进去，那么成员是会感触到的，如此下来，他们可能会放大 leader 身上的小毛病，对于谬误的容忍度也会升高。
2）套路
套路就是一些治理动作，做事件肯定要有一个相对来说比拟确定的节奏和套路。不论是人才盘点，还是降职、激励、例会、集体指标和一直的继续反馈，又或者是复盘、总结等都是根本套路，如果把这些变成在治理周期之内该做的事件，循序渐进地进行，所有都会变得天经地义。一个团队须要组织，也须要很多外部的固定机制来确保成员的信息互通，确保大家的了解和认知对齐指标，使其可能一直地优化解决，以进步本人的整体的程度。
更进一步来说，还要更好地关注业务，关注组织层面的工作，以及技术的方向、资源的调配、跨组织的协调、准则和规矩等。将这些治理套路向下贯彻，使下一级别的管理者复制能力，就能把团队率领得更好。
3）聚焦
聚焦是指就是根本动作实现之后，还要有一些关注点。关注点一方面是各层次的信息透明度，也就是要公开通明，然而个别状况下信息传递肯定是有衰减的或者说会有乐音产生，在这个过程之中，要确保哪些信息能触达到哪些层面、哪些信息没有必要。比方好的信息应该让所有人都晓得，不好的信息就自行排汇消化，让成员晓得本人该晓得的就能够了。另外，还要做好中继，就是要放大重要的事件，并向团队反复强调。接下来是穿透，方才说了很多套路，但有时候要不按套路出牌，可能把层级打穿，看到最后面产生了什么。业务价值也是很重要的一点，业务价值有它的合理性和业务模型，人也是一样，对于不同职责的人，要求是不一样的，要关注人性化层面的问题。咱们还要保障工夫效率，治理好本人的工夫并一直优化。最初就是容纳，要换位思考，不要拿本人的规范去要求所有人，因为一般来讲，leader 的能力比大多数人强，因而会很容易发现他人的毛病，而漠视长处，这样的做法是不适合的。
4）成长
成长的关键在于实际，对于带团队，不论是否有一个很成熟的治理理论体系，最终还是要实际出真知，再好的实践也必须拿出成绩来证实。在成长过程中会遇到很多问题，方才提到了不确定性，我认为咱们要接收不确定性、应答不确定性。作为一个 leader，要比个别的团队成员面对更多的不确定性，此时要成为一个团队的表率，解决这些未知的状况，这就意味着要一直成长。咱们能够多借鉴行业前辈积攒的教训，这里我给大家举荐了一些书（如图 7 所示），当然不是说所有书都看，每个人各取所需。
■图 7
很多同学会感觉对于技术治理如同没有相干的图书，如同也没有一个业余叫技术治理，但其实技术的治理在行业内是存在一些积攒的，作为一个 leader 你肯定要去理解这些信息，这些货色是可能逾越工夫的，因为人没有变，行业最根本的逻辑也没有变，尽管技术翻天覆地了，然而技术治理这件事曾经通过了几十年，所以有很多货色是能够去借鉴学习的。
04 总结
我明天分享这么多，最初提一些问题供大家思考。如果对于上面的问题大家都能有明确的答案，那么置信你间隔更为一个优良的团队 leader 也不远了。
- 怎么保障交付品质？
- 怎么进步团队满意度？
- 本身还有什么有余？
- 1 年后要达到什么程度？
- 通过哪些伎俩达成？
- 你的治理格调是什么？
- 你的工夫怎么调配？
- 你最罕用的治理动作是什么？
- 你开过人么？对方是否承受？下次怎么开？
- 没有你的话，团队是否失常运行？
- 团队还有哪些改良空间？
05 问答环节
1、作为一家公司的空降 CTO，如何率领一二百个人的技术团队？
从我的角度来讲，首先你要要想明确这个公司为什么要找一个空降的人？为什么要找你？你要解决什么问题？当初这个团队处于什么样的状态？这个团队是不是你可能影响的？或者说其中是不是有一些组织问题是你要解决的？这几方面是一开始就要想的。最重要的一点就是信息，你做任何判断都要充沛理解多维度的信息，这样能力确定你的判断和剖析是对的。
2、作为技术管理者，如何考核或治理程序员的后果和产出？
技术工程师不是流水线，不像拧螺丝那样有规范能够量化，因为每个人都有本人的施展空间，因而咱们考核其工作的时候，要从两个维度对待：第 1 点，考核是一个公司继续运行的必要机制，组织心愿本身倒退更好，为此而要求每个人可能一直进步。第 2 点，绩效考核的量化是肯定要有指标的，当然不见得是谋求代码量、bug 数等，咱们要尽量在不同的阶段看不同的后果，在不同的维度考核的规范不同，要遵从考核规范。从这个层面来说，这只是对一个阶段的工作成绩进行考核，而不是给集体打标签。
浏览更多
1）要理解更多对于声网 SDK 和其余应用案例，请看这里的开发者指南：
https://www.agora.io/cn/community/blog?categoryId=119&offset=0
2）理解咱们的更多 demo 和案例：
https://www.agora.io/cn/community/demo
3）还能够退出声网 RTE 开发者社区和咱们一起探讨交换：
https://www.agora.io/cn/community/