前言

这篇的讲者很nice，直接讲了这篇演讲很适合给这几种人看

1. 刚成为TL
2. 还不是TL但你觉得你会成为TL
3. 已经是TL但想变更好

总之就是给tech leader看的一篇演讲XDD。

演讲总结

这篇顾名思义就是在讲tech leader的一些战略。

就像我说的（绝对不是偷打广告，欧飞），tech leader是个很模糊的词。我们通常定义为此：

项目里技术愿景的拥有者，与项目团队里的技术领导人。

有时候我们会把项目经理（Project manager，PJ）与TL搞混，PJ其实着重的是GTD（Get Things Done）而不考虑技术细节，但TL却要在意这些事情。

但讲来讲去，TL在不同的公司与地方还是有着不同的意思，与不同的工作。所以如果是这样，岂不是没有一套规则要怎麽当TL呢？其实也没那麽悲观，因为大家的共同目标都是一样：「与团队一起创造好的软件」。根据这样的目标，我们可以简单讨论TL的几个重要的工作：

一、协调（facilitate）

也就是帮team完成应该做的事情。身为TL，你永远要想着「下一步」。

帮助团队移除路障（roadblock）是最最基本的。但是你更该练习的是，先预测未来的路障并且先消除它。後面这件事更重要是因为

• 可以让团队成员感受到inclusion。
• 可以减少未来处理事情的不确定性。
• 可以练习你的前瞻性。
• 可以练习你的同理心。

而要成为好的facilitator，你要把计画事情，并把事情切小切细，所以你就可以更好评估什麽时候会发生什麽事。

这里讲者讲到，虽然大家都很不喜欢工作时打断，但身为TL，你的工作就是要被打断，因为团队随时会需要你的帮忙。当然你未必要知道所有的事情，但你必须要知道「要如何找到答案」。

二、主张（advocate）

（其实我没有很懂这词的精华）身为TL，你必须要知道哪些是重要哪些是不重要，所以你不能全然接受别人叫你做的事情。你要练习跟其他人说No，并且给出好的理由为什麽是No。有时候别人不理解context，那你要跟他们解释背景；有时候是别人没看到某些事，所以你要先想到可能会造成的问题。

而要成为好的advocater，你要把事情写下来，留存的纪录便可以确认大家理解相同，也避免其他人未来偷偷改变心意。

这里有讲到工程师是个很喜欢做对的事情的生物，而大家常常犯的一个错是过度工程（over-engineering）。

大家喜欢写可重用的code，但没人喜欢重用别人写的code。

身为TL你必须要有sense每个项目的scope在哪里，然後让大家聚焦投资时间在重要的事情上面。

三、驱使（motivate）

虽然很不想承认，不过TL无论如何都是一种管理。而既然是管理，最重要的关键就是leader的态度。如果你每天各种抱怨，对各种事情都很悲观，新不在team上，那大家也会备受影响。

而当你身为TL想要大家做事情时，你会需要的能力就是让大家有动机做你想要他们做的事情。关於动机，大多时候我们会想到的都是用外部的方式给於他人动机，例如给更多钱、请客、更多福利等等，但研究指出这些外部动机通常不够强烈也无法持久，更重要的是想办法让他们发自内心去感受到被感召，这也是最难的部份。

讲者说有一个技巧叫 passive-aggressive white-boarding（sorry我完全不知道该怎麽翻译这个= =），意思就是说，当你难以说服一个人走错路的时候，尝试问他多点细节，叫他把他想像的过程在白板上写出来，那他自然而然就会发现问题所在。而这种由内而外的觉醒，也是更强烈的动机。

四、风险管理（mitigate risks）

最後一点是关於Tech leader的悖论：虽然code都不是你写的，但是你却要为这些系统所负责。

所以在这里risk management变得非常重要，你必须要有能力去看到project中容易被忽略的那10%，然後尝试去降低风险。而在降低风险中你要做的其实很简单：

• 去理解那些你最不熟悉、最害怕的事物。
• 然後尝试去找出处理这些事情的答案。

个人心得

虽然这场是讲TL，但与之前的文章重复性好像没这麽高，有几个我觉得蛮有感触的点，这里来讲讲：

关於见闻色霸气（误）

在facilitate的部份讲到了，在别人遇到问题前先把问题解决，这个能力我觉得其实是大家应该都要培养，而非TL要有的，或者说更多应该是在成为mentor之前应该就要开始练习的能力。因为先想好未来要走的一步或一百步，本来就是工程师的职责，毕竟我们写code要写的好，或架构设计好，就是在预测未来的行为。

先思考路障对自己做事的帮助，有更多是你可以平行的处理事情，就有点像是coroutine，你知道对於「与别人沟通的操作」可能不会很快速的得到回覆，或者需要比较久的时间讨论，那你就应该早点开始，不然sequantial的处理到最後就会变成瓶颈都在等待时间上。

移除路障的两难

不过这里有个两难是，我们是否真的应该移除路障？还是应该让团队成员碰壁，自己去练习移除路障？关於这点我自己的答案是，要回到delegation的初衷：「delegation的目的，是为了利用下放任务而让他人达到学习的方法」。所以路障是他未来所需要的技能，我可能就会让他自己去撞壁XD。但如果只是one time effort，或者他早已习得这项技能，那我可能就自己偷偷做掉。

举个小例子来说如果做task的时候要apply server的permission，这种路障对於新人就可以让他们自己去碰碰看，但如果是老人(?)要开server，我可能就直接帮他们弄了，也可以省点时间。

不过这里有个重点是，「偷偷做掉的事情」也要跟他们讲，以防成功者偏误（success bias）产生。