To Be An Excellent Tech Lead

back

在成为 Tech Lead 之前已经见过很多优秀的 Tech Lead，也对自己有过一些想象，诸如能不能胜任，怎么去面对客户，怎么协调处理各种各样的问题。

随着时间的推移和见闻的增长，逐渐形成了自己对优秀 Tech Lead 的认知，趁着还有热情赶紧写下此文，免得日后失了方向。

何为 Tech Lead

既然是优秀的 Tech Lead(下文简称TL)，有必要先搞清楚它到底是怎样的一个角色。

需要说明的是 TL 作为一个团队内不可或缺的角色，在 Thoughtworks 这个特定的上下文下，其职责与外界稍有不同。

如果将一个项目比作一场战争，TL 不是那个在千里之外挥斥方遒制定战略的人，他更像是战场前线的突击小队队长。

具有过硬的“射击技术”只是基础要求，他还要能够在小队损耗最小的情况下制定战术攻破敌人的据点。他是最了解队员的人，能让合适的人去做合适的事，也知道如何将一名队员培养成某个方向的“特种兵”。而更强的 TL 甚至能化敌为友，“打入敌人内部”。

虽然比喻不太恰当，但想表达的意思很简单，TL 不是 Manager，他不应该是一个管理者，他更应该是一个带头人/协调者/培养者，以及背锅侠。

团队为何需要 Tech Lead

对外，TL 是团队最直观的技术能力窗口，TL 的能力很大程度上决定了客户的第一印象，决定了客户怎么看待整个团队。

对内，虽然 TW 一直在倡导自组织团队，希望一个团队里的每一个人能够明白各种各样的实践和背后的意义，什么时候应该做什么样的事情。

但事实是每个成员所站的角度不同，能力不同导致并不是每一个人都能发挥自己的能力或处于一个高效的状态，这时候需要有一个人戴上 TL 的帽子从中协调和引导，发挥团队的最大效能。

而对于团队中的每一个人来说，一个优秀的 TL 懂得如何放权，这个过程是成员成长的好时机，大多数小伙伴们从单纯写代码这件事开始成长往往都是从 TL 放权开始的。

优秀 Tech Lead 的特质

在我的认知里，成为一名优秀的 TL 是一件非常困难的事情，他需要具备许许多多优秀的特质，这些特质共同组成了一个？

首先既然是团队的带头人，至少你需要让团队信服，否则团队很难打心底里认同你。使用职权影响力显然不是一个好的方式，程序员有程序员的规则。

程序员的世界像是一个“江湖”，这里的规则很简单，你比我强，我就服你。这里的强可以是多方面的，不仅仅局限在技术这个范畴，核心原则是让大家觉得你这个人是靠谱的。

比如有的团队里面已经有某个领域的专家存在，这个领域 TL 的技术可能不如这位同事，但 TL 如果有能力能够为其排除干扰，给予他足够的空间发挥自己的能力，那至少跟这个 TL 做项目会很开心。

也有的 TL 本身在某个领域就有很强的能力，不管是对外展现团队的技术能力，还是对内解决疑难杂症都得心应手，这样的 TL 当然也会得到团队的信赖。

程序员世界里另一个原则是：

Shut up and show me your code.

无论如何，请尽量不要脱离写代码，脱离了写代码跟脱离了前线是没有区别的，而这又恰恰是一个展现你能力的窗口，说得再好，干不了就是干不了。

协调与沟通

据我观察这是大多数同学不愿意做 TL 的直接原因。

一位 TL 对外需要和客户讨论技术方案，在需要的时候为业务方提供技术输入，在客户和团队中间找到那个微弱的平衡点，让客户认可团队又不至于让团队过载。

对内需要和非 Tech 的同学紧密沟通，及时给予技术输入帮助他们整理 backlog 和调整优先级，根据情况协调资源化解交付中的 blocker。

同时你还需要站在全局的角度及时识别和管理交付中的风险，项目的 CFR 管理是不是有什么问题，我们是否实现了客户的目标，项目是不是不稳定，后续的 staffing 应该怎么做等等等等。

令人烦躁的是上面的这一堆事情我只列举了部分，而这些被大家称为“杂事”的东西将占据 TL 大量的工作时间。更可怕的是这些事情的大多数将以会议的形式出现，在会议中面对一张张面庞，去解决一个个问题。

这已经完全违背了那个当初我们在大学时代定下的写代码的初衷：

我不擅长与人打交道，但我写代码挺快乐的，所以我选择做程序员。

这些事情是大多数程序员不愿意做的，但又恰恰是一个 TL 需要做好的部分，这些事情做的好与坏决定了团队的运转是否流畅，大家的工作环境怎样。

所以首先你需要做的是先平衡好自己的心理预期，你的工作重心将会有一个大的偏移。其次你需要用自己的方式管理好你的时间表和 backlog，什么时候需要做什么事情，它们的优先级是怎样的。

处理客户关系

这是另一个让人头大且值得单独从协调与沟通中单独拎出来聊的一件事。

Thoughtworks 内部有一个专门的角色叫做 Engagement Lead，不过与其说这是一个角色不如说它是一顶帽子，规模不大的项目通常是 TL/BA 来戴这顶帽子，大规模的复杂项目通常会由各个拆分后的小组中的 TL/BA/PM 来戴这顶帽子并最终组成这个项目的 Client Leadership Team(CLT)。

这个角色有一个重要的职责是从业务、技术、组织愿景等方面理解客户，然后将 Thoughtworks 独有的价值代入其中帮助客户获得成功并成为客户的深度合作伙伴。

一句很短的话，但想要做到却困难重重。相信很多 TL 都遇到过这样的情况：

我们坚持好的代码实践和敏捷实践以求更好的交付质量，但是这些东西在客户眼里一文不值甚至是浪费时间，而在我们的视角里他们油盐不进，一心只有按时交付，其他的都不重要。

问题或许出在我们是不是不知道客户向上承诺了什么导致他们不愿意承担这个“风险”，也可能因为客户压根还不信任我们，更不会接受我们的策略，他们更想待在自己的舒适区内按照他们的游戏规则来玩。

这里面的问题相当复杂，没办法一概而论，但或许这里有一些建议你可以试试看：

• 站在客户的角度考虑问题，然后解释为什么我们的实践可以帮助实现这个目标，我们并没有背道而驰
• 先顺着客户的想法走，交付一部分价值取得客户信任后再提出我们的构想，阻力或许会变小
• 最重要的，这些讨论你最好有实际数据支撑你自己的论点，数据的说服力是强大的

留点时间给自己

TL 通常会花大量的时间在当下，解决各种各样的问题。但请记得留下时间给自己，有一个对 TL 的期望是 Think Big, Think beyond，如果将所有的时间花费在当下，我们很有可能丢掉 TW 的一大特质：

We are not just get things done, we think much more.

我见过很多给自己留时间的方式，有的 TL 会在每一天早上很早的时候来办公室；有的 TL 则是在下班后留出一些时间来思考；还有的直接在自己的 calendar 上 block 一段固定的时间来做自己的事情。

我们常说的技术债管理，优先级调整，全局性思考，CFR 追踪等等都不是凭空出现的，你需要一点点时间，跳出当下，仔细看看这趟火车是不是还好好的行驶在自己的轨道上。

你也需要一些时间来熟悉熟悉代码库，做一些简单的任务，看看大家写的代码是不是还在我们之前设计好的模式下，你自己的想法和能力是不是还像以前一样令你充满自信。

别跑太快，停下来仔细想想，你需要一些休整。

人才金字塔

“做 TL 太累了，所有事情都怼到我这里，感觉我都快忙死了，根本没时间做别的！”

地球少了你照样转，你不是超级英雄，请相信你的团队，合理放权。

先问自己几个问题：

• 你能在30秒内划分出你团队的能力金字塔吗，谁的能力较强，谁的能力稍弱？
• 你清楚大家擅长什么吗，出现问题能立马想到团队里的谁可以做这件事？
• 你清楚团队里的小伙伴想要做什么事情，你可以提供什么样的帮助吗？

可能做一件事的能力要求是 70 分，有的小伙伴只有 60 分的能力，由于你不愿意接受这个风险，选择自己完成这件事。但明明这对于这位小伙伴来说是很好的锻炼机会，你只要给予他支持就能补足这 10 分的差距。

或许你觉得自己做事效率更高，但是换个方面思考你是不是低估了大家的成长能力呢？我身边已经有无数趁着适当的机会快速成长的故事，几个月后，他们也可以成长为独当一面的人。

如果你常常抱怨事情太多，不如想想这件事是不是非你不可，还是那句话，你不是超级英雄，请相信你的团队，就像你的团队相信你的那样。

你需要学会接纳风险，同时帮助团队成长，你完全可以采取 trust but check 的策略，在关键时间点检查任务的情况，使进度时刻在你的可控范围内，他们的变化可能会超出你的想象。

最后你需要把握甩锅和放权的区别，别忘了你应该是那个背锅侠。

你觉得这是全部了吗？可能是，也可能不是，受限于自己的眼界，我对这个角色的理解只能到这个程度了。

其实这里面的每一个点单拎出来都能作为一篇文章去详细分析，公司里的各位同事也已经有许多优秀的分享，非常建议大家看看不同的视角，说不定你也会有自己的理解。

在此感谢我工作中遇到的每一位 TL ～