一些关于Tech Lead的畅想

Tech Lead是个能够自解释的词，Tech Lead = Tech + Lead就是说既要懂技术又要会领导，字面含义就是这么简单。不过光这么说还不行，还得把它的适用场景圈一下，TL就是团队中既要懂技术又要会领导的人。这个说法清楚吗？我觉得还不行，因为关于懂技术和会领导这两件事显然不会有0或1的二元解答，到底懂什么样的技术与会怎么样的领导才能被称之为Tech Lead的呢？

TL的职责

这里先分享一张来自"Tech Lead-Circles of responsibility"文章的图，透过它我们能很清楚地了解到Tech Lead是怎样的一个角色以及肩负的责任与所需的技能。

开发

TL不单单是写写代码，而是“有追求”地写代码，同时还要外延到研发的其他方面。普通开发通常一个人埋头苦干而TL则需要具有开发的“器、术、道”的十八般武艺，就像上图Developer圈中展示的那样，如OO、重构、设计模式等。通常每个领域都会有固定的技能要求，在这之上TL还得有追求，包括对优雅开发代码的追求、对易用开发工具的追求、对高效开发方法的追求以及对正确开发思想的追求，追求就意味TL掌握的开发技能是动态发展的，探索将是TL的长期课题。

十八般武艺

如果只是这些，TL和高级或资深的开发看上去没有差别，真正产生不同的是，TL能推动团队发生变化，比如推广技术、分享知识等，而不只是一人独领风骚。有分析师曾经研究过3千个以上的项目中团队的表现，最好团队与最差团队之间的表现差别是1：2000，这里存在着巨大的提升空间，所以如果让能TL帮助团队发生变化效果将十分惊人。

架构

Tech Lead不是System Architect，但TL是守护架构的关键角色。架构这个概念很大也很立体，在代码、组件、系统每个层面上虽表现形式不一样却相互联系，实现的代码只是架构的一部分，TL对于架构的职责也需要立体地展开。要做到这点首先要理解架构，需要掌握业务架构与代码架构的相互映射，能够分析业务对架构的影响并识别业务对架构的挑战，最终能够处理和应对挑战，保证架构的健康。

除了防止架构腐化，TL还有责任让架构变得更好，这就要求TL去接触更多的架构，沿着业务演进的方向尝试去思考架构的演进之路，比方说现有的单块架构是否需要向微服务架构演进以及如何规划与实施这种演进。

领导力

作为团队技术最全面的人（即使团队内有更精通细分方向的领域专家），TL必须是主要技术方向的决策者，这种技术话语权不是别人赋予的而是需要获得团队每个人的对他技术能力的认可，这通常是TL在团队协作中逐步建立起来的，比方说解决难题故障、完成挑战任务，推广实用技术、分享专业知识等。技术话语权是TL领导力的源泉，但TL又不能唯技术论（那样容易陷入技术式的孤芳自赏）而应该关注到团队的人以及团队的文化，或者更直接地说TL也要能管理团队。

情景领导

这种关注和管理不是简单地找人聊聊天谈谈话问几个问题，而是以一种“对结果负责”的态度去理解产品需求，理解团队之间的关系，平衡技术优雅与人力以及时间进度，它会随着TL的技术活动展开，比如对于团队技术能力弱的新员工，TL就要能拆解任务以及指导他们完成攻关；对于技术水准高的资深开发，TL就要能授权和支持同时保持开放的心态并做关键决断。除此之外TL还要善于解决冲突，冲突可能来自团队成员之间的也可能来自成员与团队外的，这就要求TL兼有系统思维能够跳出自已团队的圈子去看问题。没有这些能力，TL充其量就是一个领域技术专家而已，因此技术领先只不过是TL的“根骨”，领导力才是TL真正的修炼。