初次做技术领导的3个陷阱
不要错过作者之前发表的文章高效技术领导的5个锦囊妙计
开发人员初次走进技术领导（后文简称TL）这个角色的时候都是很困难的。即便经验再丰富的开发人员，他的技能和经验也是不能自动转换成一个TL必备的技能的。事实上，如果开发人员不能很好地运用已有的技能和经验，或者不能在这个新角色中树立更多权威，一些旧有的习惯不但没有帮助，反而会带来阻碍。
这篇文章，我们一起来探索一下初次做TL时容易踏入的三个陷阱，以及他们可以做些什么来避免绕过这些陷阱。
1. 所有时间都在编码
开发人员初次做TL往往会手痒痒想去写代码。事实上，他们很容易误认为自己需要通过一直不停地写代码来证明自己的领导力。的确，一个高效的TL是需要一些时间来编写、阅读以及检查代码，但一旦他们花太多的时间去编码，其他的职责就容易被忽略掉。例如，创造一个技术愿景，以及确保团队成员理解核心的系统质量属性。
缺乏技术愿景可能会导致三种不同的实现，开发人员会觉得他们自己想的是最好的，或者部署可能失败是因为开发人员不知道操作约束或者生产环境的差异。更糟糕的情况是，如果一个开发人员不考虑维护性而选择了非主流的方式，或者压根不知道系统是如何随着时间推移而演变，他们写出的代码就必须不断地被改写
稍微有些经验的TL知道他们必须平衡编码和其他职责的时间。他们将时间以天为单位或者至少以周为单位进行分割，这样就能确保关注到其他职责。比如，构建一个共享的架构愿景，识别和解决技术风险，计划会议以及关注团队和代码的内聚性和稳定性。
2. 做了所有的技术决定
一个新的TL通常是团队中经验最丰富的开发人员，他或许会有种压力感导致他们要做所有的技术决定来证明他的权威和影响力。TL一个人对技术说了算意味着他成为了团队的瓶颈，此时团队离开了TL就无法取得进步了，团队其他成员也会失去动力，因为TL做了所有的重要的决定意味着他们的贡献都被否定了，而这只会让他们心生不满。
有经验的TL知道他们可以有很多种方式去做决定。通常，最好的决定是源自于整个团队的经验和技能，而非某个个体。下面列出的一些值得借鉴技巧，而它们取决于决定的重要性、紧急程度以及他们想要从团队成员中获得多少的承诺：
- 仅仅委派 - 在没有任何沟通的前提下，TL将决定告知某个成员。
- 提供建议 - TL将决定委派给某个成员后，还提供了输入和自己的建议。
- 询问调查 - TL将决定委派给某个成员后，还对后续的产出和影响因素做了跟踪调查。
- 达成共识 - TL将团队所有成员召集起来，让大家对某个决定达成共识。
- 独裁专制 - TL运用自己已有的信息去做决定，至于要不要和团队成员商量完全看自己的意愿，最后将结果告知大家。
3. 忽视了团队文化的培养
一个团队是一群有共同目标的人在一起工作。新的TL可能会误以为他们的角色就是在所有的技术方面做出表率，而忘了关心团队是怎么一起工作的。虽然像团队领导者和项目经理这样的角色也肩负这个责任，TL也要带领着团队像同一技术方向前进。
同样，新的TL也很容易忽视了两个开发人员之间激烈的讨论，或者忽视团队技术成员对非技术成员的不理睬和不尊重。
而一个有经验的TL会意识到这个角色领导意义如同技术一样重要。他们会不断地寻找方法在团队中建立信任和良好的关系。一些好的实践，如将团队描述成一个白板架构图，建立编码和架构原则来指导个人决策，或者做定期改进提升以及回顾。
总结
初次做TL通常会容易掉进一些陷阱，这跟他们做开发是养成的习惯有密切关系。为了绕过这些陷阱，他们必须找到有效地方法来平衡技术和领导责任。
在Patrick写的《Talking with Tech Leads》书里可以找到更多关于TL的经验。你可以下载一本免费的样本。
版权声明：自由转载•非商用•非衍生•保持署名 | Creative Commons BY-NC-ND 4.0