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

近日，一名有超過15年軟件開發經驗的軟件開發人員在Hacker News上提出了一個問題：如何才能成爲一個好的技術領導者？

該問題一經提出，不到一天的時間得到了160多條回覆。關於技術領導者應該具有的品質和管理技巧，網友們提出了各自的見解和建議，本文擇要概括以下。

遷移到：http://www.bdata-cap.com/newsinfo/1741376.html

若是不能從幫助團隊得到知足感，那麼就不要成爲一名領導者

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

技術領導者的工做再也不是讓本身成爲最好的編碼人員，而是要儘量地讓其餘人成爲最好的編碼人員。

工做分配也要以一種有利於團隊和我的成長的方式進行。

要負責爲團隊成員清楚障礙，讓他們的工做進入正軌。

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

將本身視爲其餘開發人員的導師

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

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

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

有時候，技術領導者仍是架構師。當解釋系統或代碼的行爲時，他須要可以快速改變高度。當同開發人員調試問題時，他要可以深刻技術細節；而當向CEO解釋計劃或成本估算時，他要可以在一個更高的層次上談論系統。

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

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

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

爲了瞭解團隊成員，技術領導者要按期主動同團隊成員進行一對一的溝通。每名開發人員都是不一樣的，經過溝通能夠了解到這種不一樣。

減小具體的編碼工做，但仍然要編碼

即便不作不少具體的編碼工做，也仍然須要監控和接受全部的pull request，並利用這個過程，幫助初級開發者修改代碼。這是必須的，若是不編碼，那麼開發人員會質疑你的判斷，不容易接受你的建議。

可是，做爲技術領導者，你的首要任務是確保團隊成員的生產力，而不是本身的生產力。你要爲整個團隊的輸出負責，若是那意味着零編碼，那麼就不要編碼了。同時，這也意味着，即便代價是停下本身的工做，也要幫助處於困境中的團隊成員。

要謙遜

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

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

若是團隊成員都將你視爲權威，那麼他們會懼怕本身作決策。在這種狀況下，你就成了障礙。

要誠實

當你知道答案的時候，就說出來，即便那意味着某些人要重作大量的工做。若是你不知道答案，也要說出來，不能不懂裝懂。你得到了當前的職位，就說明你有資格，你永遠不須要向其餘人證實你的能力。

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

此外，網友們還提供了許多可供參考的資料，好比，《人月神話》、《人件》、《程序員修煉之道》、《成爲技術領導者:掌握全面解決問題的方法》（Becoming a Technical Leader: An Organic Problem-Solving Approach）等。