Engineering Leadership: The Hard Parts

全書精華

主要主題、論點、核心訊息

• 主要主題：在充滿混亂與高度不確定性的環境中，工程主管應如何引導團隊、建立穩定性，並持續交付具備商業價值的產品。
• 核心論點：混亂既是挑戰也是機遇，面對混亂時不能僅靠僵化的官僚流程來解決問題。領導者必須具備「適應力（Range）」，藉由精準診斷情境、靈活切換領導角色、建立團隊心理安全感，並以輕量級的流程專注於推動實際成果。
• 核心訊息：在混亂之中，「創造清晰度」本身就是領導者最重要的工作。透過專注於人、使命、計畫、流程與產品等五大支柱，主管能夠化無序為動力，建立出具有凝聚力、適應力，且無需過度依賴主管也能自主運作的強大團隊。

掌握作者思路必懂的關鍵要點

• 工程領導的五大支柱：工程主管的職責可具體拆解為「人（People）、使命（Mission）、計畫（Plan）、流程（Process）、產品（Product）」五個面向，這是將混亂環境轉化為清晰與穩定執行的基礎框架。
• 情境診斷與角色切換（Leadership Range）：有效的領導者不會死守單一管理風格。主管必須透過系統、人、工作與文化等四個視角來「診斷情境」，並根據團隊當下需求，在「飛行員（Pilot，著眼全局與方向）」、「醫護兵（Medic，專注團隊心理與關係）」及「工程師（Engineer，深入技術與執行）」三種角色間有意識地靈活切換。
• 化解「漂流（Drift）」並成為燈塔：混亂會導致團隊失去方向感與動力，產生白忙一場的「漂流」現象。領導者必須作為燈塔，明確指出優先事項、勇敢拒絕不重要的工作並承受權衡的代價，因為在混亂中，給予團隊清晰的方向是領導工作的核心任務。
• 心理安全感是高績效的起點：在試圖優化流程或擴張團隊之前，首要任務是降低團隊的防衛心與威脅感。如果沒有心理安全感，團隊將不敢說真話、無法創新，也無法建立真正的凝聚力與克服困難的能力。
• 推崇龐克精神與建立輕量級流程：不要試圖用繁文縟節的官僚控制來解決混亂，那只會加深功能失調。應借鑒龐克精神與開源社群的做法，採取「行動帶來清晰（Motion creates clarity）」的態度，建立剛好足夠的輕量級流程來維持前進動能，將焦點放在交付成果而非服務流程。
• 選擇「無聊技術」以避免過度工程（Choose Boring Technology）：技術策略不應盲目追逐最新潮流，而應以解決商業問題為核心。團隊應將有限的「創新籌碼（Innovation Tokens）」花在最能帶來競爭優勢的刀口上，並選擇成熟、無聊但可靠的技術，讓系統具備可擴展性且易於維護。
• 關注真實成果並善用合理指標：避免將「開發速度（Velocity）」誤用為個人的績效評估工具，這會引發反效果與技術債。應採用如 DORA 這樣的客觀指標來真實反映團隊的交付速度與品質，將指標作為了解團隊健康度與引導持續改善的指南針，而非監控團隊的武器。

反主流洞見

擁抱混亂：混亂是建立職涯與創造價值的最佳契機

• 差異點：主流觀點通常將「混亂」視為必須盡快消除的問題或應極力避免的負面狀態；但作者認為混亂反而是一種優勢與機會，甚至是成就卓越工程領導者的關鍵環境。
• 作者論證：混亂的環境剝除了官僚體系的繁文縟節與階級制度，縮短了與決策者的距離。因為缺乏既定結構與明確的所有權，反而賦予了領導者打破成規、主動承擔與建立新系統的自由。在混亂中，每一次微小的改善都會帶來巨大的動能，強迫領導者發展出多面向的綜合能力。
• 相關案例：最受尊敬的工程領導者，其職涯的決定性時刻往往是接手一個充滿災難或由膠帶拼湊起來的產品，並在其中建立穩定性，而非單純維護一個已穩定的系統。

官僚控制會加劇混亂，真正的解方是「行動創造清晰」

• 差異點：面對失控與混亂時，多數領導者的直覺是增加更多審批流程、會議和報告來奪回「控制權」；但作者指出，試圖用官僚控制來解決混亂，就像在破裂的地基上貼膠帶，只會讓團隊在溺水時還要耗費精力填寫文書表單。
• 作者論證：過度增加流程只會產生「我們很忙」的表面活動假象，卻無法帶來實質的推進動能。在失靈的環境中，最糟的不是做錯決定，而是不作決定。領導者應該採取「行動創造清晰」的原則，專注於推動具體的小型交付，用行動取代無止盡的規劃與審批。
• 相關案例：作者引用龐克音樂與開源軟體的發展精神：Ramones 樂團繞過唱片業的守門人，在 7 天內錄製完首張專輯；Linux 和 Apache 也是由看見問題並直接動手解決的人所建立，而非透過委員會設計。這些例子證明了「具備紀律的行動力」遠勝於死板的階級控制。

選擇「無聊的技術」才是卓越的技術策略

• 差異點：主流工程文化常鼓勵追逐最新、最酷炫的程式語言或框架；但作者強烈建議應該盡量選擇「無聊」的技術，將有限的創新精力花在刀口上。
• 作者論證：每家公司擁有的「創新代幣（Innovation Tokens）」是固定且有限的。頻繁重寫程式碼以追趕最新趨勢，會帶來極大的維護負擔、不穩定性以及技術債，同時也會縮小未來招募人才的範圍。技術選擇應由業務需求驅動，優化現有且成熟的技術，往往比徹底重寫更能帶來穩定成長。
• 相關案例：在 PixelCurl 的案例中，資深工程師提議用 Rust 重寫認證系統以提升效能，但工程主管 April 拒絕了這份提案。她指出公司應該將寶貴的「創新代幣」花在核心優勢（動畫渲染引擎）上，而非讓團隊耗費數月去適應新語言，最後他們僅透過優化原本「無聊的」 Node.js 就成功提升了三倍效能。此外，April 也將團隊中五種不同的資料庫整併為最基礎實用的 PostgreSQL，大幅降低了營運複雜度與雲端成本。

軟體開發的「開發速率（Velocity）」不該用來衡量生產力

• 差異點：許多企業與高階主管將團隊的開發速率（如 Story Points、程式碼提交頻率）視為績效或生產力指標，並用於團隊或個人之間的比較；但作者認為 Velocity 只是「容量規劃（Capacity Planning）工具」，用它來衡量績效是嚴重的誤用。
• 作者論證：根據「古德哈特定律（Goodhart's Law）」，當一個測量指標變成目標時，它就不再是一個好的指標。如果將開發速率視為績效，團隊就會開始操弄系統（例如灌水預估時間、將任務切得更碎），或為了求快而犧牲品質、忽略文件與程式碼審查，最終累積巨大的技術債並導致系統脆弱。
• 相關案例：當 PixelCurl 的高層要求「提升開發速率」並將每次衝刺的點數從 30 提高到 45 點時，團隊為了達標而略過程式碼審查與文件撰寫，兩個月後反而導致了長達 6小時的系統停機災難。團隊主管隨後將指標改為僅供團隊內部進行容量規劃使用，並搭配品質與穩定性指標來進行平衡。

達成對齊（Alignment）不需要團隊達成共識（Agreement）

• 差異點：主流往往認為設定方向需要團隊所有人達成共識，這常導致冗長的會議與議而不決；作者強調「對齊不等於同意」，領導者必須勇於斬斷尋求絕對共識的陷阱。
• 作者論證：真正的對齊是「即使不同意，也能全力投入執行（Disagree and commit）」。試圖讓所有人滿意只會讓權衡妥協轉入「地下化」，導致優先事項堆積如山、團隊精力嚴重分散。領導者應該明確列出「不做的清單（Not-doing list）」，讓團隊清楚知道每一個決定都伴隨著明確的取捨。
• 相關案例：Stripe 的 LATAM（拉丁美洲）工程團隊原本試圖同時兼顧 30 個優先事項（包含拓展多國新市場與法規遵循），導致團隊陷入空轉。領導層最終在會議上強制作出艱難取捨，將目標縮減至 6 個，並決定「先穩定現有市場，再擴展新市場」。雖然並非所有人都同意暫緩擴張，但決策一旦拍板，團隊便能集中火力，迅速恢復了交付動能。

內化行動計畫

1. 診斷環境上下文

• 行動目標：精準判斷當前混亂局勢的根本原因，以採取正確的領導與介入策略。
• 記憶鉤子：把脈先於開藥——善用系統、人、工作、文化的四重濾鏡。
• 故事或例子：April 面對團隊疲憊與上線失敗，並未急著引入新監控工具，而是透過濾鏡發現根本問題是基礎設施不足與業務擴張的系統性矛盾，進而調整平台投資策略。
• 觸發情境：剛接手新團隊、專案停滯不前，或常規管理手段全部失效時。
• 對象與場景：新上任主管或面對突發混亂的技術領導者。
• 具體步驟：
  • 步驟一：評估系統壓力，確認是新創求生、企業擴展還是大公司政治。
  • 步驟二：觀察人員狀態與工作負載，分辨團隊是倦怠還是抗拒，並找出隱藏工作。
  • 步驟三：檢視文化潛規則，理解公司是獎勵求快還是求穩。
• 可衡量的成果：能具體列出當前團隊的一項系統性問題，並制定對應的實際行動計畫。
• 失敗補救機制：若診斷錯誤導致團隊反彈，退回觀察者模式，設計小型實驗測試團隊反應以重新收集資訊。

2. 靈活切換領導角色

• 行動目標：根據團隊當下的實際需求與情緒，提供最適合的領導支援模式。
• 記憶鉤子：三面變色龍——飛行員、醫護兵、工程師。
• 故事或例子：April 在一次事故檢討會上，面對業務施壓時切換「飛行員」講大局；面對資深工程師防衛時切換「醫護兵」安撫情緒；最後切換「工程師」與團隊一起解決部署細節。
• 觸發情境：團隊陷入無效爭論、士氣低落或技術卡關停滯不前時。
• 對象與場景：日常會議、事件檢討會（Postmortem）或一對一指導場合。
• 具體步驟：
  • 步驟一：辨識團隊當下需要看清大局、情緒安撫，還是具體的技術支援。
  • 步驟二：刻意切換至對應角色（飛行員指引方向、醫護兵重建信任、工程師捲起袖子實作）。
  • 步驟三：解決當下的溝通或技術瓶頸後，向團隊說明切換角色的意圖並退回適當位置。
• 可衡量的成果：會議能從無效的情緒爭辯，轉變為擁有明確行動項目的具體結論。
• 失敗補救機制：若頻繁切換導致團隊混淆，請明確溝通你的意圖，讓團隊理解你為何改變領導方式。

3. 建立心理安全感

• 行動目標：降低團隊防衛心，促使成員敢於分享真實的痛點、錯誤與未知。
• 記憶鉤子：主動示弱破冰——領導先坦承不懂，團隊才敢說真話。
• 故事或例子：April 初到新團隊時無人願在會議發言。她主動分享自己看不懂部署流程的混亂畫面並承認迷失，這個示弱引發共鳴，工程師們才開始吐露沒有文件的真實痛點。
• 觸發情境：團隊死氣沉沉、報喜不報憂，或剛接手防衛心極重的新團隊時。
• 對象與場景：團隊例會、代碼審查（Code Review）或專案啟動會議。
• 具體步驟：
  • 步驟一：主動在團隊面前展現好奇心，並坦承自己的未知或錯誤。
  • 步驟二：對於成員提出的困難或失誤，先傾聽，絕不急著下定論或指責。
  • 步驟三：將問題焦點放在「我們能學到什麼」，而非「是誰搞砸了」。
• 可衡量的成果：團隊成員主動在公開頻道提出問題、尋求協助或承認錯誤的頻率明顯增加。
• 失敗補救機制：若公開會議依然沉默，可改用一對一私下交流來逐步建立初步信任。

4. 成為指路燈塔與設立停止清單

• 行動目標：終止團隊瞎忙的「漂流」狀態，將精力集中於高價值的產出。
• 記憶鉤子：砍掉重練的減法——說「不」才是真正的優先級。
• 故事或例子：Stripe 團隊曾同時處理 30 個優先事項導致疲憊不堪。領導層強制將目標縮減至 6 個，明確列出「不做的清單」，讓工程師終於有權限對雜事說不，重新找回專注。
• 觸發情境：需求超載、專案不斷蔓延，或團隊什麼都想做卻什麼都沒做完時。
• 對象與場景：季度規劃、衝刺計畫會議（Sprint Planning）。
• 具體步驟：
  • 步驟一：為下個週期設定一個最核心、具體的單一成果目標。
  • 步驟二：條列出明確的「不做的清單（Not-doing list）」並公開展示。
  • 步驟三：在每次會議以一句話重複該目標，直到團隊完全內化為止。
• 可衡量的成果：團隊成員能不加思索說出當前核心目標，且非目標任務佔比顯著降低。
• 失敗補救機制：若外部壓力強行塞入新任務，堅持「一進一出」原則，要求利害關係人決定替換掉清單上的哪一項。

5. 推行 RFC 技術決策機制

• 行動目標：消除閉門造車與無效爭論，讓技術決策透明化、非同步化且具備明確所有權。
• 記憶鉤子：先寫後做——RFC 是技術架構的避雷針。
• 故事或例子：StudioOps 團隊曾因「誰先寫程式誰贏」導致系統混亂。引入 RFC 後，有工程師提議用 Rust 重寫後端，團隊透過 RFC 審查提前點出招募與時程風險，成功阻止了災難。
• 觸發情境：準備引入新工具、推動重大架構變更，或團隊常為技術選型爭論不休時。
• 對象與場景：架構變更前期、新功能設計或技術選型階段。
• 具體步驟：
  • 步驟一：提供標準但輕量的 RFC 模板，包含動機、詳細設計、缺點與替代方案。
  • 步驟二：要求任何新工具或架構變動前，必須先提交 RFC 並分享給團隊。
  • 步驟三：給予團隊非同步審查的時間，最後由決策者核准並存檔為紀錄。
• 可衡量的成果：所有重大技術決策皆有文件紀錄，技術會議中的無效爭論時間大幅縮短。
• 失敗補救機制：若 RFC 淪為長篇大論拖慢進度，限制 RFC 最長為兩頁，並嚴格設定審核的時限。

6. 利用影響力與精力矩陣優先排序

• 行動目標：科學化評估任務價值，避免團隊陷入低價值卻高耗能的泥淖。
• 記憶鉤子：尋找甜蜜點——高影響低精力先做，高精力低影響放棄。
• 故事或例子：April 利用此矩陣排定優先級：推動「每週跨團隊代碼審查（高影響/低耗能）」立刻打破穀倉效應；而耗時的「全面入職培訓（高影響/高耗能）」則推遲到下季度，迅速取得早期勝利。
• 觸發情境：待辦清單過度膨脹，或面臨多方利害關係人同時施壓要求新功能時。
• 對象與場景：Backlog 梳理會議、產品迭代與資源分配規劃。
• 具體步驟：
  • 步驟一：將待辦任務轉化為具備商業價值描述的使用者故事。
  • 步驟二：畫出以「影響力（垂直）」與「精力（水平）」為軸的四象限矩陣。
  • 步驟三：將任務放上矩陣，優先執行左上角，分解右上角，直接刪除或延後右下角。
• 可衡量的成果：待辦清單中的低價值任務減少，團隊每週能交付 2-3 項高影響力的成果。
• 失敗補救機制：若團隊對「影響力」有爭議，引入具體的商業指標（如營收、減少的基礎設施成本）作為客觀評估標準。

整體執行建議

• 搭配方式：先運用「診斷環境上下文」看清局勢與團隊狀態，接著以「主動示弱破冰」建立心理安全感打通溝通管道；穩定後，再透過「指路燈塔與停止清單」以及「影響力矩陣」收斂焦點，最後用「RFC 機制」確保技術執行的透明與高品質。
• 執行週期：建議以 6 週為一個基礎迭代週期。每季進行一次策略與技術原則的回顧，每週的 Standup 中確認是否仍對齊單一核心目標。
• 防棄機制：
  1. 建立每日口訣與過濾器：在日常會議中，遇到新需求只問一句：「這對我們當前的核心目標有幫助嗎？」若無則直接放入冰箱或拒絕。
  2. 從小處著手實驗：不要一次推行所有變革。先選擇團隊最痛的一個流程（例如混亂的技術決策），進行為期兩週的小型實驗，取得成功後再擴展。

記憶卡片總表