如何才能成為一個好的技術領導者？

　　近日，一名有超過15年軟體開發經驗的軟體開發人員在Hacker News上提出了一個問題：如何才能成為一個好的技術領導者？該問題一經提出，在不到一天的時間內就獲得了160多條回覆。關於技術領導者應該具備的品質和管理技巧，網友們提出了各自的看法和建議，本文擇要歸納如下。

　　如果不能從幫助團隊獲得滿足感，那麼就不要成為一名領導者

　　技術領導者要忙於會議、計劃、打斷、團隊溝通、文件等工作，永遠無法達到一個人單獨工作時所能達到的那種個體生產力。

　　技術領導者的工作不再是讓自己成為最好的編碼人員，而是要儘可能地讓其他人成為最好的編碼人員。工作分配也要以一種有利於團隊和個人成長的方式進行。要負責為團隊成員清楚障礙，讓他們的工作進入正軌。

　　技術領導者的滿足感來自新人的培養和成長。

　　將自己視為其他開發人員的導師

　　即使已經知道了答案，有時候也需要讓團隊自行決策。許多時候，正確的答案並不唯一。技術領導者的工作不是選擇正確的答案，而是確保團隊不選擇錯誤的答案。允許團隊作為一個整體自行決策有利於保持高漲的士氣，讓每名成員都更有自豪感和主人翁精神。

　　在有關技術問題上，團隊信任並依賴你的建議/觀點。作為技術領導者要了解團隊所開發的應用，瞭解該應用所涉及的領域，瞭解功能背後的技術，並編寫詳細的技術文件。

　　有時候，技術領導者同時也是首席工程師。這時，他所能為團隊做的最有價值的事情是在開始和結束時為團隊成員提供幫助。

　　有時候，技術領導者還是架構師。當解釋系統或程式碼的行為時，他需要能夠快速改變高度。當同開發人員除錯問題時，他要能夠深入技術細節；而當向CEO解釋計劃或成本估算時，他要能夠在一個更高的層次上談論系統。

　　隨時準備好回答團隊成員的問題

　　但當你有問題要問他們時要首先詢問他們是否方便。這很難做到，因為作為一名技術領導者，你有許多工作要做。但是，為了可以有更多的時間回答他人的問題及為其他人提供支援，可以將複雜的任務委派給團隊中更有經驗的成員。

　　很多時候，團隊成員的問題本可以在空閒或閒聊的時候提出。為此，引入可非同步使用的生產力工具是一種更好的方式，比如，對於一些不太緊急的問題，可以藉助Trello卡片或GitHub問題跟蹤器提出。不過，不管採用什麼樣的溝通機制，關鍵是要獲得其他團隊成員的支援，讓他們在工作無法進行或完成的時候，可以很舒服地打斷你。

　　為了瞭解團隊成員，技術領導者要定期主動同團隊成員進行一對一的溝通。每名開發人員都是不同的，通過溝通可以瞭解到這種不同。

　　減少具體的編碼工作，但仍然要編碼

　　即使不做很多具體的編碼工作，也仍然需要監控和接受所有的pull request，並利用這個過程，幫助初級開發者修改程式碼。這是必須的，如果不編碼，那麼開發人員會質疑你的判斷，不容易接受你的建議。

　　但是，作為技術領導者，你的首要任務是確保團隊成員的生產力，而不是自己的生產力。你要為整個團隊的輸出負責，如果那意味著零編碼，那麼就不要編碼了。同時，這也意味著，即使代價是停下自己的工作，也要幫助處於困境中的團隊成員。

　　要謙遜

　　要相信，你的團隊所具備的能力和理解力都要超過你。

　　要承認，關於某個主題或元件，有人懂得比你多。成為一名優秀的領導者，並不需要事事都懂得比別人多。

　　如果團隊成員都將你視為權威，那麼他們會害怕自己做決策。在這種情況下，你就成了障礙。

　　要誠實

　　當你知道答案的時候，就說出來，即使那意味著某些人要重做大量的工作。如果你不知道答案，也要說出來，不能不懂裝懂。你獲得了當前的職位，就說明你有資格，你永遠不需要向其他人證明你的能力。

　　除了上述這些討論比較多的觀點外，還有一些其它的觀點，比如，把令人愉快的任務分給別人，把令人討厭的任務留給自己；公開表揚，私底下批評；讓每個團隊成員都清楚地知道你對他們的期望；及時反饋和表揚；與非技術管理人員建立穩固的關係等等。還有一些行為是技術領導者應該避免的，比如，不要抱怨程式碼庫有多糟糕；不要說“我們要重寫XYZ”，技術債務要逐步解決；不要輕易提議使用可選的平臺和框架。不過，需要注意的是，不同的組織有不同的企業文化，對技術和技術領導者有不同的看法和預期，技術領導者要以此為出發點考慮問題。

　　此外，網友們還提供了許多可供參考的資料，比如，《人月神話》、《人件》、《程式設計師修煉之道》、《技術領導之路》等。這裡就不一一列舉了，感興趣的讀者可以進一步閱讀。