您本月還剩下 1 篇文章可閱讀，之後需要註冊 LeadDev.com 的免費帳戶。

預估閱讀時間：10 分鐘

重點摘要：

  • 工程經理面臨的是權衡問題，而非工作量問題。每一項期望單獨來看可能都合理，問題在於它們同時擴張。
  • 隱藏的權衡與可見的權衡一樣真實。把選擇清楚呈現，才能有具體的討論空間。
  • 目標是把判斷力集中用在真正能改變結果的地方。

工程經理被要求在每個面向都做得更多。你可能被期待帶領團隊更快運用 AI、緊跟技術決策、在不確定性中教練團隊、跨團隊影響他人，並以更具策略性的方式運作。

每一項期望單獨來看可能都合理。問題在於它們同時擴張。這通常被描述成工作量問題，但其實是權衡問題。

領導力容量是有限的。你只有這麼多注意力可以分配給教練、審查、決策、升級，以及理解不斷變動的組織。無論是否有人承認，有些事情已經被捨棄了。聰明的做法是把這些權衡清楚呈現出來。

這不是為了減少工作而減少工作，而是更清楚知道自己的判斷力最該用在哪裡、選擇忽略什麼，以及誰需要知道這些選擇。

Your inbox, upgraded.

Receive weekly engineering insights to level up your leadership approach.

工程經理角色並非線性擴張

許多工程組織談論管理容量時，彷彿它能線性擴張。只要再多幾個專案、利害關係人或依賴關係，經理就能神奇地撐住。

然而，範疇並非只朝單一方向成長。有時代表更多直屬部屬；有時代表更少但更資深的人、同時運行更多工作；有時代表更多跨團隊依賴、較不明確的職責，或更多技術變更同時流經系統。

AI 又在這之上增加了一層複雜度。它能幫助團隊更快產出工作，但也會增加你需要解讀的材料：更多功能提案、更長的規格，以及更多半成品選項爭取你的決策。瓶頸從「產出工作」轉移到「判斷哪些工作有意義、值得去做」。

控制範圍（span of control）與情境負載（context load）的差異很重要。控制範圍是指有多少人向你報告；情境負載則是指你同時需要處理多少對話、決策與風險。

認知超載會以細微的方式出現：風險浮現變慢、教練回饋變淺、技術判斷變得不可靠。

身為經理，你並沒有變得更沒能力，而是角色本身已超過一個人能好好承擔的情境量。

3 項需要清楚說明的權衡

隱藏的權衡很少感覺像是真正的選擇。它們更像是壓力堆積下的即興應對。

你可能因為某位團隊成員這週很艱難而需要你，錯過設計審查；你可能因為跨團隊的火燒眉毛而縮短一對一；你可能讓工程師自己負責一場會議，因為你無法同時出現在每個地方；你可能跳過策略文件，因為眼前的交付風險更急迫。

這些選擇不一定錯。其中大多數正是好的經理應該做的。關鍵在於你是否刻意做出這個權衡，以及周遭的人是否知道你做了這個選擇。

以下將這些反覆出現的張力分成幾組，來探討不同於預設反應的做法。

More like this

1. 深度 vs. 廣度

第一個權衡是：在涵蓋越來越大的組織表面時，你能多深入地理解自己負責的系統與決策。

選擇深度，你會參與設計審查、架構討論與風險對話。你能更直接地抓到問題，也能真正教練工程師處理細節，但用在跨團隊對齊、影響力與串聯工作的時間就會減少。

選擇廣度，你會把時間用在形塑職責、升級路徑、優先順序，以及決策該在哪裡做出。這可能正是團隊需要的，但如果你不說清楚，工程師仍會期待你參與每一場重要的技術對話，而你的主管則期待你往上三個層級工作。

不管哪一種，未被滿足的期望都會帶來挫折。

更清楚的說法是：「考量我們目前的範疇，我這個季度會優先選擇廣度。我會減少參與詳細設計審查，把更多時間用在確保有正確的負責人、正確的決策場域，以及清楚的升級路徑。」

這樣大家就有具體的內容可以討論。你的主管可以挑戰它，團隊也可以指出風險。這正是重點。一旦權衡被清楚呈現，就能被討論與調整。

2. 急迫 vs. 重要

第二個權衡是：當步調從不放緩時，你能保護多少時間給長期品質、團隊健康與策略。

急迫的工作很吵。事故、升級、阻礙、高階主管的要求、客戶問題、接近的截止期限——這些都要求你立刻處理。

重要的工作通常比較安靜。教練新任技術主管、寫下決策規則以減少未來干預、修復不斷製造火災演練的流程缺口、在下一次規劃週期爆炸前建立對齊。

我們總告訴自己，等事情平靜下來再處理重要的事。我們都知道，大多數地方的事情都不會平靜下來。

更刻意的做法可能是：「這個月我會保護時間來教練我們的新技術主管。除非有範疇、可靠性或跨團隊依賴需要我參與，否則我不會出席每場專案狀態會議。」

句子本身不重要，重要的是清楚說明什麼事情會得到較少的你。如果跳過這一步，你的行事曆就會變成你的策略，而最吵的事情永遠會勝出。

3. 出席 vs. 影響

第三個權衡是：在不稀釋對真正能推動關鍵事項的影響力之下，你能在每場對話與審查中保持多少出席。

經理常常把能見度與價值混為一談。出席每一場會議感覺很負責、被抄送每一封信件感覺很有資訊、審查每一個決策感覺很安全。但超過某個點，能見度只是對你判斷力的稅收。

更好的問題不是「我應該出現在哪裡？」，而是「我的出席在哪裡能改變結果？」

有時這代表退出定期會議、改看 AI 摘要；有時代表讓工程師主導架構討論，只在決策觸及事先約定的界線時才介入；有時代表把狀態更新換成簡短的風險清單、需要做的決策，以及仍懸而未決的依賴關係。

一個有用的界線可以這樣說：「我不需要參與每場討論。我只需要在決策涉及客戶承諾、可靠性、人員配置或另一個團隊的 roadmap 時，提前得到通知。」

這有助於團隊理解你的參與真正意味著什麼。不是每個決策都要等你，而是正確的決策在正確的時機、以足夠的脈絡送到你手上，讓你的判斷力真正有價值。

讓我們再深入探討這一點。

把監督視為有限容量

我們通常很擅長管理技術容量。我們追蹤利用率、飽和度、延遲、錯誤預算與瓶頸。我們毫無疑問地接受：當需求超過容量時，系統就會退化。我們幾乎從不這樣看待領導力。

每個組織都只有有限的審查、決策、驗證與教練可以分配。超過這個量，品質不會突然崩壞，而是慢慢侵蝕。更多工作需要返工、決策被重啟、職責變模糊、經理變得反應式、團隊等太久才得到回應，或乾脆放棄詢問。

通常的回應是變得更有效率。更短的會議、更多授權、更乾淨的流程，以及保護專注時間。這些都有幫助，但也有限。效率能換回時間，但無法讓你免除「決定判斷力最該用在哪裡」的責任。

更好的起點是認真檢視自己的監督負載。

問問自己：哪些決策真的需要你？哪些審查只是出於習慣？你在哪裡只是在重複已經足夠好的工程師的判斷？哪些核准真正創造安全，哪些只製造延遲？你在哪裡仍然是後盾，只是因為沒有人把職責說清楚？

然後有意識地卸下負載。取消低價值的核准。把職責推到它該在的位置。請資深工程師負責整個問題領域，而非零散的任務。寫下決策規則，讓例行性的詢問不再找你。把重複的狀態檢查換成更好的運作訊號。清楚說明哪些風險需要升級，哪些應該由團隊自行處理。

重點不是抽身，而是把注意力留給真正能改變結果的地方。

一個具體做法是畫出決策邊界。工程師可以在不經你審查的情況下做出本地實作決策；技術主管在你同意的架構限制內擁有設計決策；當決策影響到範疇、人員配置、可靠性、客戶承諾或另一個團隊時，才會找你；當權衡影響到組織優先事項或需要你無法控制的資源時，才會找主管。

這些邊界不會完美，也不需要完美。它們的任務是消除不必要的升級，讓剩下的升級更清晰。

協商而非吸收

許多經理默默吞下這些張力，因為把它們說出來感覺像承認自己跟不上。但這不是那樣。這是在限制下進行領導，而這才是真正的工作。

與主管的對話不應該聽起來像認輸，而應該聽起來像一起在解決設計問題：「我們的範疇在成長，但對教練、技術深度與組織領導的期望保持不變。這些無法同時擴張。讓我們一起決定要刻意做出哪些權衡。」

這個重新框架很重要。你不是在尋求同情，而是在幫助組織做出更好的選擇。

好的經理主管可能無法立刻解除壓力，但他們可以澄清優先順序、調低互相衝突的要求，並停止用兩個互相矛盾的目標來衡量你。

對團隊也一樣。從某些決策中退一步？說出原因。保護更多時間來教練？說出什麼事情會得到較少的你。請資深工程師承擔更多技術判斷？清楚說明他們在哪裡擁有權限，以及你還希望在哪些地方被通知。

人們處理權衡的能力，遠勝過處理模糊。挫折通常不是來自權衡本身，而是太晚才發現大家假設的權衡不一樣。

如何開始

你不需要重新設計整個工作就能開始。挑選一個你已經在做、但從未說出口的權衡。把它寫成一句話：「這個季度我會最佳化 ___，這代表我會刻意減少對 ___ 的注意力。」

例如：「這個季度我會最佳化更廣泛的組織對齊，這代表我會減少參與例行的專案狀態追蹤。」

或者：「這個季度我會最佳化教練我們的新技術主管，這代表除非觸及我們事先約定的升級界線，否則我會從某些設計討論中退一步。」

然後測試它。帶給你的主管與團隊，並問：「如果這是真的，會出什麼問題？」他們的回答會告訴你這個權衡是可行的、被誤解的，還是真的有風險。

每個月花一點時間回答四個問題：

  • 我現在正在最佳化什麼？
  • 因為這個選擇，什麼事情被忽略了？
  • 這個忽略是刻意的還是意外的？
  • 誰需要知道？

這樣你就能避免讓角色完全被最吵的壓力所塑造。

未來的工程經理

隨著工作持續擴張，工程經理被要求教練更多人、監督更多系統、參與更多決策，並影響更多組織——前提是這些職責可以同時成長。但它們無法同時成長。領導力容量是有限的，而你的注意力已經有某些部分被減少了。

做得好的經理，不是那些永遠吸收所有新期望的人，而是那些理解自己的注意力最有價值的地方、把這些選擇清楚呈現，並推動組織刻意做出決定，而不是太晚才發現的人。