当研发团队来了不懂技术的领导……

管理学大师 Peter Drucker 有一句名言：

管理人员是与人打交道，其任务是使员工能够协同工作、扬长避短。

正如 Drucker 所说，作为管理者，我们的目标很清晰了。既然需要帮助员工实现以上目标，那么管理人员至少要能够明白员工的工作流程、内容，清晰地知道当前工作方式和模式下存在的优缺点，如果管理人员自身就是这一领域的大牛，那么他既能理解问题，也能解决问题，就好比能够做个既能干又通情达理的好婆婆。那么，如果实际情况超出了我们的设想?突然之间从其他部门调过来一位领导，而这位领导又完全不懂技术，那情况会怎么样呢?(事实上，这种情况并不少见)我们逐一讨论。

研发团队领导职责

前几天和朋友吃饭，他是 BAT 出身，习惯了在技术大牛领导带领下干活，而后工作换到了现在的大公司，刚开始境况还是相同，忽然有一天换了基本不懂技术的领导来带他，噩梦开始了：交互过程中频频出现不在一个频道的情况，而对于技术方案的差异看待，成为了直接的导火索，导致他们之间发生了激烈的争执，进而导致他吃到了两次季度不佳评价。他一度想主动离开，毕竟技术还在，不愁没工作，但转念一想，这种情况可能在哪都会出现，即便回到过去的环境，也不能保证一辈子不碰上，既然现在碰到了，就想办法应对，最不济就当交学费吧。

换位思考后，他开始不断自我调整，摆正心态，积极主动地与那位领导沟通，了解他的困难。现在，他俩好得和亲兄弟一样，工作上他成了领导的技术顾问，领导也把他当成自己的左膀右臂。但是，说实在的又有几个员工愿意这么做呢?很多人是不愿意这么做的，他们会认为这是委曲求全，此外，这种情况下也确实容易让员工出现“天花板现象”，毕竟那位领导可能不太会有上升空间了。

进一步扩展 Drucker 的想法，我认为，作为研发团队领导，我们的主要职责是组织整个团队的工作，合理安排、高效协调。同时，当他们出现任何问题时，无论是技术问题，还是管理问题，亦或者个人问题，我们都要能够给予有利支撑，让他们感觉背后有人站着，而不是背后就是悬崖，这样才能做到高质量、高效率地输出成果物，无论是技术上的，还是产品上都能输出优质的成果物。综合这些要求，坦白地说，我认为不懂技术的人如果做了研发团队的领导，很容易出现严重的问题。

理解研发团队领导工作

研发团队领导实质上在做的是技术管理工作。技术管理是一种组织团队一起进行研发的工作，它是一门细分工种，随着社会的进步、人类思维的开放、经济水平的提升，被管理者(工程师们)逐渐从单纯为了解决物质矛盾转化为追求工作的归属感、参与感、技术尊重感，他们逐渐地对跟着谁一起工作、采用哪种工作方式、解决了什么样的技术问题、做出了什么样的产品感兴趣，而不是仅仅满足于金钱多少。同时，被管理者之间还存在紧密的社交媒体关联关系，能够保持沟通，共享着对于在该公司 / 组织工作的感受，共享着对于管理者的能力、品德认识，这也是一种共享过程。我们每位技术团队管理者，也正在像书一样被摆放在被管理者面前，如果别人懒得翻你，就证明你不能给予他们指导，他们不会有归属感，最终都会匆匆离职。

可能会出现的问题

会出现哪些问题呢?比如研发团队会举办各种技术会议，产品需求、总体设计评审会议、调研项目技术选型会议、预研项目预研报告评审会议等等，其实也基本上是一个研发团队的大部分工作内容。这样问题就来了，如果他不懂技术，你觉得我们在召开会议的时候，这位领导到底需不需要参加?如果是一位技术专家出生的人，问题就变得简单了，毫无疑问他需要参加，因为很多技术设计环节需要他把关或批准，一些技术难题他可以牵头解决。

但如果情况相反，这时候就会出现麻烦。他参不参加，都会引起麻烦：如果参加，可能给不出任何意见，说不定还乱指挥，如果不参加，时间长了他自己会感觉被架空，说不定引起团队内部的大清洗。这是单纯从日常的技术工作上去考虑问题，我们每天需要应对的事情，也正是整个团队需要应对的，大家得在一个频道上，不然沟通起来确实很麻烦，增加沟通成本的同时也在消耗内部资源。

说完了技术日常工作，再来看研发过程管理。对于整个研发过程的管理，不懂技术的人很容易完全从产品角度出发，忽略研发团队面临的困难和风险，忽略技术人员对于技术的憧憬，造成团队超负荷工作的情况、技术团队缺少技术愿景等情况发生。举个例子，遇到业务方提出的需求完成时间点过于苛刻的情况(其实这是一个压力传导问题，业务方收到了客户的压力，本来可以通过向客户解释等方式减少研发的压力和风险，但是选择直接施压研发)。

这时候，你这位不懂技术的团队老大可能会说，没关系，我们一开始并不需要一个完美的系统，你先上了再说，先解业务的渴(怎么解渴其实他也说不清楚)，我们后面有时间再重构再完善(当然有的技术人员也会用“架构和设计是逐步演化出来的”这句话来证明“故障驱动”开发是值得的)，这样的想法本质上是错误的。

其实我们不应该把责任一股脑推卸到产品思维上去，我认为一名合格的研发团队领导，他本身就必须具备一定的产品思维，这样才能更好地让技术为产品服务，做好技术的落地工作。我们需要担心的也是很多时候容易出现的情况，这位领导的产品思维也是半桶水，这时候他口中的用户需求，是否准确我们得打问号，是否能够与研发体系融合在一起就更需要质疑，也许正是因为他本人的能力问题，造成产品牵着技术往前赶，而不是有条不紊地落地。

不懂技术的研发领导，虽然他不懂技术，但是他肯定懂别的，例如产品、运营等等。去年有一次和一位通信运营商高管聊天，她说自己所在的企业，选择的高管一般会来自三个领域，产品、运营、技术。无论他来自哪一个领域，他一定不会放弃自己所熟悉的领域，否则就做得有点虚了，而对于自己不懂的领域，比如技术领域，如果他觉得在技术上缺少抓手的时候，他就会迅速地寻找自己在团队内的技术代言人，只有找到这样的人，他才能真正对团队进行掌控，不让自己在技术上落虚。但是如果短时间内找不到，或者没有人愿意担当这样的角色，怎么办?

这个时候他可能会开始转向软件开发流程，因为这一点上的管理模式似乎和其他部门的管理方式差不多，拿需求、干活、输出给用户、接受反馈意见，看起来好像确实差不多，是吗?不是的，科技行业研发项目的产品需求不等同于用户需求，它是对用户需求的产品化转换。下地干活之前，一定需要对系统进行设计，无论是瀑布式开发模型，还是 XP、敏捷，都没有否定设计环节，而是对实现方式、模块划分方式进行切分，通过对于系统架构的树形结构进行有效切分，达到快速需求收集、设计、实现、验证、需求再收集、设计修改、实现、再验证，这样的快速重复过程，实现高效的迭代，满足各个行业用户的需求。

需要记住的是，无论对于懂或不懂技术的研发领导而言，任何的软件工程模型，都不会允许在需求完全不明确、描述不清楚的情况下，开始进行技术方案设计，也不会鼓励在方案设计缺失情况下开始编码，因为这个时候没有人知道究竟如何编码。

我的理解如果没有外界的干扰，许多程序员在独自面对自己的设备时通常都会很投入地写代码，一边写一边设计。研发团队管理者必须培养软件开发文化，而文化又是建立在可靠的开发实践基础上的，否则程序设计项目就可能失败。

这里需要聊一聊研发领导需不需要编码，我觉得，其实无关是否需要编码，如果是一家成熟的科技公司，它应该从多个维度评审技术团队管理者的工作过程和成绩，而不是采用单一化规则进行评判。关键看你的输出是否需要编码，是否编码是验证你的输出或者贡献的关键环节，如果是关键环节，那你就需要编码，如果编码的价值没有技术全局把握的价值大，那么你需要把时间用在编码以外的方面，毕竟，对于技术团队管理者，产品研发、技术调研和预研、系统架构设计、未来技术方向明确、团队管理等，都属于你的工作内容。

我认为，团队领导完全可以不是对口技术专业出身，甚至可以不是理工科毕业，但是他必须对技术有热情，之前工作经历包括了开发工程师经历(这其实是必要条件)，其实懂不懂技术和是不是专业出身没有任何关系，事在人为，关键看你有没有认真去做积累。有一个同事，以前是学法律的，后来转行写代码，写出的代码比很多写的年份多得多的人还强的多。她对法律相关的思维缜密，很好地就转移到了代码逻辑的缜密上，不学自通。这就是程序员，你用正常思维理解不了他们的成长路线。研发领导需要对技术有敬畏之心，需要能够有效地掌控团队的技术输出，总结为以下几点：

基础知识和理论知识非常重要，不懂技术的领导应该利用业余时间多学习，不断强化自己的弱点，慢慢地可以跟上团队的研发节奏。其实勤能补拙的道理大家都懂，就看会不会真正去实践了，保持自己终身学习的状态，看看巴菲特，每天的学习时间都会超过 6 个小时，可见每一个人都需要不断学习、思考。

多使用已有的成熟的方案是稳定当前状态的关键手段，不懂技术的领导需要在团队内培养技术代言人，通过和他的交流，逐渐明确对于技术方案的意见、理解，慢慢地你也就有了对于技术的抓手，可以有效开展工作。

对技术要有一颗严谨和敬畏的心，只有这样你才能够真正和技术人员打成一片，没有他们的帮助，最终领导的绩效也不会好，互相尊重非常重要，都是高学历的人，别把工程师的木讷当成傻。

想清楚了再干，坚持高标准，很多事情都急不来，任何的软件开发流程，都是基于软件工程模型推导得来的，都是为了解决某一类特定问题而演化得来的，所以要深入理解方法论，只有理解了才能用好。

明确技术愿景。这一点对于研发团队的稳定性和成长性非常的重要，不懂技术的领导很难在短时间内明确技术愿景，因为他自己不懂，所以要么轻视这一点，要么无从下手，这时候，团队内部的技术大牛的作用就出现了，领导需要积极主动地与这些大牛沟通，通过分派任务、搭建团队梯队等形式，让这项愿景明确工作能有实质性进展，避免研发团队出现纯粹的支撑产品状态。

写在最后

今天我们具体讨论了研发领导如果不懂技术怎么办?首先，我的观点是如果研发领导不懂技术，那么会容易造成团队内部人员高频率流动，也会造成技术人员缺少技术支撑，也更有可能让技术人员遇到“天花板现象”。其次，容易出现业务严重驱动技术的情况发生。再者，可能会出现乱用项目管理手段的情况出现。所以，我的观点是最高管理层应该尽量避免这种情况出现，通过任职资格等方式进行严格把控，做到能上能下，需要用专业的人带领专业的团队。

但是如果真的遇到了，作为普通员工，我们还是需要面对现实、认清形势，既然最坏的情况已经出现了，如果想继续待下去，就要努力成为他的技术顾问，你就当是在和 CEO 一起工作吧，做好自己的向上管理，无论前途是否艰难，都要咬着牙走下去，只要别人不赶你，你就做下去。