工作了6年，可能是由于大学专业的原因，毕业之后选择了技术行业。理发店小妹儿经常问我是什么职业的？我就说我是“写码的”……

大概工作1年之后就开始或多或少开始的带人一起开发工作，大概一个团队里技术最好的，都会被提拔成这个团队的技术 Leader（以下简写TL）。这个好像都已经是圈里的潜规则了……

最近的团队里的一件事情引起了我的注意和思考，TL 的工作到底是做什么？事情是这样的，前几天有人跟我吐槽他的 TL 把活都分给他们，而 TL 自己什么都不干！当然事情已经解决，其中有我的问题，有那个 TL 的问题，还有那个“有人”的问题。这个不是这篇文章要讨论的，就不再废话了。

那么 TL 的工作到底是什么呢？TL 真的什么都没干吗？

首先，TL 需要是这个团队里的一个技术专家（可能团队有N个技术专家），TL 和技术专家对于技术本身的要求同样重要。不同点在于技术专家（或者架构师）相对于团队的其他成员更加独立，可以不跟其他人有很多交集，更多专注技术本身。而 TL 更多的是在人与人之间的关系，并且想法设法让团队所有其他人乐意去追随你。

更加具体一些的展开的来说，很大层度上取决于作为 TL 为团队其他人提供的帮助。帮助更加倾向于是主动的，不是等他人先来找到你的被动方式。这个不光是一个技术专家的聪明头脑和技术能力决定的，更多依赖的是爱心和一颗帮助他人的心。

作为 TL 需要把手头的工作下分出去，对于刚刚升任 TL 的开发同学，我认为这也是你首先要做的工作。如果因为你太忙，而没有时间去帮助其他人的话。那么 TL 就相当于舍近求远，退而求其次，没有去做你应当分内的、且重要的工作。TL 的工作更像是服务行业或者咨询服务，现在重要的已经不再是你自己的技术工作产出，而是你帮助其他人的产出。你帮其他人解决了什么问题，节省了其他人多少的开发时间。

所以现在的问题不再是 TL 的技术能力有多牛逼，而是需要让其他人，整个团队的人都像你一样牛逼。如果不能从这个角度去帮助团队提升，TL 跟技术专家（架构师）又有什么区别？所以从现在开始 TL 需要考虑如何提高整个团队的开发效率和开发质量，TL 写的每一行代码，写的每一个文档都必须是整个团队的参照。帮助其他人解决技术问题，技术选型，以及对未来的思考。

说到写代码，不能只保证 TL 自己写 Clean Code。Code Review 是一个不错的方法，发现并且培训其他人写 Clean Code 。我们目前也在尝试用GitLab 的 Pull Requst 方法来做。公用的业务逻辑封装成一个 function，一组 functions 的集合可以封装成一个类等等。统一代码风格，降低团队间代码的阅读成本。培训大家从团队的角度去思考写可复用的代码，并且组件化，业务解耦等。

TL 的工作是需要耐心，耐心分俩方面：一个是耐心把工作分配出去，确保讲清楚你的诉求，你的预期；然后耐心的对待其他人的工作，可能这一次完成的效果并不能达到你的期望。对其他人的成长过程要耐心，急不得。但是对其他人的要求是要循序渐进的，并能够不断提出更高的期望和要求，让他们有成长提高。培训落实到具体工作粗略分为俩块：

技术分享：在众人面前讲话，分享你的解决问题的经验，还有框架、技术架构、新技术等；

具体问题分析：每个人过来找你解决技术问题都是一个培训的好机会；

TL 对于技术选择也要谨慎，当然我自己也是一个不断追求新技术的人，经常踩坑，但是热情不减。话又说回来该小心还是小心，比如 TL 决定选择使用xx新技术，团队已经完成了基础代码和框架编写，并且在此基础上完成了很多的业务代码的编写。这时候如果再从新选择更新技术，就可能意味着所有代码不是简单的改改就可以了。意味着整个框架和基础代码要重构，并且所有已经完成业务代码也都需要重构。而且整个团队又面临了新的技术，需要从新学习所有的新知识。所以如果想不断尝试新的技术，就需要有不断推翻重来并且随时入坑的觉悟。激情必不可少，我也很喜欢不断折腾自己的人。

更深一点说，要明白是有很多的“因”，才会促成这样一个“果”。如果要不断追求新技术“果”，就需要做很多铺垫。TL 要有大局观，权衡很多因素，比如：

说服领导和团队其他人使用新的技术

让PM和项目经理理解不断重构带来的项目工期变长或者系统不稳定等问题

招聘时，就要选择有激情且志同道合的人

提高开发效率，让团队有余力去做新技术的调研

……

当然每个 TL 都有自己的方式方法，并不是要求一味的求新求变。TL 的核心工作还是培训团队其他人，包括写代码、撰写文档等以提高开发效率。并且在做技术选型时，选择大家都熟悉的框架和技术也是必要的。TL 还要注意，避免在一个项目里使用只有你才能使用的技术，因为 TL 是需要照顾到所有的团队项目工作。如果这个项目只有 TL 能维护，是有问题的。如果说技术专家可以所有技术随便玩的话，那么 TL 应该学会约束住自己，找到最适合团队的技术方案，并且确保能让团队的其他人也一起来用这个方案。

TL 除了要面对团队内部的问题，还有跨部门沟通的工作。包括跟产品、项目经理、运营等的需求，及技术评估，预估项目风险，并把这些信息耐心的说明给那些并不懂技术的产品和运营等人员。这并不容易，需要 TL 的耐心和激情。关于如何处理好跨部门协调工作，个人觉得最重要的 － 彼此信任。之前曾写过一篇程序开发如何处理和PM的关系，第一个方法提到“强势开发，震慑PM”，其实就是让PM从一开始就相信你的技术和能力。

沟通还需要的就是要彼此尊重，虽然你在技术方面是专家。但是产品或者项目经理也是其他方面的专家，每个人都有自己擅长的东西，他们也有强过于你的领域。技术人员普遍情商略低，对待他人的时候，总会显得不屑。如果不改善，继续忽视这个问题难免会影响职业的发展。

表达能力同样重要。很常见的一种情况，本来很简单的一件事情，被一个技术人员说的很复杂。要学会把复杂的事情能用简单的言语表达出来，尤其是面对非技术人员的时候。学会用非技术人员的角度思考问题，并用他们能听懂的语言表达出来 － 这会让你作为 TL 的工作更加有价值。

PS：表达不清，跟自己原本思路混乱有很大关系。练习自己的写作能力会有帮助，写写博客文章或者多写写技术文档，或者尝试把自己写的某个代码功能描述清楚。

沟通是双向的，除了对其他人表达，还要学会“听”，听最核心的内容。经常遇到的问题是，PM 觉得 xx 功能有问题，不好用，希望得到改善。可能 TA 的表达能力也不是很强，没讲到重点，听得你也是一头雾水。这时候一定不要马上给 PM 答复。学会说“我不太清楚”、“我不知道”或者“回去了解下，再给你答复！”。很多时候通过事后去整理，多次的沟通，会发现问题并没有 PM 一开始描述想象的那么复杂。而且你或许能提供给TA更好的方案，而且这个方案对开发来说也相对简单。

而且作为 TL，大家可能都会依赖你，因为你是团队的领导者。有时候团队的其他人找到你请教问题，或许他们真的是醉翁之意不在酒，要留心团队其他每个人的小心思。或许这时候，你该找TA做一次一对一的聊天，看看TA是否有什么想法。

总之，TL 面对的问题大部分还是与“人”有关，而且要清楚的认识到你的行为和言行会影响到其他人。让团队其他人乐于被你领导比帮他们解决技术难题要重要。忽视人与人的问题，且不关注其他人，不去交流和沟通会让你在 TL 的位置上很尴尬。学会用同理心思考问题，并且用自己的情绪去管理他人。