（转）研发leader成长手册（一）

   

      近来和一些担任研发leader的同事和朋友交流中，发现部分同学，在研发leader的岗位工作上遇到了瓶颈。具体的问题，有个人发展空间上的，有工作内容上的，有时间精力安排的，有对外合作配合的，笔者仅以自己过去的经历和对leader工作的理解，分享一下对成为一个成功的研发leader的视角、观点。

 

       研发leader的工作内容，可以分为以下几个方向：

        1.  技术方向工作 

        2. 规划方向工作（目标、计划、执行、制度等）

        3. 协调方向工作（跨部门沟通、跨部门项目协作）

        4. 团队方向工作（招聘、培养、沟通、团建、宣传等）

 

 

在这几个方向上，分4个主题，逐个来分析、探讨。这4点交融在leader的工作中，因此每个方向探讨时，会有互相交叉的部分。

 

技术方向篇

-------------------------------------------------

在技术工作方向上，容易出现的三个误区：

1.  技术leader是团队的产出核心，其他人辅助工作

2. “我”是做技术的，产品、运营做的好不好，不关我事

3. “他们”技术不行，培养太花时间，等他们做完，我早做完了

下面我们来刨析这三个误区，看看这么做leader工作会带来什么问题。

 

 01.技术leader是团队的产出核心，其他人辅助工作

 

作为研发团队的leader，首先要做好技术方向的工作，这是这个岗位的最基本职责；大部分研发团队的leader，都是因为技术工作做的比较好，而被提拔为leader，给予晋升空间和发展空间。但是技术leader的职责不仅仅是技术方向的工作，还要承接更多的岗位职责，大部分leader感到工作瓶颈，都是在非技术工作上面。

 

在技术方向的工作职责之外，其他的职责，是初晋升研发leader所不了解、不擅长的，此时如果没有得到很好的帮助或自己思考想清楚，工作便会出现一个迷茫期，不仅影响自己的发展，也影响团队的整体产出。笔者也未幸免，曾经在非技术方面折腾过一段时间，深为苦恼，甚至怀疑自己是不是应该回去做技术专家，而不是去带技术团队。

 

我从这个坑里爬出来，最直接、最重要的一个因素，是意识到了研发leader的岗位职责变化。研发Leader的岗位职责是要看团队整体的产出效率，而不是看个人的产出效率。作为曾经的研发好手，在技术问题攻关、代码编写质量、速度方面，是自己的长项，晋升leader也是因为这些方面的强项，被公司、上级所认可。这会给晋升的leader们一种错觉，技术能力和项目产出是自己的主要贡献。

 

在这种“leader观”下，会不幸的形成以自己为技术中心、其他团队成员协助工作的模式；项目里最难、最重要的部分，由leader攻关、实施；leader成为团队最忙、负载最大的同学。这种情况在早期阶段，依然可以运转一段时间，但是随着时间的推移，因为leader其它工作职责的加入，把leader已经被技术工作占满的时间、精力，轻易的给“引爆”。

 

团队成员遇到了工作的问题、招聘面试量的增加、和PM沟通讨论产品方案、和业务方开会讨论需求、开展晋升绩效的沟通、团队工作汇报的准备等等，会迅速的开始消耗leader的时间精力，使得leader主导的技术攻关、项目攻关，出现延期、失败，而团队其他人由于技术能力问题、分工安排问题，不能有效支持项目推进。此时，Leader不得不面对这个现状，为了摆脱这个“陷阱”，做出选择。

1. 拒绝技术工作外的管理工作，来保障技术工作的完成；

2. 投入时间做好管理工作，但技术工作陷入混乱；

3. 对管理工作敷衍，依然把主要精力放在技术工作上，保障技术工作的完成。

 

  笔者当年走过由A到C，再到B的过程，所以在今天的工作里，对团队里的技术leader，非常能够理解他们遇到的工作上的问题。下面我说一下我自己的经历。

 

  刚开始，我对自己被提拔为技术leader非常兴奋。作为一个疯狂的技术爱好者，这种晋升，我认为是对技术能力和产出的一个认可，非常有成就感。我把这次晋升，当成了一个奖励，丝毫没有意识到随岗位的变化，我的职责也变了（当然也没有人真正严肃的对我说，我的职责变了，要求的能力模型变了）。也丝毫没有意识到，除了技术能力，其他方面我都没有达到一个leader的能力要求，处于“不知道自己不知道”的状态。于是更以加倍的热情，投入到开发工作里，绝大部分时间都是在做开发，少部分时间分下任务给团队其他人。

 

 由于是团队leader，HR开始安排更多的面试工作，自己部门的、其他部门的，在面试工作的时间上，基本增加了一倍以上；项目经理、客户（内部需求方和外部客户）开始找我沟通项目的安排、进度，会议的量开始增加…… 是的，各位leader今天遇到的问题，我也没意外的遇到了。我热爱技术工作，我是技术极客，干嘛让我把时间花到这些“虚”（不是写代码，都是虚的）的事情上呢？I reject！

 

  但是拒绝不了多久，就被我的老板谈话了。这些事我不参加、不做，对应的伙伴们，自然就要找我的老板投诉了。当然这也不难沟通，作为leader那些事是要做的，只是我不喜欢，那如果还要做leader的话，就得改变自己啊！价值观是杠杠的，调整自己认真对待技术以外应该承担的工作。但是我的精力客观上是有限的，白天用了40%-50%的时间在这些问题上，技术工作就只能继续用自己的夜晚时间来补充。熬夜到12点后，成为一个常态。【曾经有一回，在公司加班到1点，开车回家的路上，我睡着了…着了…了，以60KMPH的速度，撞在了前面一辆现代SUV上，还好相对速度不那么大，车损人未损。阿弥陀佛，如果不撞上这辆车，我撞上的，将是50米前方的两个水泥路障，当时在施工建设地铁，阿弥陀佛，救命之恩！】

 

  好吧，知道不能这么下去了，我在认认真真的想，我是不是该回去做程序员？我是不是根本就不适合做管理？在这种不坚定、不明确的状态下，对非技术类的工作，进入一种敷衍的状态，开会时经常两个耳朵听着，两只手在看着屏幕敲代码…… 不知道当时的同事们有多想骂我，在此对你们说声sorry！然而我一直没有下定决心往回撤。因为人都要上进，没干好的情况下往回撤退，我岂不是懦夫。隐隐的感觉到，我自己遇到了“瓶颈”，我需要突破自己。也就是说，进入了“知道自己不知道”的状态。

 

  转机出现在一次去广州出差的路上，在机场买了一本《领导阶梯》，完全是偶然的在机场买了一本。里面明确说明了一点，作为首次晋升的leader，根本的转变，是我从个人贡献者，转变为一个管理者。两者的差异，在于职责上，Leader要对团队的结果负责，而不是对Leader自己在其中的比例负责。进一步，我做了以下的思考。

 

  假如我们团队有6个人，我个人超强，一个人贡献团队40%的产出；其他人平均每人贡献12%的产出（合计算100%）；假如我通过管理工作，让团队的外部环境井然有序、任务明确，并致力于指导、提高团队成员的能力，让每个人的产出，提升一倍，我自己的个人贡献因精力转移降低60%，降到16%；此时我们相对以前，整体的产出是 （16% + 24%*5）= 136%。这样，我做为leader的杠杆效用，就出现了：通过我的工作，团队的整体产出增加了。

 

  懂得这个逻辑无比的重要，能让自己下定决心转型，做好外部工作，做好内部指导、培养工作，通过自己的工作提高团队的整体产出，给团队每个人带来成长。对leader的考核，应该是团队的整体产出情况，而不是leader个人做了那些具体的事。

 

  因此，技术leader在技术工作上，应该把精力转移到那些体现leader价值、高杠杆率的事情上。包括：

1.  和产品经理或项目经理沟通、明确项目需求，让团队的技术工作不乱

2. 系统架构设计、核心算法设计、主要性能攻关

3. 提高团队成员能力、引进合适人才

 

02. “我”是做技术的，产品、运营做的好不好，不关我事

 

  这个观点虽然我们一看就知道不合价值观，但是在实际的工作里，却是一个挺常见的现象。作为技术leader，保障在技术上把产品、运营的需求，用代码给做出来，变成产品、服务。

 

  一般来说，我们都清楚产品经理对自己的产品目标负责、运营经理对自己的运营方案效果负责；那么作为研发的负责人，我们可以独身于事外、对产品和服务的实际结果，不加关注嘛？

 

  很抱歉的说一句，笔者也曾经有过这样的思维。我负责技术团队，确保技术团队的战斗力，把交给我们实施的需求，都给实现了，就起到了研发这个环节的责任、体现了研发的价值。直到有一次和高德的总裁董振宁先生请教，他对我说：从公司角度看，无论是做技术的、产品的还是做管理的，负责人们都是业务干部，业务做没做好，是考核干部合不合格的标准。

 

  一席话激起千重浪，深刻的击中我自己的认知盲点。对于干部，公司的期望是完成业务目标，拿到业务结果；我们不能在业务结果不好的情况下，说我们产品设计是没问题的、我们开发交付是没问题的，这不叫责权明确，对于干部来讲，这叫甩锅，而且锅只能是给老板来接。

 

03.“他们”技术不行，培养太花时间，等他们做完，我早做完了

 

  我不知道有多少leader们，有没有心里想过、嘴里说过这句话。笔者心里想过，嘴里没有说过。作为因技术能力强、技术产出高而在team里被提拔起来的人，有实力说这句话。客观的实际工作里，也有这样的情况，我们要不要自己动手，取代团队成员应该完成的工作？

 

  我认为是不行的。

 

  首先，精力是不允许的。Leader还有很多其他方向的工作，在写代码这个非常耗时间精力的事情上投入，会严重影响其他工作的展开。一个团队，如果leader不能打理好内外环境，很快就会进入效率降低的阶段。取代他们的职责，是拆东墙补西墙，团队整体的产出依然下降。

 

  其次，对成员的发展不利。遇到困难不能克服，就让leader来做，那成员是很难成长起来的。我们的成长，70%来自于工作。遇到困难时，也是他们成长的最好机会。此时做为leader，应该是花时间帮助他，指导他。这也花时间，但是和直接自己取代来做不一样的，团队成员的能力会因此提高，给将来团队的整体实力、产出提高打下了伏笔。这样既推动了项目的完成进度，也提高了团队的成长。

 

  笔者曾经经历过这个阶段，当时公司成本控制，招聘的同学的技术能力在行业里偏低，水平一般。大部分的工作也是我在做。后来我改变了策略，不管如何，把任务分给他们，约定完成时间。到项目周期的1/3时，我会review下所有人工作的进展情况，分情况进行不同处理：

1. 进展符合预期，不管他了，让他继续往前做。

2. 进展高于预期50%以内，给予指导，在这个项目上，给他建议，提高效率。

3. 进展低于预期50%以内，拿过来我做，追赶上项目工期。

 

  真正落到C选项的，实际很少，大部分在A和B里分流了。对于A种情况，对应的工程师会给予更多的项目和职责，快速成长起来；对于B种情况，对应的工程师能够有效得到帮助，能实实在在的提高自己的工作水平；对于C情况，如果不能带起来，就只能优化了。

 

  最后，如果用这样的思维思考，团队内的氛围会比较差。成员不能承接自己本应该承接的工作，得不到成长锻炼的机会，没有有效的产出，会很容易产生不安全感；人在不安全感的情况下，容易会去互相推脱责任，互相指责、力求自保，诉求最基础的“我没错”的安全需要。

 

  这种氛围下，团队就带散了，有能力的人会离职、转岗，没能力的人会力求不犯错，做为leader的老板，不得不出来解决这个团队的稳定性问题。还好，笔者没有这么干过：）

 

  综上所述，我给研发leader们三个建议：

1. 在技术工作上，当退则退，保持30%的精力，在某个技术方向上做深，利用业余时间提高技术广度。保持技术深度和广度的同时，留出精力去做管理性的工作。充分挖掘团队资源，去完成团队任务。

2. 作为技术leader，身在技术，心在业务，始终站在业务成功的角度思考问题。

3. 为团队培养人才、引进人才，优化不合适的人才；是团队建设永远正确的真理。

 

感谢各位阅读，欢迎留言，一起交流学习；并敬请期待下篇，一起来探讨规划方面的工作。

 

本文以笔者工作经历为素材，进行思考、总结，肯定有不足、不对之处，欢迎各位读者斧正，请加我的微信（windows2000d）或关注公众号，共同学习、提高。