本章概覽#

在第五章中，我們討論了從「個人貢獻者」（Individual Contributor）轉變為團隊領導者的歷程。本章則進一步探討：當你從領導一個團隊擴展到領導多個團隊時，如何持續保持效能。

隨著角色演進，你仍然是「僕人式領導者」（Servant Leader），只是服務的群體更大了。你解決的問題範圍變得更廣、更抽象——你被迫從「深入」轉向「廣泛」，逐漸遠離技術細節。這個過程令人沮喪：你哀悼失去的技術深度，也意識到過去的工程專業與你的工作越來越不相關。取而代之的是，你的效能更加仰賴通用的技術直覺以及引導工程師朝正確方向前進的能力。

這個過程常令人士氣低落——直到某天你注意到，身為領導者，你的影響力實際上遠超過當個人貢獻者的時候。這是一個令人滿足但苦樂參半的體悟。

本章以所謂的「領導者的三個 Always」為核心框架：

1. Always Be Deciding（持續決策）
2. Always Be Leaving（持續放手）
3. Always Be Scaling（持續擴展）

Always Be Deciding（持續決策）#

管理多個團隊（a team of teams）意味著在更高的層級做出越來越多的決策。你的工作更多是關於高層策略，而非解決某個特定的工程任務。在這個層級上，大多數決策都是關於找到正確的取捨組合（Trade-offs）。

飛機的寓言#

作者的朋友 Lindsay Jones 分享了一個關於航班的真實故事：一架飛機因為油箱多加了一萬加侖燃料，機長宣布兩個選項——要嘛等一個多小時讓油罐車把燃油抽回去，要嘛需要二十名乘客立刻下機以平衡重量。一位頭等艙旅客急著趕會議，怒不可遏地掏出一大疊現金，以每人四十美元的代價讓二十個人下了飛機（總共八百美元）。

飛機準備起飛，結果機上電腦又當機了，只好被拖回登機門。這位旅客要求改搭其他航班，但下一班 8:00 的航班已經滿了——因為那二十位拿了錢下機的乘客，全部都搭上了 8:00 那班飛機。登機口人員說：「他們是我見過最開心的乘客，笑著走過空橋。」

這個故事的核心就是取捨（Trade-offs）。取捨不僅適用於技術系統，也適用於人類行為。作為領導者，你每週都要為團隊做出取捨決策：

• 有時取捨很明顯：「如果我們做這個專案，另一個就會延遲……」
• 有時取捨會產生不可預見的後果，像上面的故事一樣反過來咬你一口

領導者在決策中的三個步驟#

在最高層級，無論你領導一個團隊或一個更大的組織，你的工作是引導人們解決困難且模糊的問題。所謂模糊，是指問題沒有明顯的解法，甚至可能無法解決。如果寫程式碼就像砍樹，那麼領導者的工作就是「透過樹木看見森林」，找到一條可行的路徑，引導工程師朝重要的目標前進。

這個過程有三個主要步驟：

1. 辨識盲點（Identify the Blinders）#

當你初次接手一個問題時，往往會發現一群人已經與它搏鬥多年。他們沈浸在問題中太久，已經戴上了「眼罩」——無法再看到森林全貌。他們在不自覺中對問題（或解法）做了大量假設：「我們一直都是這麼做的。」有時候，你會發現奇怪的應對機制或合理化說詞，用來維護現狀。

這正是你——帶著新鮮視角——擁有巨大優勢的地方。你能看到這些盲點、提出問題，然後思考新的策略。當然，對問題不熟悉並不是好領導的必要條件，但它往往是一個優勢。

2. 辨識關鍵取捨（Identify the Key Trade-Offs）#

重要且模糊的問題不會有「銀彈」式的萬能解法。沒有一個答案能永遠適用於所有情況，只有當下的最佳答案，而它幾乎必然涉及某個方向的取捨。你的工作是指出取捨、向所有人說明，然後協助決定如何平衡。

3. 決策，然後迭代（Decide, Then Iterate）#

理解了取捨及其運作方式後，你就有了做出決策的能力。你可以根據這些資訊做出這個月的最佳決策；下個月，你可能需要重新評估和再次平衡——這是一個迭代的過程。這就是「Always Be Deciding」的含義。

如果你沒有把決策過程框架為「持續重新平衡取捨」，團隊很可能會掉入尋找完美解法的陷阱，導致所謂的「分析癱瘓」（Analysis Paralysis）。

你需要讓團隊習慣迭代。降低風險感知的一個有效方法是告訴團隊：

「我們先試試這個決定，看看效果如何。下個月，我們可以撤回變更或做出不同的決策。」

這能保持團隊的靈活性，讓他們處於一種持續從選擇中學習的狀態。

案例研究：解決 Google Web Search 的「延遲」問題#

當你管理多個團隊時，往往會從負責單一產品轉向負責一整個「產品類別」或跨產品的更廣泛問題。Google 最古老的產品 Web Search 就是一個好例子。

多年來，數千名 Google 工程師致力於改善搜尋結果的「品質」（Quality）。但追求品質有一個副作用：產品逐漸變慢。過去，Google 搜尋結果不過是一頁十個藍色連結。十多年來，成千上萬的微小改進帶來了更豐富的結果：圖片、影片、Wikipedia 資訊方塊、甚至互動式 UI 元素。這意味著伺服器需要做更多工作、傳輸更多位元組、客戶端（通常是手機）需要渲染越來越複雜的 HTML。即便網路速度和電腦效能大幅提升，搜尋頁面的延遲（Latency） 卻持續增加。

即使是短至 10 毫秒的渲染延遲增加也會影響使用者的參與度和使用頻率。延遲是緩慢累積的，不是某個特定團隊的錯，而是長期的「公地悲劇」（Poisoning of the Commons）。

多年來，許多領導者嘗試過解決這個問題，但都未能系統性地處理。所有人戴著的盲點是：他們假設處理延遲的唯一方法就是每兩三年宣布一次延遲「Code Yellow」（Google 的緊急黑客松——受影響的團隊必須暫停所有工作，將 100% 的注意力集中在問題上，直到緊急狀態宣布結束）。這個策略暫時有效，但一兩個月後延遲就會回到原來的水準。

轉折點在於：團隊退後一步，辨識出盲點，並全面重新評估取捨。結果發現追求「品質」不只有一個成本，而是兩個：

• 對使用者的成本：更高品質通常意味著更多資料傳輸，造成更多延遲
• 對 Google 的成本：更高品質意味著伺服器需要做更多運算，消耗更多 CPU 時間——即「服務容量」（Serving Capacity）

過去領導層小心翼翼地在品質和容量之間取捨，卻從未把延遲視為同等重要的因素。套用那句老笑話：「好、快、便宜——三選二。」可以用一個張力三角形來描繪這三者之間的取捨：Good（品質）、Fast（延遲）、Cheap（容量）。

改善其中任何一個特性都很容易——只要刻意犧牲另外至少一個：

• 提升品質：在搜尋結果頁放更多資料，但會傷害容量和延遲
• 降低延遲：減少叢集流量（讓它運行得「更冷」），每個查詢更快，但整體服務容量降低
• 增加容量：向叢集發送更多查詢，CPU 利用率更高，但資源競爭加劇，平均延遲惡化

關鍵洞見：更好地理解所有取捨，讓團隊能開始嘗試新的平衡方式。延遲不再是不可避免的意外副作用，而是與其他目標同等級的一級目標。資料科學家精確測量延遲對使用者參與度的影響，建構出一個指標，將品質驅動的短期參與度提升與延遲驅動的長期參與度損害進行量化對比。這讓團隊能做出更資料驅動的產品決策——持續決定品質、延遲和容量的變更是否平衡，每月迭代。

Always Be Leaving（持續放手）#

乍看之下，「Always Be Leaving」聽起來像是糟糕的建議。為什麼一個好的領導者要試著離開？事實上，這是 Google 前工程總監 Bharat Mediratta 的名言。他的意思是：你的工作不僅是解決模糊的問題，而是讓你的組織能在沒有你的情況下自行解決問題。如果做到了，你就能自由地轉向新的問題（或新的組織），留下一連串自給自足的成功。

這裡的反模式（Antipattern）是讓自己成為單點故障（Single Point of Failure, SPOF）。Google 用「巴士係數」（Bus Factor）來衡量這個風險：需要多少人被巴士撞到，你的專案才會完全失敗。

當然，「巴士」只是一個隱喻。人會生病、換團隊或換公司、搬家。作為石蕊測試，想想一個你的團隊正在順利推進的困難問題。現在想像你——領導者——消失了。你的團隊會繼續前進嗎？它會繼續成功嗎？

做一個更簡單的測試：回想你上一次至少一週的假期。你是否一直在查看工作郵件？（大多數領導者都會。）問問自己為什麼。如果你不關注，事情會崩潰嗎？如果答案是肯定的，你很可能已經讓自己成為 SPOF。你需要修正這一點。

你的使命：打造「自動駕駛」團隊#

回到 Bharat 的名言：成功的領導意味著打造一個能自行解決困難問題的組織。這個組織需要：

• 一組強大的領導者
• 健康的工程流程
• 能隨時間自我延續的正向文化

構建這種自給自足的團隊有三個主要部分：

1. 劃分問題空間（Dividing the Problem Space）#

有挑戰性的問題通常由困難的子問題組成。一個明顯的做法是讓每個團隊負責一個子問題。但風險在於子問題會隨時間改變，而僵化的團隊邊界無法適應這種變化。

如果可能的話，考慮一種更鬆散的組織結構：子團隊可以改變規模、個人可以在子團隊間遷移、分配給子團隊的問題可以隨時間演變。這需要在「太僵化」和「太模糊」之間走一條細線——一方面要讓子團隊有清晰的目標和成就感，另一方面要給予人們改變方向和嘗試新事物的自由。

範例：拆分 Google Search 的延遲問題

在處理搜尋延遲問題時，團隊發現問題至少可以拆分為兩個空間：

• 處理延遲的症狀：優化程式碼提升速度
• 處理延遲的原因：防止延遲的源頭產生

光靠加速還不夠——成千上萬的工程師持續增加搜尋結果的複雜度和「品質」，速度改進一落地就被抵消。團隊還發現了指標、延遲分析工具以及開發者教育和文件方面的缺口。透過同時指派不同團隊處理延遲的原因和症狀，他們才得以長期系統性地控制延遲。

注意這些團隊擁有的是問題，而不是特定的解決方案。這一點至關重要。

2. 將子問題委派給領導者（Delegating Subproblems to Leaders）#

委派（Delegation）是管理書籍中的老生常談，但它確實極難學習——它違背了我們對效率和成就的所有本能。這就是為什麼有句諺語說：「如果你想把事情做好，就自己做。」

然而，如果你的使命是打造一個自動駕駛的組織，教導的主要機制就是透過委派。你必須建立一組自給自足的領導者，而委派是訓練他們最有效的方式——給他們任務、讓他們失敗、然後再試一次又一次。矽谷有句著名的口號「快速失敗並迭代」（Fail Fast and Iterate），這個哲學不僅適用於工程設計，也適用於人的學習。

當你的待辦事項不斷堆積時，在動手之前問自己一個關鍵問題：

我真的是唯一能做這項工作的人嗎？

也許你做最有效率，但這樣你就沒在訓練你的領導者。除非任務真的火燒眉毛，否則把工作交給別人——即使他們需要更長時間完成。你需要為領導者創造成長機會，讓他們學會「升級」並自行完成這些工作，讓你不再處於關鍵路徑上。

相對地，每天到辦公室時問自己另一個關鍵問題：

我能做什麼是團隊中沒有其他人能做的？

好的答案包括：

• 保護團隊免受組織政治的干擾
• 給予團隊鼓勵
• 確保每個人都以謙遜、信任和尊重（HRT）的方式對待彼此
• 向上管理，確保管理鏈了解團隊在做什麼
• 最重要的是：「我能透過樹木看見森林」——定義高層策略，不僅涵蓋技術方向，還包括組織策略。你在建構一份藍圖，描繪如何解決模糊問題，以及你的組織如何長期管理這個問題。你持續地繪製森林的地圖，然後把砍樹的任務交給別人

3. 調整與迭代（Adjusting and Iterating）#

假設你已經打造了一個自我維持的機器，不再是 SPOF。現在該做什麼？

你已經解放了自己——你有了「Always Be Leaving」的自由。這可能意味著處理一個新的相鄰問題，甚至搬到全新的部門和問題空間，為你培養的領導者騰出職涯發展的空間。這也是避免個人倦怠（Burnout）的好方法。

「接下來做什麼？」的簡單答案是：引導這台機器並保持其健康。除非有危機，否則應該用輕柔的觸碰。《Debugging Teams》一書中有一個寓言：

一位退休的機械大師被請回來解決一個沒人能修好的問題。他仔細檢查機器、聆聽它運轉，最後拿出粉筆在機器側面畫了一個小 X，告訴技師那個位置有一根鬆掉的電線。技師打開機器、收緊電線，問題解決了。大師開出一萬美元的帳單——其中粉筆標記一美元，知道畫在哪裡九千九百九十九美元。

這就是好的管理：95% 的觀察和傾聽，5% 在正確的位置做出關鍵調整。

具體而言：

• 傾聽你的領導者和跨級報告（Skip-Reports）
• 與你的客戶交談——如果你的團隊建構的是工程基礎設施，你的「客戶」往往不是外部使用者，而是你的同事。客戶的滿意度需要和你的直屬報告的滿意度一樣用心傾聽
• 問自己：什麼在運作？什麼不在運作？這艘自動駕駛飛艇是否朝著正確方向前進？

你的方向調整應該是迭代性的、深思熟慮的且最小化的，只做必要的修正。

如果你退回到微觀管理（Micromanagement），就有再次成為 SPOF 的風險。「Always Be Leaving」是對巨觀管理（Macromanagement）的呼籲。

注意團隊身分的錨定#

一個常見的錯誤是讓團隊負責特定產品而非通用問題。產品是問題的解法，解法的壽命可能很短，產品可能被更好的方案取代。但如果選得好，問題可以是長青的。

• 不好的錨定：「我們是管理 Git 倉庫的團隊」
  • 如果大比例的工程師想換到新的版本控制系統，團隊可能會「挖壕溝」、捍衛自己的方案、抵制變革
  • 解決方案已經成為團隊身分和自我價值的一部分，團隊會緊抓著盲點不放
• 好的錨定：「我們是為公司提供版本控制的團隊」
  • 團隊被解放出來，可以自由地隨時間嘗試不同的解決方案
  • 問題（如果選得好的話）可以是長青的，而解法的壽命往往很短

將團隊身分錨定在問題上，而非特定解法上——這是構建持久組織的關鍵原則。

Always Be Scaling（持續擴展）#

許多領導力書籍從進攻的角度討論「擴展」——如何最大化你的影響力、擴大團隊和影響力。本章不討論這些。打造一個有強大領導者的自動駕駛組織本身就是成長和成功的最佳秘方。

本節從防禦性和個人性的角度來討論團隊擴展。作為領導者，你最珍貴的資源是有限的時間、注意力和精力（Time, Attention, and Energy）。如果你激進地擴大團隊的職責和權力，卻沒學會在過程中保護個人的理智（Sanity），這種擴展注定失敗。因此，我們要討論的是如何在這個過程中有效地擴展你自己。

成功的循環（The Cycle of Success）#

當團隊處理困難問題時，會出現一個標準的模式——一個特定的循環：

1. 分析（Analysis）：接收問題並開始搏鬥。辨識盲點、找出所有取捨、建立如何管理取捨的共識
2. 掙扎（Struggle）：無論團隊是否認為準備好了，開始推進工作。為失敗、重試和迭代做好準備。你的工作主要是「放牧貓群」——鼓勵領導者和一線專家形成意見，然後仔細傾聽並制定整體策略（即使一開始需要「假裝」）
3. 牽引力（Traction）：團隊開始弄清楚狀況。做出更聰明的決策，取得實質進展，士氣提升。組織開始自行圍繞問題運轉
4. 獎勵（Reward）：主管把你拉到一旁恭喜你的成功。你發現獎勵不只是拍拍肩膀，而是一個全新的問題要處理。沒錯：成功的獎勵是更多工作和更多責任

在掙扎階段，冒充者症候群（Imposter Syndrome）很容易出現。一個對抗的技巧是假裝有某位專家確切知道該怎麼做，而他們只是在度假，你暫時代班。這能消除個人利害關係，給自己失敗和學習的許可。

你陷入了困境：你被賦予了新問題，但通常沒有更多人力。你需要用一半的人在一半的時間內管理原來的問題，另一半的人去處理新工作。這個最終步驟稱為壓縮階段（Compression Stage）：你把之前做的一切壓縮到一半的規模。

因此，成功的循環實際上更像是一個螺旋（見下圖）。隨著月份和年份推移，你的組織通過處理新問題、然後壓縮它們來擴展規模，以便承接新的、平行的挑戰。如果幸運的話，你可以在過程中招聘更多人。但更多時候，招聘速度趕不上擴展速度。Google 共同創辦人 Larry Page 大概會稱這個螺旋為「令人不安地興奮」（Uncomfortably Exciting）。

成功的螺旋是一個難題——它難以管理，卻是擴展團隊的主要範式。壓縮問題不僅是弄清楚如何最大化團隊效率，也是學習如何擴展你自己的時間和注意力，以匹配新的職責廣度。

重要 vs. 緊急（Important Versus Urgent）#

回想你還不是領導者時，身為無憂無慮的個人貢獻者，你的生活可能更平靜。你有一份工作清單，每天按部就班地完成，寫程式碼和除錯。

但當你進入領導角色後，你的主要工作模式變得更不可預測、更多是救火——從主動（Proactive）轉為被動（Reactive）。你在領導階層越高，收到的升級（Escalation）越多。你就像是一長串程式碼區塊中的 finally 子句！你的所有溝通管道——郵件、聊天室、會議——開始感覺像是對你的時間和注意力發動阻斷服務攻擊（DoS Attack）。如果你不保持警覺，最終會把 100% 的時間花在被動模式中——人們不斷向你丟球，你瘋狂地從一顆球跳到下一顆，試圖不讓任何一顆落地。

管理學作者 Stephen Covey 以區分「重要」與「緊急」的概念而聞名。事實上，這個概念是美國總統 Dwight D. Eisenhower 在 1954 年的一句名言中推廣的：

「我有兩種問題：緊急的和重要的。緊急的不重要，重要的從不緊急。」

這種張力是領導效能的最大威脅之一。如果你讓自己滑入純粹的被動模式（這幾乎會自動發生），你會把每一刻都花在緊急的事情上，但幾乎沒有一件是大局中重要的。

記住，你的工作是做只有你能做的事，比如規劃穿越森林的路徑。建構這種元策略（Meta-Strategy）極其重要，但幾乎從不緊急。回覆下一封緊急郵件總是比較容易的。

以下是幾個關鍵技巧，幫助你把精力集中在重要的事情上：

• 委派（Delegate）：許多緊急事項可以委派回組織中的其他領導者。這是對他們的好訓練，也釋放了你的時間去做只有你能做的重要事情
• 排定專屬時間（Schedule Dedicated Time）：定期留出兩小時或更多時間，安靜地只處理重要但不緊急的事務——例如團隊策略、領導者的職涯發展路徑、或與鄰近團隊的協作計畫
• 找到有效的追蹤系統（Find a Tracking System That Works）：不論是軟體工具、紙筆系統（如 Bullet Journal），還是 David Allen 的《Getting Things Done》方法論，重點是找到一個比電腦螢幕上貼滿便利貼更有效的系統

學會放手（Learn to Drop Balls）#

還有一個關鍵技巧，乍聽之下很激進：刻意放掉一些球。

身為工程師，你注重細節、列清單、精確完成每件事。但身為領導者的領導者，你的時間和注意力不斷受到攻擊。無論你多努力，你都會掉球——被丟過來的球實在太多了。

既然掉球不可避免，刻意選擇掉哪些球不是比意外掉球好嗎？至少你還有一些掌控權。

既然掉球不可避免，不如借鑑 Marie Kondo（近藤麻理惠）的整理哲學。她的《怦然心動的人生整理魔法》核心論點是：大多數人整理不當——他們花時間丟掉底部 20% 明顯的垃圾，但剩下的 80% 仍然感覺太雜亂。她主張真正的整理工作是辨識頂部 20%，而非底部 20%。如果你能找出真正關鍵的東西，就應該丟掉其他 80%。

將這個哲學應用到你的收件匣或任務清單上，把任務分為三堆：

• 底部 20%：既不緊急也不重要，很容易刪除或忽略
• 中間 60%：可能有些緊急或重要的成分，但參差不齊
• 頂部 20%：絕對、至關重要的事項

不要試圖處理前 80% 的任務——你仍然會被淹沒，最終主要處理緊急但不重要的事。取而代之，用心辨識嚴格落在頂部 20% 的球——只有你能做的關鍵事項——並專注於它們。給自己明確的許可放掉其他 80%。

這麼做一開始可能感覺很糟，但你會發現兩件驚人的事：

1. 即使你沒有委派中間 60% 的任務，你的副手們往往會注意到並自動接手
2. 如果中間桶裡的某件事真的很關鍵，它最終會回到你面前，自然遷移到頂部 20%

你只需要相信低於你 20% 門檻的事情要嘛會被處理，要嘛會適當演化。與此同時，因為你只專注於至關重要的事，你就能擴展你的時間和注意力，覆蓋團隊不斷增長的職責。

保護你的精力（Protecting Your Energy）#

我們談了保護時間和注意力，但個人精力是等式的另一塊。所有這些擴展都令人精疲力竭。在這樣的環境中，你如何保持充沛和樂觀？

部分答案是隨著時間推移，你的整體耐力會增長。在職涯早期，每天在辦公室工作八小時可能感覺像一場衝擊，回家時疲憊不堪。但就像訓練馬拉松一樣，你的大腦和身體會隨時間建立更大的耐力儲備。

另一個關鍵是領導者逐漸學會更聰明地管理精力——持續關注自己當下有多少能量，並在特定時刻以特定方式刻意「充電」。以下是一些有意識的精力管理範例：

• 真正的假期（Take Real Vacations）：週末不算假期。至少需要三天才能「忘記」工作，至少一週才能真正感到恢復。但如果你查看工作郵件，就破壞了充電效果。假期只有在你真正紀律性地斷線時才有效——而這只有在你建立了自動駕駛組織之後才可能
• 讓斷線變得輕鬆（Make It Trivial to Disconnect）：斷線時把工作筆電留在辦公室。如果手機上有工作通訊，移除它們。例如使用手機的「工作設定檔」功能，一鍵停用所有工作 App
• 真正的週末（Take Real Weekends, Too）：週末的恢復力不如假期，但仍然有效。週五晚上真正登出，週末做你喜歡的事，週一早上回到辦公室再登入
• 白天休息（Take Breaks During the Day）：你的大腦以自然的 90 分鐘週期運作。利用機會站起來走走辦公室，或花 10 分鐘到外面散步。微小的休息只是微小的充電，但對你的壓力水平有巨大的影響
• 給自己心理健康日的許可（Give Yourself Permission to Take a Mental Health Day）：有時候，沒有任何原因，你就是過了糟糕的一天。如果你是領導者，你的壞心情會為周圍所有人定調，可能導致糟糕的決策。如果遇到這種情況，轉身回家，宣布請病假。什麼都不做比造成主動傷害好

最終，管理精力和管理時間同樣重要。如果你學會掌握這些，你就準備好應對更廣泛的職責擴展循環，並打造一個自給自足的團隊。

結論#

成功的領導者隨著進步自然地承擔更多責任——這是好事，也是自然的發展。然而，除非他們有效地發展出快速決策、適時委派、以及管理不斷增加的責任的技巧，否則可能會感到不堪重負。

成為一個有效的領導者不意味著你需要：

• 做出完美的決策
• 事事親力親為
• 加倍努力工作

取而代之，努力做到：

1. Always Be Deciding（持續決策）
2. Always Be Leaving（持續放手）
3. Always Be Scaling（持續擴展）

TL;DRs#

• Always Be Deciding：模糊的問題沒有神奇的答案，關鍵在於找到當下正確的取捨，並持續迭代
• Always Be Leaving：作為領導者，你的工作是建立一個能隨時間自動解決模糊問題的組織——不需要你在場
• Always Be Scaling：成功會隨時間帶來更多責任，你必須主動管理這種擴展，以保護你稀缺的個人時間、注意力和精力資源