前言

筆者從15年5月開始從帶3人小團隊到目前10人左右規模，從一線研發工程師到Team Leader（下文簡寫為TL）身份轉換的過程中，曾經有過很多迷茫與困惑，完成轉換之後總結一些心得寫到這篇文章中。

降低編碼的時間

多數技術團隊的Leader都是從表現優秀的一線工程師中提拔上來的，這個現象在其他行業也普遍存在。而作為工程師本能的希望自己每天繼續寫程式碼，沉浸在自己的程式碼世界中，努力提高技術水平

針對問題上，筆者的建議是，最大程度的降低自己的編碼時間。

為什麼？

首先需要想清楚TL該做的事情，總結起來有以下兩點：

• 對團隊的產出結果負責
• 對團隊成員的成長負責

如果TL每天花大量的時間投入到編碼中，那麼最終帶來損失的是整個團隊。

首先，團隊的成員會在TL高超的技術水平的光環下，極度緩慢的成長，因為如果大量的需求開發工作被TL搞定了，團隊成員就很難有機會得到鍛鍊。

第二，團隊中的真正只有TL能解決的問題被擱置，比如團隊成員間配合時的摩擦。比如同兄弟團隊配合過程中流程上的問題等等。這些問題一旦被擱置，對團隊自身的傷害非常大。

TL要時刻牢記自己如何發揮最大的價值，給團隊帶來產出，跳出自己原有的“熟悉域”，站在更高的角度去思考。

分配多少時間去處理程式碼？

首先一定不要走極端：那好吧，我不寫程式碼了，讓團隊內其他同學去寫吧，我就處理其他事情，程式碼寫成啥樣也不關心了。

筆者建議分配時間的30%來“處理”程式碼，“處理”的含義在於，可以是直接寫程式碼，或者是Review其他人寫的程式碼。

前面提到TL的職責，你需要為結果負責，對成員的成長負責，因此花時間去Review程式碼，給其他成員一些指導和建議是很有必要的。在這個過程中也可以發現工程內潛在的問題，並且作為TL推進解決。

花時間做一對一溝通

作為TL很重要的一點在於為團隊內的其他成員服務，瞭解他們的訴求，分析他們階段性的問題，並幫助他們去解決。

週期性的一對一溝通是非常有必要的，也是作為TL一定需要花大量時間去做的。

很多工程師的性格都很內向，但一定要邁出這一步，經常性的聊聊天，將你看到成員自身的問題及時反饋出來，並且給出指導建議，對於團隊成員的成長是非常有利的。

如何做一對一溝通？

首先溝通的訣竅只有兩個字：真誠。

• 從團隊成員成長角度出發，能夠達成共鳴，並得到很好的溝通效果
• 及時直接的指出成員的問題，並幫助他改進

不要讓自己成為決策的瓶頸

很多TL自身不參與程式碼開發但非常喜歡拍板，無論大小都要經有TL決策。

從效率角度出發，如果TL成為決策的瓶頸，TL自身的效率將會大大降低，每天需要處理無數的事情，大腦基本要爆炸了，團隊推進事情的效率也將降低，因為任何事情都要等待TL來決策。

從團隊成員角度出發，不做決策意味著可以不對決策產生的結果負責，長期下來也就不需要針對事情做過多的思考了，思考少了成長自然也就少了。與此同時他們更多的工作就是一個執行者，對事情沒有決策權，每天的成就感也會大幅降低。

該如何做

• 培養能夠作出準確決策的人，給團隊成員更大的空間來發揮自己的才能。
• 參與決策討論，決策過程中拋開TL的身份，給出必要的建議，但不要身份壓制。
• 對待決策的事情進行劃分，能夠下方權利決策的事情明確負責人，負責人對結果負責。

傳達價值觀，以身作則

一個團隊的價值觀決定了這個團隊的行為方式，以及戰鬥力。

因此從一開始TL就要思考我希望的團隊文化是什麼樣的，團隊成員的價值觀應該是什麼樣的，並且在工作的過程中去傳達。

比如希望打造學習型的團隊，希望團隊中每個成員除了開發以外，能夠有提高，那麼TL就需要去思考一些能做的事情，傳達這個想法。

TL的行為方式也會潛移默化的影響到團隊中的其他成員。如果口號喊一套，實際做事是另一套，那麼事情推進起來就不會很順利。所以一定要以身作則，為團隊成員梳理標杆，讓大家明白TL是這樣做的，那我也應該這樣做。

總結

Team Leader是一個很關鍵的崗位，在這個崗位上也需要非常多的思考。 簡單的做了幾條總結，希望能夠幫助新人TL，文中的很多觀點也是基於現有的認識和經驗做的總結，歡迎留言。