做了六年多技术管理，聊⼀些经验总结
前⾔
我是从 2014 年开始正式⾛上管理之路的，在那之前虽然也有带过⼏个初级程序员，但毕竟不是正式的管理职位。正式踏上管理岗是从做⼀个⼩主管开始的，刚开始只管理⼏个⼈；之后担任过⼀些业务线的技术负责⼈，管理⼗⼏⼆⼗⼈；最多时管理百⼈团队，负责整个研发部门。⼀路从技术主管，到技术经理，再到技术总监，中间也和别⼈合伙创业当过 CTO。有空降管理过现成的团队，也有不⽌⼀次从 0 到 1组建团队的经验。
六年多的管理经验，说多不多，但说少也不少，肯定也有⾃⼰的⼀些⼼得体会，如今就⽤⽂字来和⼤伙分享我的⼀些经验总结。
我打算根据管理的三个级别来聊：技术主管、技术经理、技术总监。这⾥所说的这三个级别，并不是指代具体的管理岗位名称，可以简单理解为技术团队中的基层管理者、中层管理者、⾼层管理者，具体的再⼀⼀细说。
技术主管
如刚才所说，技术主管并不指代具体的岗位，⽽是指初级技术管理⼈员，主要负责管理某⼀垂直技术领
域，包括管理该领域的基层技术⼈员。⽐如 Android 主管、iOS 主管、前端主管、Java 主管、Golang 主管等。有些公司也称为技术组长，⽽且也不⼀定设置明确岗位。另外，在有些⼩公司，管理层级少，可能就没有设置技术主管的岗位，⽽直接挂名技术经理，⽐如我的第⼀份正式管理岗，挂名就是 App 技术经理，管理 Android 和 iOS。那时候的我其实既是基层管理者，也是中层管理者。这在⼩公司很正常，甚⾄处于初创期的 CTO，还需要同时担任⾼层、中层、基层所有的管理⼯作。
技术主管所管理的⼈员⼀般只有⼏个⼈，多的可能⼗⼏个。如果⼈员超过 20 ⼈，最好对团队根据细分领域做⼀下拆分。⽐如 App ⼈员如果超过 20 ⼈，那就可以拆分为 Android 组和 iOS 组，每组再分别设置⼀个主管，⽽原先的 App 主管则可以升级为技术经理。
对公司部门来说，技术主管优先考虑肯定是从内部⼈员中提拔，条件不满⾜的情况下才从外部招聘。⽐如，组建新团队的时候；或当前团队都只有些初级⼯程师，缺乏能够独当⼀⾯的⼈；或团队中都是些技术宅，只想专研技术，不想做管理。这些情况下，⼀般就需要从外部招聘合适的⼈选。
能荣升技术主管的，⼀般⼯作经验 3-5 年，专业技术能⼒已经⾮常娴熟，可达到资深级别，还具备⼀定的架构能⼒，能够独当⼀⾯。学习能⼒、沟通能⼒、对业务的理解能⼒等，也都是⽐较出众的。⼀般可以对标阿⾥的 P6 级别。
想要做好技术主管的⼯作，也不是那么轻松的。作为⼀名技术主管，平时⼤部分时间依然还是⽤在了
技术设计、写代码、解决 Bug 等⼯作，这和基层的程序员没多⼤区别。但是，技术主管除了需要做好这些程序员本⾝的⼯作之外，还需要花时间做开发任务的分解、分配，以及代码 review、技术设计评审、⾯试、和团队内外的⼈员沟通协作等管理⼯作。因此，想要做好技术主管的⼯作，提⾼时间管理的能⼒是很有必要的。不然的话，就会把⾃⼰搞得很忙很累，最后管理⼯作没做好，还影响了作为程序员本⾝的⼯作。也因此，有些⼈就会开始退缩，不愿意当技术主管，觉得会占⽤⾃⼰过多的时间，平时写代码的时间都不够，哪有时间做管理。想要在管理这条路上不断往上爬，这是必须要迈过去的第⼀道坎。
从程序员升级为技术主管，最核⼼的转变就是：从管理⾃我到管理他⼈。所以，我想谈谈关于管理他⼈的⼀点经验，主要还是分享下在选⼈和⽤⼈上我⾃⼰的⼀些做法。
关于招⼈选⼈，我有⼀个标准，也是我最看重的⼀点，那就是候选⼈的深度思考能⼒。不只是技术⼈员，包括产品经理、UI 设计、测试⼈员等，我都会考察他们的深度思考能⼒。深度思考能⼒越强的⼈，越能看到问题的本质，各⽅⾯的能⼒也会越优秀。
那么，如何考察候选⼈的深度思考能⼒呢？其实也简单，多问些为什么就可以了。⽐如，对于应聘架构师的候选⼈，可以类似下⾯这样层层追问下去：
1. 问：你们系统采⽤什么样的架构？答：微服务架构
2. 问：为什么采⽤微服务？答：为了快速迭代
3. 问：为什么⽤了微服务就能实现快速迭代？答：服务间解耦，可以分⼩组分别独⽴开发、测试和部署
4. 问：分了多少个⼩组？每个⼩组多少⼈？为什么这么分？答：……
这些相互关联的问题，是可以不断追问下去的，问题也并⾮有标准答案的，也并不是考察候选⼈是否知道正确答案，⽽是考察他是否思考过这些问题，是否有⾃⼰的⼀些想法。当然，候选⼈也不可能对所有领域的问题都能答得上来，所以尽量多⽅⾯考察，并尽量从候选⼈所熟悉的领域进⾏深⼊。
再说说⽤⼈⽅⾯，我⽐较崇尚于为下⾯每个⼈的⾃我成长⽽负责。我会去了解每个⼈的职业规划，为他们的职业发展路线提出建议，并在⼯作中不断给他们提供成长的机会，包括分配的任务、提供的技术指导和培训、定期的⼀对⼀沟通，等等。其实，从本质上来说，就是为了激发他们的善意和潜能。
我做基层管理时就已经开始实践选⼈⽤⼈的这些⽅法论，⽽且成效还⾮常不错。
符合我的标准招进来的⼈，做事基本都是很⾼效的，⼤多都能成为团队⾥的⾻⼲成员，有时还能做到远超我的预期，有着突出的表现。不过，有时候，长时间没招到合适⼈选或急需⽤⼈时，我只能减低标准，这时候招进来的⼈，则有些参差不齐了，部分⼈虽然也能完成任务，但成果就是不尽如⼈意。
也因为我⽤⼈的⽅式注重于他们的成长，所以，他们也很尊重我、⽀持我、追随我。我管理过的团队，离职率也⼀向⽐较低。
作为基层管理者的技术主管，建议重点培养⾃⼰的以下能⼒：
1. 专业技术能⼒：这是技术管理者的⽴⾝之本，肯定需要不断精进，如果技不如⼈，是⽆法服众的。
2. 业务理解能⼒：对业务有正确的理解，甚⾄能理解到业务的本质需求，才能让技术实现价值。
3. 任务分解能⼒：技术主管承担着开发任务分解分配的职责，如果分解不当，漏掉了⼀些环节，就会导致任务的延迟、质量的不可控，
为项⽬带来了风险。
4. 时间管理能⼒：管理者需要在有限的时间⾥⾼效地管理多种事情，⾃然就需要提⾼时间管理能⼒。
5. 团队建设能⼒：管理者的核⼼价值就是打造出⼀⽀优秀的团队。
6. 向上管理能⼒：向上管理没做好，会影响职业的发展，但切记，向上管理并不是拍上级的马屁。
7. 领导⼒：领导⼒不同于管理⼒，不能靠职权，⽽是靠个⼈魅⼒，建议尽早培养。需要明⽩⼀点，⼤
部分技术⼈员更喜欢被“领导”，
⽽不是被“管理”。
技术经理
技术主管作为基层管理⼈员，更多时候只是个执⾏者，要求能够「正确地做事」，能够带领⼀线团队⾼效地执⾏上级所交代的任务。
技术经理，作为中层管理⼈员，主要职责则是根据⾼层管理所确定的⽬标，制定实现⽬标的具体计划并保证实施，还要为最后的实现结果负责。
技术经理具体的⼯作职责，不同公司会有所不同，但主要可能包括：制定技术规范、制定⼯作计划、项⽬整体的架构设计和架构优化、跟进项⽬进度、团队建设、与其他部门的协调沟通等。
对技术经理的⼯作年限⼀般要求 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，资深总监
java技术专家
再往上就不列举了，马云卸任前是最⾼级别，为 M10。
⽽⼀般⼩公司的技术总监，跳到阿⾥可能只会给到 P7 级别，很优秀的可给到 P8，能达到 P9 的绝对是凤⽑麟⾓。⼤部分技术总监难以达到 P9 或 P8，很多时候是因为技术深度达不到⾼ P 级别的要求。因为⼩公司的技术总监，能⼒更偏向于“全能型”，优势在于⼴度，⽽深度难免会成为短板。⽽⼤⼚因为分⼯精细化，对⼴度反⽽没什么要求，但对深度要求很⾼。
另⼀⽅⾯，⼤⼚的⾼ P 们跳去⼩公司当技术总监或 CTO，很多⼈也会⾯临⼴度不⾜的问题，难以很好地统筹全局。因此，习惯了⼤公
司“精细化”模式的⼈也未必能满⾜⼩公司“全能型”的需求。
所以说，⼤⼚和⼩⼚的总监，⼏乎是两个不同的⽅向。⽽我⾃⼰也没有⼤⼚总监的经验，所以我在这⽅⾯的经验主要适⽤于中⼩⼚。
我的总监级别的管理经验，也有三年多了，具体岗位担任过技术总监、研发总监、CTO。管理的团队⼈员最多时近百⼈，最少时则是从 0搭建。当 CTO 的时候责任最⼤，但团队的⼈员却是最少的，最多时也就 20 多⼈，后来因为熊市来了，资⾦链断裂，融资失败，团队最终解散。担任研发总监时，管理的团队是最⼤的，整个研发部门有百号⼈，包括技术⼈员，也包括产品和运营⼈员。
作为技术总监/研发总监/CTO，最核⼼的能⼒就是能够组建和管理整个研发部门，打造出⼀个⾼效的研发团队。
先聊聊从 0 组建团队的经验，这⽅⾯我有过两次经历。从 0 组建团队，最核⼼的还是如何才能招到合适的⼈选。最优的⽅案就是从⾃⼰的⼈脉中⼊⼿，以前带过的下属，或熟悉的同事、朋友，觉得优秀合适的可以试着挖过来，每个岗位上的⼈员，最好都是能够独当⼀⾯，后续有能⼒担任技术主管的。我当 CTO 时组建的团队，有好⼏个核⼼⾻⼲就是我以前带过的下属，他们之所以愿意跟随我，部分原因还是因为认可我的领导⼒。这⾥要补充说⼀下，前⾯我就建议从技术主管开始就重点培养领导⼒，因为，领导⼒发挥作⽤的时候，不只是对在职的团队成员。
次优的⽅案就是靠别⼈推荐了，最后的⽅案才是进⾏社招。⽽不管是推荐还是社招，有些岗位，技术总监可能不熟悉相应的技术，就难以考察候选⼈的实际能⼒。我⾃⼰倒不存在这样的问题，毕竟我⾃⼰是个全栈。但⼤部分总监却⾮如此，那么，我提供三种⽅案：
1. 请技术专家帮忙⾯试，并给予相应的酬劳。
2. 请技术专家出⼀些⾯试题，并提供参考答案。
3. 总监⾃⼰花时间去了解相应的技术。
这三种⽅案，效果⼀般也是由⾼到低。花点钱请相应的技术专家帮忙⾯试是最好的选择，现在普遍都是视频⾯试，也⽐较⽅便。
接着，再跟⼤伙分享下我管理近百⼈的整个研发部门的⼀些经验。整个团队包括了产品经理、设计师、开发、测试、运维、运营等⼈员，需并⾏研发多个项⽬。有些公司的研发部门可能不会包括产品经理、设计师、运营⼈员，不过没关系，管理⽅法也是⼀样的。
管理百⼈级别的研发团队，第⼀个核⼼⼯作，就是采⽤合适的组织结构。⼀般有三种类型的组织结构：职能型、项⽬型、矩阵型。
职能型的组织结构，即是对团队成员按不同职能划分为多个⼩组，⽐如分为：产品组、设计组、前端组、App组、Java 组、Golang 组、测试组、运维组、运营组。每个⼩组再分别设置⼀个组长，管理各职能⼩组的成员和相应的职能事务。主要优点就是能够发挥各职能⼩组的集中优势，⼈员调配上也有较⼤的灵活性。主要缺点就是在项⽬管理上，完成项⽬需多个⼩组相互配合，但项⽬经理缺少权⼒，协调难度较⼤，难以做到快速迭代。
项⽬型的组织结构，即是将团队成员按不同项⽬划分为多个项⽬组，每个项⽬组都分别有⾃⼰的产品、设计、开发、测试、运营等⼈员，每个项⽬组再分别设置⼀个项⽬经理，管理项⽬中的所有事务和⼈员。优点就是项⽬经理对项⽬可以全权负责，包括对项⽬成员也有全部权⼒，项⽬决策快、效率⾼，也可做到快速迭代。缺点则是项⽬组相对封闭，资源⽆法共享，很容易造成资源浪费，且项⽬之间缺乏交流，知识和经验也难以在不同项⽬组之间共享，对团队整体的提升造成阻碍。
矩阵型的组织结构，则是职能型和项⽬型的混合体，可对两种结构的优缺点进⾏取长补短，是⽬前⼤部分互联⽹公司所采⽤的⽅式。矩阵型结构，项⽬成员会有双重领导，职能经理和项⽬经理都是他/她的上级，对员⼯容易产⽣焦虑和压⼒。且如果权⼒划分不明确，两位领导容易产⽣冲突。
根据项⽬经理和职能经理权⼒的强弱关系，矩阵型结构还可以再细分为：弱矩阵、强矩阵、平衡矩阵。弱矩阵下，职能经理的权⼒更⾼，项⽬经理的⾓⾊更像个协调者。强矩阵则是项⽬经理有着更⾼权⼒，管理上更偏向于项⽬。平衡矩阵⾃然就是两位经理的权⼒都差不多，取平衡，⽽平衡之道其实也是最微妙的。
我这边主要尝试过项⽬型和弱矩阵型，从效果来看，弱矩阵型的组织架构会更加合适。⾄于平衡矩阵型，想要达到好的效果，需要精⼼建⽴管理体系，且对协调⼈的能⼒要求较⾼，⽽⾝边缺乏这样的⼈。另外，还有⼀种⽅案，就是让职能经理同时兼任项⽬经理，我曾任技术经理时就是这样，但我担任总监时，却缺乏符合要求的⼈。
作为技术总监，组建起研发团队只是第⼀步，想让这个团队变得⾼效，还需要做很多事情，也有很多⽅法，但回归到最本质上，还是要尽⼀切努⼒去激发成员们的善意与潜能。
总结
技术管理的⽅⽅⾯⾯还很多，限于篇幅，暂时就先聊这么多了。总结陈词，我只说两点：
1. 技术⼀定不能落下，不管是主管，经理，还是总监，最最核⼼的还是技术。
2. “管理的本质，是激发⼈的善意与潜能。” 谨记这句话并时刻践⾏之。