技术leader要拎得清:领导≠管理

Keegan小钢 2021-05-22 09:35:00
前言

 

我是从 2014 年开始正式走上管理之路的,在那之前虽然也有带过几个初级程序员,但毕竟不是正式的管理职位。正式踏上管理岗是从做一个小主管开始的,刚开始只管理几个人;之后担任过一些业务线的技术负责人,管理十几二十人;最多时管理百人团队,负责整个研发部门。一路从技术主管,到技术经理,再到技术总监,中间也和别人合伙创业当过 CTO。有空降管理过现成的团队,也有不止一次从 0 到 1 组建团队的经验。

 

六年多的管理经验,说多不多,但说少也不少,肯定也有自己的一些心得体会,如今就用文字来和大伙分享我的一些经验总结。

 

我打算根据管理的三个级别来聊:技术主管、技术经理、技术总监。这里所说的这三个级别,并不是指代具体的管理岗位名称,可以简单理解为技术团队中的基层管理者、中层管理者、高层管理者,具体的再一一细说。

 

技术主管

 

如刚才所说,技术主管并不指代具体的岗位,而是指初级技术管理人员,主要负责管理某一垂直技术领域,包括管理该领域的基层技术人员。比如 Android 主管、iOS 主管、前端主管、Java 主管、Golang 主管等。有些公司也称为技术组长,而且也不一定设置明确岗位。另外,在有些小公司,管理层级少,可能就没有设置技术主管的岗位,而直接挂名技术经理,比如我的第一份正式管理岗,挂名就是 App 技术经理,管理 Android 和 iOS。那时候的我其实既是基层管理者,也是中层管理者。这在小公司很正常,甚至处于初创期的 CTO,还需要同时担任高层、中层、基层所有的管理工作。

 

技术主管所管理的人员一般只有几个人,多的可能十几个。如果人员超过 20 人,最好对团队根据细分领域做一下拆分。比如 App 人员如果超过 20 人,那就可以拆分为 Android 组和 iOS 组,每组再分别设置一个主管,而原先的 App 主管则可以升级为技术经理。

 

对公司部门来说,技术主管优先考虑肯定是从内部人员中提拔,条件不满足的情况下才从外部招聘。比如,组建新团队的时候;或当前团队都只有些初级工程师,缺乏能够独当一面的人;或团队中都是些技术宅,只想专研技术,不想做管理。这些情况下,一般就需要从外部招聘合适的人选。

 

能荣升技术主管的,一般工作经验 3-5 年,专业技术能力已经非常娴熟,可达到资深级别,还具备一定的架构能力,能够独当一面。学习能力、沟通能力、对业务的理解能力等,也都是比较出众的。一般可以对标阿里的 P6 级别。

 

想要做好技术主管的工作,也不是那么轻松的。作为一名技术主管,平时大部分时间依然还是用在了技术设计、写代码、解决 Bug 等工作,这和基层的程序员没多大区别。但是,技术主管除了需要做好这些程序员本身的工作之外,还需要花时间做开发任务的分解、分配,以及代码 review、技术设计评审、面试、和团队内外的人员沟通协作等管理工作。因此,想要做好技术主管的工作,提高时间管理的能力是很有必要的。不然的话,就会把自己搞得很忙很累,最后管理工作没做好,还影响了作为程序员本身的工作。也因此,有些人就会开始退缩,不愿意当技术主管,觉得会占用自己过多的时间,平时写代码的时间都不够,哪有时间做管理。想要在管理这条路上不断往上爬,这是必须要迈过去的第一道坎。

 

从程序员升级为技术主管,最核心的转变就是:从管理自我到管理他人。所以,我想谈谈关于管理他人的一点经验,主要还是分享下在选人和用人上我自己的一些做法。

 

关于招人选人,我有一个标准,也是我最看重的一点,那就是候选人的深度思考能力。不只是技术人员,包括产品经理、UI 设计、测试人员等,我都会考察他们的深度思考能力。深度思考能力越强的人,越能看到问题的本质,各方面的能力也会越优秀。

 

那么,如何考察候选人的深度思考能力呢?其实也简单,多问些为什么就可以了。比如,对于应聘架构师的候选人,可以类似下面这样层层追问下去:

 

问:你们系统采用什么样的架构?答:微服务架构

问:为什么采用微服务?答:为了快速迭代

问:为什么用了微服务就能实现快速迭代?答:服务间解耦,可以分小组分别独立开发、测试和部署

问:分了多少个小组?每个小组多少人?为什么这么分?答:……

 

这些相互关联的问题,是可以不断追问下去的,问题也并非有标准答案的,也并不是考察候选人是否知道正确答案,而是考察他是否思考过这些问题,是否有自己的一些想法。当然,候选人也不可能对所有领域的问题都能答得上来,所以尽量多方面考察,并尽量从候选人所熟悉的领域进行深入。

 

再说说用人方面,我比较崇尚于为下面每个人的自我成长而负责。我会去了解每个人的职业规划,为他们的职业发展路线提出建议,并在工作中不断给他们提供成长的机会,包括分配的任务、提供的技术指导和培训、定期的一对一沟通,等等。其实,从本质上来说,就是为了激发他们的善意和潜能。

 

我做基层管理时就已经开始实践选人用人的这些方法论,而且成效还非常不错。

 

符合我的标准招进来的人,做事基本都是很高效的,大多都能成为团队里的骨干成员,有时还能做到远超我的预期,有着突出的表现。不过,有时候,长时间没招到合适人选或急需用人时,我只能减低标准,这时候招进来的人,则有些参差不齐了,部分人虽然也能完成任务,但成果就是不尽如人意。

 

也因为我用人的方式注重于他们的成长,所以,他们也很尊重我、支持我、追随我。我管理过的团队,离职率也一向比较低。

 

作为基层管理者的技术主管,建议重点培养自己的以下能力:

 

专业技术能力:这是技术管理者的立身之本,肯定需要不断精进,如果技不如人,是无法服众的。

业务理解能力:对业务有正确的理解,甚至能理解到业务的本质需求,才能让技术实现价值。

任务分解能力:技术主管承担着开发任务分解分配的职责,如果分解不当,漏掉了一些环节,就会导致任务的延迟、质量的不可控,为项目带来了风险。

时间管理能力:管理者需要在有限的时间里高效地管理多种事情,自然就需要提高时间管理能力。

团队建设能力:管理者的核心价值就是打造出一支优秀的团队。

向上管理能力:向上管理没做好,会影响职业的发展,但切记,向上管理并不是拍上级的马屁。

领导力:领导力不同于管理力,不能靠职权,而是靠个人魅力,建议尽早培养。需要明白一点,大部分技术人员更喜欢被“领导”,而不是被“管理”。

 

技术经理

 

技术主管作为基层管理人员,更多时候只是个执行者,要求能够「正确地做事」,能够带领一线团队高效地执行上级所交代的任务。

 

技术经理,作为中层管理人员,主要职责则是根据高层管理所确定的目标,制定实现目标的具体计划并保证实施,还要为最后的实现结果负责。

 

技术经理具体的工作职责,不同公司会有所不同,但主要可能包括:制定技术规范、制定工作计划、项目整体的架构设计和架构优化、跟进项目进度、团队建设、与其他部门的协调沟通等。

 

对技术经理的工作年限一般要求 5 年以上,技术上对架构能力的要求高一些,本身至少也应该是个能够独当一面的架构师或技术专家,可以对标阿里的 P7 级别。不过,在具体要求上,大厂和中小厂是不一样的。大厂对技术深度的要求会更高,小厂则比较看重技术广度。但大厂基本很少对外招聘管理岗,同级别的高 P 技术岗反而会招得多。所以,大部分人只能在中小企业发展管理路线。另外,技术经理也不一定是从技术主管升上去的,也可以从高 P 的技术专家转岗的。

 

在管理能力上,对技术主管所要求的也同样对技术经理有要求,而且要求更高。比如,业务理解能力,技术主管更多只是停留在对业务局部的一些点和线方面,而技术经理应该精通业务,对业务应有全局观。再比如,团队建设方面,技术主管更多只是偏于对个人提供技术指导,而技术经理则需要制定具体的团队建设方案,比如制定技术培训方案,以提高团队整体的技术水平。

 

技术经理还有一个核心工作就是培养技术主管。如何培养呢?最核心的一点就是要懂得授人以渔,教以方法论,而不是一旦出现问题就直接帮他解决问题。技术主管上任初期普遍会存在一些不足,比如,在任务分解方面会做得不太好,经常会分解得不彻底,会导致增加很多沟通成本甚至任务延迟;面试时也不太懂得如何抓重点,会浪费很多时间;团队成员出现分歧时,也不太懂得如何妥善处理。这些都需要技术经理花时间、花精力去慢慢指导技术主管,要让技术主管明白背后的方法论,而不要简单地丢给他解决方案。

 

我做技术经理的时候,还担任过公司里某些业务线的技术负责人,统筹管理项目的技术研发进度,其实就是项目管理。有些公司,会设置专岗来做项目管理,一般称为项目经理。但不少公司和我一样,是由技术经理兼做项目管理的。另外,还有部分公司,会由产品经理来兼做项目管理。

 

其实,要做好项目管理,对业务和技术两方面都熟悉是再好不过的。毕竟,从流程来看,项目管理包含了需求、设计、开发、测试、上线五个阶段,前两个阶段是业务强相关的,后三个阶段是技术强相关的。因此,最好的项目管理人员,应该是既懂业务又精于技术的,才能更好地统筹全局。但现实情况却是这样的人比较稀少,所以,更多时候,一个项目的前两个阶段主要由指定的产品经理进行管理,后三个阶段则由指定的技术负责人进行管理。而统筹全局的人,则从两人中再指定一人,或直接由上级领导来统筹。所以,确切来说,我当时所担任的项目管理,其实只是技术层面的项目管理,统筹项目全局的是我的上级领导。

 

技术层面的项目管理,我主要采用敏捷开发方法,并结合 TAPD 或 TOWER 等工具进行管理。项目管理涉及到的具体事务不少,我只挑几个重点说一下:

 

代码分支管理:建议用 Git,不要用 SVN。要制定适合团队和项目情况的代码分支管理规范,可以从简单的 TrunkBased 模式开始,在实践中再不断去优化演进。

 

每日站会:站会的时间控制在15分钟内,目的主要是同步项目进度,发言要简明扼要、关注重点、禁止报流水账,可提出问题,但切记不要在站会中讨论解决问题,留待会后再去沟通解决。

 

复盘总结:每次版本迭代结束后,应该组织复盘总结会,这很重要,总结成功经验,吸取失败教训,有助于提升团队能力。

 

质量管理:这应该是项目管理中最重要但却是最难管理的一块了,其会贯穿整个研发流程中几乎每一个阶段。主要的管理工具包括测试驱动开发、设计评审、code review 等。

 

作为中层管理者,技术经理一般不会对基层员工进行直接管理,因此,想要管理好下面的整个团队,更需要提升自己的领导力,通过领导力而不是职权来让基层员工信服。

 

技术总监

 

高层技术管理岗,大厂和中小厂在这个级别上对管理者的能力要求,差距非常大。比如,阿里的总监级别,职级一般得在 M4 以上,M4 对应于 P9。阿里的职级体系有两条线,P 系列为技术岗,M 系列为管理岗,对应关系为:

 

P6 = M1,主管

P7 = M2,经理

P8 = M3,资深经理

P9 = M4,总监

P10 = M5,资深总监

 

再往上就不列举了,马云卸任前是最高级别,为 M10。

 

而一般小公司的技术总监,跳到阿里可能只会给到 P7 级别,很优秀的可给到 P8,能达到 P9 的绝对是凤毛麟角。大部分技术总监难以达到 P9 或 P8,很多时候是因为技术深度达不到高 P 级别的要求。因为小公司的技术总监,能力更偏向于“全能型”,优势在于广度,而深度难免会成为短板。而大厂因为分工精细化,对广度反而没什么要求,但对深度要求很高。

 

另一方面,大厂的高 P 们跳去小公司当技术总监或 CTO,很多人也会面临广度不足的问题,难以很好地统筹全局。因此,习惯了大公司“精细化”模式的人也未必能满足小公司“全能型”的需求。

 

所以说,大厂和小厂的总监,几乎是两个不同的方向。而我自己也没有大厂总监的经验,所以我在这方面的经验主要适用于中小厂。

 

我的总监级别的管理经验,也有三年多了,具体岗位担任过技术总监、研发总监、CTO。管理的团队人员最多时近百人,最少时则是从 0 搭建。当 CTO 的时候责任最大,但团队的人员却是最少的,最多时也就 20 多人,后来因为熊市来了,资金链断裂,融资失败,团队最终解散。担任研发总监时,管理的团队是最大的,整个研发部门有百号人,包括技术人员,也包括产品和运营人员。

 

作为技术总监/研发总监/CTO,最核心的能力就是能够组建和管理整个研发部门,打造出一个高效的研发团队。

 

先聊聊从 0 组建团队的经验,这方面我有过两次经历。从 0 组建团队,最核心的还是如何才能招到合适的人选。最优的方案就是从自己的人脉中入手,以前带过的下属,或熟悉的同事、朋友,觉得优秀合适的可以试着挖过来,每个岗位上的人员,最好都是能够独当一面,后续有能力担任技术主管的。我当 CTO 时组建的团队,有好几个核心骨干就是我以前带过的下属,他们之所以愿意跟随我,部分原因还是因为认可我的领导力。这里要补充说一下,前面我就建议从技术主管开始就重点培养领导力,因为,领导力发挥作用的时候,不只是对在职的团队成员。

 

次优的方案就是靠别人推荐了,最后的方案才是进行社招。而不管是推荐还是社招,有些岗位,技术总监可能不熟悉相应的技术,就难以考察候选人的实际能力。我自己倒不存在这样的问题,毕竟我自己是个全栈。但大部分总监却非如此,那么,我提供三种方案:

 

  • 请技术专家帮忙面试,并给予相应的酬劳。

  • 请技术专家出一些面试题,并提供参考答案。

  • 总监自己花时间去了解相应的技术。

     

这三种方案,效果一般也是由高到低。花点钱请相应的技术专家帮忙面试是最好的选择,现在普遍都是视频面试,也比较方便。

 

接着,再跟大伙分享下我管理近百人的整个研发部门的一些经验。整个团队包括了产品经理、设计师、开发、测试、运维、运营等人员,需并行研发多个项目。有些公司的研发部门可能不会包括产品经理、设计师、运营人员,不过没关系,管理方法也是一样的。

 

管理百人级别的研发团队,第一个核心工作,就是采用合适的组织结构。一般有三种类型的组织结构:职能型、项目型、矩阵型。

 

职能型的组织结构,即是对团队成员按不同职能划分为多个小组,比如分为:产品组、设计组、前端组、App组、Java 组、Golang 组、测试组、运维组、运营组。每个小组再分别设置一个组长,管理各职能小组的成员和相应的职能事务。主要优点就是能够发挥各职能小组的集中优势,人员调配上也有较大的灵活性。主要缺点就是在项目管理上,完成项目需多个小组相互配合,但项目经理缺少权力,协调难度较大,难以做到快速迭代。

 

项目型的组织结构,即是将团队成员按不同项目划分为多个项目组,每个项目组都分别有自己的产品、设计、开发、测试、运营等人员,每个项目组再分别设置一个项目经理,管理项目中的所有事务和人员。优点就是项目经理对项目可以全权负责,包括对项目成员也有全部权力,项目决策快、效率高,也可做到快速迭代。缺点则是项目组相对封闭,资源无法共享,很容易造成资源浪费,且项目之间缺乏交流,知识和经验也难以在不同项目组之间共享,对团队整体的提升造成阻碍。

 

矩阵型的组织结构,则是职能型和项目型的混合体,可对两种结构的优缺点进行取长补短,是目前大部分互联网公司所采用的方式。矩阵型结构,项目成员会有双重领导,职能经理和项目经理都是他/她的上级,对员工容易产生焦虑和压力。且如果权力划分不明确,两位领导容易产生冲突。

 

根据项目经理和职能经理权力的强弱关系,矩阵型结构还可以再细分为:弱矩阵、强矩阵、平衡矩阵。弱矩阵下,职能经理的权力更高,项目经理的角色更像个协调者。强矩阵则是项目经理有着更高权力,管理上更偏向于项目。平衡矩阵自然就是两位经理的权力都差不多,取平衡,而平衡之道其实也是最微妙的。

 

我这边主要尝试过项目型和弱矩阵型,从效果来看,弱矩阵型的组织架构会更加合适。至于平衡矩阵型,想要达到好的效果,需要精心建立管理体系,且对协调人的能力要求较高,而身边缺乏这样的人。另外,还有一种方案,就是让职能经理同时兼任项目经理,我曾任技术经理时就是这样,但我担任总监时,却缺乏符合要求的人。

 

作为技术总监,组建起研发团队只是第一步,想让这个团队变得高效,还需要做很多事情,也有很多方法,但回归到最本质上,还是要尽一切努力去激发成员们的善意与潜能。

 

总结

 

技术管理的方方面面还很多,限于篇幅,暂时就先聊这么多了。总结陈词,我只说两点:

 

技术一定不能落下,不管是主管,经理,还是总监,最最核心的还是技术。

 

“管理的本质,是激发人的善意与潜能。” 谨记这句话并时刻践行之。

 

作者丨Keegan小钢
来源丨公众号:Keegan小钢(ID:keeganlee_me)
dbaplus社群欢迎广大技术人员投稿,投稿邮箱:editor@dbaplus.cn

 

活动预告