前言

笔者从15年5月开始从带3人小团队到目前10人左右规模，从一线研发工程师到Team Leader（下文简写为TL）身份转换的过程中，曾经有过很多迷茫与困惑，完成转换之后总结一些心得写到这篇文章中。

降低编码的时间

多数技术团队的Leader都是从表现优秀的一线工程师中提拔上来的，这个现象在其他行业也普遍存在。而作为工程师本能的希望自己每天继续写代码，沉浸在自己的代码世界中，努力提高技术水平

针对问题上，笔者的建议是，最大程度的降低自己的编码时间。

首先需要想清楚TL该做的事情，总结起来有以下两点：

如果TL每天花大量的时间投入到编码中，那么最终带来损失的是整个团队。

首先，团队的成员会在TL高超的技术水平的光环下，极度缓慢的成长，因为如果大量的需求开发工作被TL搞定了，团队成员就很难有机会得到锻炼。

第二，团队中的真正只有TL能解决的问题被搁置，比如团队成员间配合时的摩擦。比如同兄弟团队配合过程中流程上的问题等等。这些问题一旦被搁置，对团队自身的伤害非常大。

TL要时刻牢记自己如何发挥最大的价值，给团队带来产出，跳出自己原有的“熟悉域”，站在更高的角度去思考。

首先一定不要走极端：那好吧，我不写代码了，让团队内其他同学去写吧，我就处理其他事情，代码写成啥样也不关心了。

笔者建议分配时间的30%来“处理”代码，“处理”的含义在于，可以是直接写代码，或者是Review其他人写的代码。

前面提到TL的职责，你需要为结果负责，对成员的成长负责，因此花时间去Review代码，给其他成员一些指导和建议是很有必要的。在这个过程中也可以发现工程内潜在的问题，并且作为TL推进解决。

作为TL很重要的一点在于为团队内的其他成员服务，了解他们的诉求，分析他们阶段性的问题，并帮助他们去解决。

周期性的一对一沟通是非常有必要的，也是作为TL一定需要花大量时间去做的。

很多工程师的性格都很内向，但一定要迈出这一步，经常性的聊聊天，将你看到成员自身的问题及时反馈出来，并且给出指导建议，对于团队成员的成长是非常有利的。

首先沟通的诀窍只有两个字：真诚。

很多TL自身不参与代码开发但非常喜欢拍板，无论大小都要经有TL决策。

从效率角度出发，如果TL成为决策的瓶颈，TL自身的效率将会大大降低，每天需要处理无数的事情，大脑基本要爆炸了，团队推进事情的效率也将降低，因为任何事情都要等待TL来决策。

从团队成员角度出发，不做决策意味着可以不对决策产生的结果负责，长期下来也就不需要针对事情做过多的思考了，思考少了成长自然也就少了。与此同时他们更多的工作就是一个执行者，对事情没有决策权，每天的成就感也会大幅降低。

一个团队的价值观决定了这个团队的行为方式，以及战斗力。

因此从一开始TL就要思考我希望的团队文化是什么样的，团队成员的价值观应该是什么样的，并且在工作的过程中去传达。

比如希望打造学习型的团队，希望团队中每个成员除了开发以外，能够有提高，那么TL就需要去思考一些能做的事情，传达这个想法。

TL的行为方式也会潜移默化的影响到团队中的其他成员。如果口号喊一套，实际做事是另一套，那么事情推进起来就不会很顺利。所以一定要以身作则，为团队成员梳理标杆，让大家明白TL是这样做的，那我也应该这样做。

Team Leader是一个很关键的岗位，在这个岗位上也需要非常多的思考。简单的做了几条总结，希望能够帮助新人TL，文中的很多观点也是基于现有的认识和经验做的总结，欢迎留言。