前言
個人從程式設計師到技術 Leader 經歷了不少的心路歷程，我目前在帶一支十幾人的技術團隊（控制團隊人數主要是遵循亞馬孫 CEO 貝索斯提出的兩個披薩原則）我記得剛開始帶團隊的時候我是非常抗拒的，因為總覺得管理太多的“雜事”佔用了我很多寫程式碼的時間，包括目前雖然已經是一支十幾人技術團隊的 Leader，但是我平時也還是偏愛技術多一些，在業餘時間都會抽空寫寫程式碼或者在 Leetcode 刷刷題，在從事管理工作這些時間裡看過很多書，也踩過很多坑，總結了很多經驗，想必也有很多程式設計師剛開始跌跌撞撞的走上技術 Leader 的崗位，所以想寫一篇文章跟大家分享一下，希望可以幫助到需要的人，文章大綱如下：
- 技術管理者需要哪些綜合能力？ 如何才能在團隊擁有 Leadership ？
- 從工程師到團隊 Leader 有哪些轉變 ？
- 如何提升技術團隊的工作效能 ？
- 如何提升團隊的凝聚力 ？
- 溝通的技巧 ？
- 管理者的自我認知和成長
技術管理者需要哪些綜合能力？ 如何才能在團隊擁有 Leadership ？
既然說到管理技術團隊，那麼管理的物件自然就是程式設計師，那麼程式設計師是一個什麼樣的群體？大多數程式設計師的特點是：“聰明且傲嬌”
比如這個網上流傳的段子，如何正確的向程式設計師提BUG：
技術 Leader 對個人綜合素質要求很高（技術好的管理者，帶技術團隊是有一定優勢的），先說說我認為技術 Leader 需要哪幾個比較重要的綜合能力
- 技術能力和基礎知識（能看懂技術表象背後的原理）
- 溝通表達能力（邏輯，同理心，情緒控制）
- 業務抽象能力（架構和演化）
技術 Leader 必須要看透技術的本質，因為技術 Leader 平時的工作內容大多包含：技術選型，技術方案評審，程式碼審查，技術氛圍的營造，如果管理者本身不是技術出身，可能無法和技術團隊建立共識，溝通成本極高，最終讓團隊變成一個非常低效的組織，人浮於事，那麼如何才能擁有這些能力，可以在技術團隊擁有 LeaderShip ? 我個人總結有一下幾點：
- 吃透基礎技術和弄懂技術背後的原理（萬丈高樓平地起，再流行的框架和技術，剝離華麗的外衣也離不開作業系統，網路，資料結構這些原理型的知識）
- 瞭解細節，永遠在寫程式碼（不熟悉程式碼就無法提出真正可落地的方案，就無法感知技術團隊的痛點在哪裡，也就無法團隊提高效能）
- 持續的學習，持續的為團隊帶來新的知識和理解（技術 Leader 已經是團隊技術問題的終結者，不可能再上傳遞了，所以不要成為技術團隊的天花板）
- 有一個真心幫助大家的心態（幫助大家成長，提高效能，最終組織效能也得到提高，實現共贏的局面）
總結了以上經驗和方法論之後，我們肯定會思考，上面所說的都只是過程和執行，那麼管理者的目標或者說是工作的結果是以什麼形式體現的？
總體概括來說的話，管理者的目標和工作結果主要體現在兩方面：
- 做事：成本、效率、質量
- 帶人：人才、梯隊、成長
以上的方向又太抽象，其實管理者很多時間的大部分工作都在選擇和許可權，主要包含以下幾個方面
- 有限資源的限定下，選擇最大化的產出方案
- 做出符合當前環境的技術決策，幫助公司產品取得成功
- 用方法和工具不斷優化和提升生產效率和質量
舉一個實際的例子：
- 比如公司A在創業期，還沒有穩定的市場和客戶，這個時候技術管理者的決策要傾向成本 + 效率，例如：技術團隊偏向全棧型，工作流偏敏捷，快速交付功能獲取使用者和市場的反饋用於升級和迭代產品
- 比如公司B在成熟期，有固定的市場和客戶，行業已經沒有新的蛋糕，這個時候需要比拼的就是效率 + 質量，技術團隊偏向專家型，注重產品質量和客戶體驗用於形成行業口碑和使用者粘性
從工程師到團隊 Leader 有哪些轉變 ？
其實工作變化還蠻大，所有很多人剛開始管理團隊會出現很多的不適，我總結如下：
我們先看看工程師的工作視角：
- 這個功能怎麼做 ？
- 這個需求寫完，我今天的工作就完成了
- 業餘時間只看技術相關的內容
- 看看今天領導分配了什麼工作給我
作為技術 Leader 的工作視角：
- 我們先階段要做什麼 ？
- 團隊未來向哪裡發展？ 團隊成長不如預期怎麼辦？ 公司今年的業績指標如何可以完成 ？
- 除了技術，還需要溝通，判斷，組織，協調，看方向的能力
- 規劃 Q1 季度的工作目標，分解到團隊成員去實施，保證工作內容和每個團隊成員的能力相匹配
看到這裡大家可能會感慨到，不同於工程師工作內容的“明確性”，管理者的大部分工作是“不確定性”的，而且幾乎沒有盡頭，也沒有一個明確的時間用於標示“完成”狀態，所以這對於習慣“確定性”思維的工程師來說，挑戰極大
我個人用通俗的比喻來總結就是，我以前寫程式碼時候的感受是 一人吃飽全家不餓，輕鬆且自由， 現在感受是 既當爹（做事），又當媽（帶人），而且還上有老（上級），下有小（團隊），感覺亞歷山大！！
如何提升團隊的工作效能
很多人都在談高效，但是軟體行業的高效度量指標是很難的，總體來說工作效能的提升，實際上是 事 + 人 的結合，我們先聊聊事情，再聊聊人
從事情的角度，我們先說說讓團隊開發工作變的高效的幾個條件：
- 給員工配置高效能的電腦（工欲善其事必先利其器，脫離工具談高效就是在耍流氓）
- 工作流是否流暢（Git 伺服器網路慢，合併程式碼要寫表格走流程申請？形式主義就不要談高效二字）
- 自動化工具是否完善（沒有自動掃面，自動測試，程式碼就被合併了？那麼接下來就是無盡的生產 Bug，修復的死迴圈）
以上側重的是工具和流程，開發的效率和開發的體驗對團隊的效能都至關重要，流暢的工作流可以讓開發者持續進入心流狀態，產生高質量的功能和程式碼，不會頻繁的被電腦卡死，頻繁的打斷，開發流程等待的阻塞降低工作的積極性，下面我們從人的方面聊聊如何提高團隊效能
程式設計師的工作大多是本質知識工作者，管理學大師彼得德魯克說過：“對於知識工作者是無法進行嚴密的督導”，所以我傾向提供一種積極，主動，自驅的工作氛圍給團隊，讓團隊在這種土壤裡面逐漸的形成高效能團隊
每個團隊都會有懈怠的員工，有時候管理者不要急於否定員工，看看管理者是不是沒有洞察到他的心理訴求，高產出員工的兩個特質是：
- 能力（專業知識，技術能力）
- 意願（團隊文化，價值觀，喜歡的氛圍）
有一種情況我們常常會發現相同的員工在不同的環境，有不同的產出，所以有時候發現懈怠的員工，不僅要從員工身上找問題，還可以去思考看看是不是我們周圍的人，事，環境，工作方法，價值觀等地方找出問題，畢竟有一句話叫做“橘生淮南則為橘，生於淮北則為枳”
外部激勵
除了團隊和個人，還可以從外部找原因來持續的激勵團隊，可以理解為是外部激勵，主要包含以下方面：
- 安全感和成就感（穩定的工作環境，完成有難度的挑戰，及時反饋 BIA）
- 學習和成長環境（和優秀的人共事，感知到自己成長）
- 和管理者定期溝通（讓員工感到自己被重視，收集員工建議並且做出工作上的調整）
自驅力和凝聚力
很多企業都期望員工可以有 Onwer 精神，但是如果想要團隊保持足夠的自驅力，管理者可能要思考是否對團隊做到以下幾點：
- 給予員工自主性（工作內容上的自由度，工作方法上的自由度，工作時間和地點上的自由度）
- 成長（明確的工作目標，內容有挑戰，工作發揮其優勢）
- 意義和使命（共同的目標和願景，價值觀）
- 信任和放權（共同面對挑戰，團隊內的對抗活動）
溝通的技巧
為了簡單先說明溝通的重要性，我們先了解一下關於聖經中《通天塔》的故事，故事大概如下：
《聖經·舊約·創世記》第11章故事中人們建造的塔。根據篇章記載，當時人類聯合起來興建希望能通往天堂的高塔；為了阻止人類的計劃，上帝讓人類說不同的語言，使人類相互之間不能溝通，因為不能溝通無法達成共識，人類之間相互猜忌，內鬥，無法團結，最終計劃因此失敗，人類自此各散東西。
總結一下就是，如果人們不願意，或者不會溝通，那麼就很容易產生分歧，誤解，從而導致大家分裂，大家的目標就會失敗，那麼管理者很多事情是需要通過溝通傳達，讓團隊達成方向共識，齊心協力，最終完成企業的目標
說完故事，那我們瞭解一下良好的溝通能帶來什麼？
- 管理者對團隊的總體認知和判斷力得到提升
- 和團隊成員之間建立信任和默契（信任的前提是充分的溝通，信任程度越高，溝通成本越低）
- 高質量的溝通可以幫助管理者在團隊建立和累積影響力
因為很多程式設計師可能不是很善於溝通，可能需要一些原則和指導，那麼在溝通中有哪些方面可以遵循或者注意事項，我個人總結如下 3 點經驗
- 認清個體差異（每個人的生活環境不同，對於不同的角色要學會用不同的溝通和表達方式）
- 基於目標溝通 （明確各自溝通的意圖和目的，減少不必要的誤會，避免情緒對抗）
- 多用我來回放（可以把：你是不是這個意思，可以換成，你看看我理解的是否準確）
溝通技巧的核心在於學會傾聽，對於還未掌握溝通技巧的同學，推薦一個溝通工具 3F 傾聽，照著做也可以稱為溝通小能手：
情緒控制
聊到溝通不得不聊情緒控制，為什麼管理者要避免情緒化，學會控制情緒 ? 我們先看看知識的原理：我們常常會因為出現情緒，導致溝通常常脫離事情本身，轉移到情緒的對抗上，我們的大腦皮層處理本能情緒的優先順序是高於理性的，例如憤怒，恐懼，飢餓等，所以我們經常可以看到被本能情緒覆蓋的人，往往會失去某種理性，所以我們在溝通的時候需要時刻以下兩點：
- 控制情緒
- 保持理性
文字可能比較枯燥，我們通過一張冰山圖來了解原理：
瞭解情緒控制後，我們往往會在工作中遇到，跨部門溝通，跨團隊溝通，這種情況往往都會有“部門牆”的存在，這種情況往往不能訴求於共同的上級，往往出現“部門牆”的情況就是因為之間沒有共同的上級，也無法相互影響，遇到這種情況可以通過如下幾個切入點去達成溝通的共識
- 人格：有口皆碑的人品和正直的人格可以讓別人更加容易信任你說的內容，並且被你影響
- 歷史表現：你曾經成功完成過相同的事情，就是成功案例，可以讓別人更加容易相信你
- 影響力：你是行業的知名人物或者是團隊公認的專家，權威的力量
- 邏輯：你的內容前後呼應有著緊密的邏輯，可以增加說服力
- 激情和情懷：心懷某種遠大的理想主義，並且有使命感有激情，比較容易獲得人們的幫助和認同，可以參考錘子手機的成功案例
- 互惠：明白對方的需求，溝通的目的是建立在滿足雙方的需求上
說完溝通技巧，那我們來看一下平常溝通中有哪些常踩的坑？可以對照下自己以前是否有踩過
-
溝通給人貼標籤，對人不對事（例如：你這個人怎麼這麼笨，這點事情都做不好）
-
沒有管理自己的情緒，負面情緒對團隊造成影響
-
溝通沒有閉環，訊息和郵件發出去就預設對方收到了
熟悉計算機網路的朋友應該很熟悉 TCP 協議和 UPD 協議，溝通有沒有閉環就可以對應計算機網路中的 TCP 協議（可靠網路傳輸）和 UDP 協議（不可靠的網路傳輸），我個人建議大家在溝通中儘量多的使用 TCP 協議
管理者的自我認知和成長
為什麼說管理者要比團隊擁有更快的成長，因為 管理者是團隊的天花板，你不成長則團隊不會成長，那麼管理者的自我認知首先要體現在哪些方面？
- 認知：管理者的價值是體現在團隊業績上，不要跟團隊搶功勞
- 心態：歸因於己，歸功於外，有錯都是管理者的錯，有功勞都是團隊的努力
- 擔當：不要推卸責任，就算是客觀原因，也要反省和覆盤避免，而不是把責任推給外部
能做到以上三點，我相信已經會是一個很優秀的管理者了，那麼如何保持穩定和高效的成長呢？我的個人祕訣的管理者要做好自己的 精力管理，因為大家的時間都有差不多，尤其是三十左右剛剛成家的管理者（比如說我），可以抽出的時間基本是少之又少，那麼還想在賽道上贏得競爭力那麼就要比其他人，那麼你就要保證自己有足夠的時間和身體的健康，那麼通過什麼來獲取呢？答案就是精力管理，我個人總結的精力管理分為以下幾個方面：
- 運動（每天定期的運動，可以讓你保持一個持續充沛的精力，也更加容易專注）
- 飲食（健康飲食，少吃多餐）
- 睡眠（早睡早起，不要熬夜）
- 健康（定期檢查，避免久坐）
- 情緒（放鬆，感恩，好心情）
說完角色認知和精力管理，那麼有人會不僅的思考，那麼我們持續為止努力的目標在哪裡？具備以上兩點，就像一輛高效能的好車，高速道路已經鋪好，但是要如何開往目的地？這個就要因人而異了，畢竟每個人的目標和理想都是不同的，先說說我個人，我是技術出身，到目前為止我其實也是偏愛技術的，轉管理崗位更多的是想要鍛鍊自己的軟技能，所以我持續努力的目標是有 2 個：
- 軟技能的提升：產品思維，專案規劃，帶團隊，帶人，溝通，執行力
- 硬技能的提升：架構，設計，演算法，網路，作業系統，程式語言
以上僅僅是代表我個人的目標，也可能是多數技術 Leader 的目標，對於技術管理者很多人總是有誤解，認為已經是團隊 Manger 就不需要去做具體的執行工作的，起碼這一點對於技術管理是行不通的，我個人認為技術管理者 要一直寫程式碼，因為如果不瞭解技術細節就無法做出有效的決策，而且管理者如果脫離技術，那麼也是很危險的一件事情，因為市場對管理者的需求並不多，市場需要更多的工程師去寫程式碼，管理者更多的價值是依附於企業，其很多業務知識也並非可遷移的技能，如果管理者放棄技術的話可謂是“自廢武功”，也會讓自己陷入一個很尷尬的境地，比如的性格發現自己不適合做管理的話，甚至都不能退回去做工程師了
總結
嘮嘮叨叨也寫了 5000 字，最後總結就寫簡單點，就像跟工程師，管理者或者正在走上管理路上的同僚提兩點建議，就是：
- 個人而言，做技術還是管理都不是很重要，找到自己最大的價值才是最重要的
- 不要被別人走過的路限制住，也不要被職業限制住，沒有誰可以定義你的發展
中國的官本位思考其實還是挺嚴重，很多人以為做管理就是當官，但是在軟體行業其實並不存在這一現象，目前大多數網際網路公司都是偏向扁平化管理，管理者的大家在工作中並沒有本質上的不同，而且管理者的工作更多的是偏向“打雜”（工程師視角），如果抱著這種心態去做管理，那麼我想說初衷就已經錯了，我先在這裡勸退，因為最終也可能會走向失敗，管理者更多的是要有利他精神，空悲和開放的心態，真正願意去幫助團隊成功，最終實現自己，通過成就他人來收穫成就感，關於技術管理的道理長篇大論說了很多，道理都很簡單，能不能走好管理路，還是要在“事上練”，自己感悟出來的道理才能真正的為自己所用
參考資料：
- 彼得德魯克 《卓有成效的管理者》 https://book.douban.com/subject/1322025/
- 劉建國《知行：技術人的管理之路》 https://book.douban.com/subject/33463986/
- 極客時間：《技術管理實戰》https://time.geekbang.org/column/intro/113