史海峰：成为技术领导者 从技术到管理的必经之路丨声网开发者创业讲堂 • 第 5 期

前言

史海峰，曾在神州数码、亚信联创长期从事电信行业业务支撑系统集成工作，参与中国移动、中国联通多个项目，具有丰富的大型业务系统研发实施经验。

曾在当当负责总体架构规划、技术规范制定和技术预研推广，参与多个重点项目的方案设计，在项目中对系统架构进行持续改造优化。负责技术委员会组织管理工作，发掘最佳实践、推动技术革新、开源产品，组织内外部技术交流。

曾负责饿了么技术创新部产品研发团队，完成多个创新性业务项目及技术产品。

曾在贝壳金服负责小微企业生态金融服务产品规划、技术团队管理、系统建设。

多次参加业界技术大会，包括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/