前言

這篇的講者很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）產生。