前言#

管理經理（managing managers）的工作期望，與管理多個團隊其實相去不遠——你負責多個團隊、監督它們的健康狀態、協助設定目標。差異在於規模。你的覆蓋範圍變大了，專案和人數遠超過你能獨自處理的範圍。你可能不再只管幾個密切相關的團隊，而是管理更大範圍的工作，甚至管理你從未涉足、缺乏專業知識的職能——例如，一位軟體工程經理現在也要管理部門內的維運團隊。

管理多個團隊已經夠累人，但管理經理帶來的是一個全新層次的複雜度，而且常常讓人措手不及。作者曾寫信給自己的領導教練：

作者的困惑： 管理經理，我該怎麼做才不會把所有時間都花在上面？我應該建立什麼流程才能從他們身上獲得適當的溝通、並讓自己能擴展規模？你如何幫忙處理那些你不在現場才看得到的問題、又有不可靠的證人？我把所有時間都花在深入兩層的人員問題上，真的累壞了。

答案比以前更不在你的掌握之中。一切都被多了一層抽象所遮蔽，你很容易錯過細節，因為你不再與每個團隊的每位工程師有定期互動。

這是一個艱難的成長關卡。你會被多方拉扯，搞清楚如何分配時間以最大化對團隊的槓桿效應（leverage）至關重要。你需要練習磨練自己的直覺——追蹤那些你不確定是否重要、但就是感覺不對勁的事情。

以管理一個超出你技能範圍的團隊為例。你很容易放手讓他們自行運作，只在出問題時才介入。但作為這個角色的新手，你大概要到問題嚴重時才會察覺。你還沒建立起讓自己能直覺感知何時該深入的紀律或本能，所以你需要更頻繁地深入，即使一切看起來都很順利。

在這個層級工作，你會對自己的優缺點有全新的認識。有些人善於管理單一團隊甚至幾個相關團隊，但在管理經理或超出自身技能的團隊時就崩潰了。他們無法平衡新角色中固有的模糊性，退回到自己覺得容易的事情上——有時表現為花太多時間當個別貢獻者（IC），有時表現為充當專案經理而不是訓練他們的經理去做這份工作。

這是一個全新的遊戲，需要與直接管理團隊不同層次的紀律。你需要追蹤所有小事，直到搞清楚哪些不需要追蹤：招募進行了嗎？你的經理有在輔導團隊嗎？大家都寫了季度目標嗎？你審查了嗎？那個應該收尾的專案狀態如何？前幾天的生產事故——事後檢討做了嗎？你讀了報告嗎？

這個職位是進入高階領導層（senior leadership）和上層管理（upper management）的入口，需要大量新技能。本章討論的主題包括：

• 如何從 skip-level 部屬獲取資訊
• 如何要求經理負起責任
• 管理新手經理與資深經理
• 聘用新經理
• 找出組織失能的根源
• 培養團隊的技術策略

Open-Door Policy 的謬誤#

Skip-Level 會議#

Skip-level 會議是管理多層組織的關鍵工具之一，但很多人忽略或低估它們。沒人想在行事曆上再加更多會議，尤其是那種通常沒有議程的會議。然而，如果你想建立一支強大的管理團隊，理解向你的經理匯報的人、並與他們維持關係，是無法迴避的。

Skip-level 會議就是與向你的直屬部屬匯報的人進行的會議。其目的是幫助你了解團隊的健康狀態和焦點。

形式一：季度一對一#

組織負責人與組織中每個人進行簡短的一對一會議，大約每季一次。這個做法有幾個好處：

• 在你和組織中每個人之間建立至少表面的個人關係，避免你把他們視為「資源」而非活生生的人
• 讓那些人有時間問你一些他們覺得不值得自己專門約會議來問的問題

這種會議在你提供潛在話題的提示時最為成功，並提醒對方這個會議主要是為他們的利益而設。建議的提示問題：

• 你目前的專案中，最喜歡和最不喜歡什麼？
• 你團隊中誰最近表現特別好？
• 對你的經理有任何回饋嗎——什麼做得好、什麼做得不好？
• 你認為我們可以對產品做什麼改變？
• 有沒有我們可能錯過的機會？
• 你覺得整個組織的運作如何？有什麼可以做得更好/更多/更少的？
• 有沒有任何業務策略你不太理解的地方？
• 目前什麼阻礙你發揮最佳表現？
• 在公司工作你有多開心（或不開心）？
• 我們可以做什麼讓在公司工作更有趣？

注意： 一對一 skip-level 的擴展性有限。假設一季有 60 個工作天，組織有 60 人，每季每人一次意味著每天一場，12 週內每週五場。組織到 1,000 人時你就只能做這件事了。但如果組織較小，每季對每個人投入時間確實有其價值。

形式二：團隊午餐#

如果組織較大，或你對增加更多非結構化 1-1 不太有耐心，可以用其他方式取得 skip-level 時間。例如，為整個團隊買午餐，一起聊聊正在發生的事情，每季每個團隊做幾次。

這種方式有 1-1 的許多好處——讓你對團隊成員更熟悉、反之亦然。雖然無法像 1-1 那樣深入地做個人職涯輔導，但能幫助你了解團體動態，直接從團隊獲得回饋。

當然，人們在團體場合的表現不同。當你是大老闆時，他們可能不會在別人面前抱怨對經理的不滿。許多午餐可能只是聊些隨意的技術話題，但你可以從中感受團隊認為他們的焦點應該在哪裡，也能回答一些關於公司策略方向、其他部門工作、或即將到來的專案的詳細問題。

在團體場合，可以用這些問題來引出資訊：

• 作為你經理的經理，我能為你或你的團隊提供什麼？有什麼我應該幫忙的？
• 從你的角度來看，這個團隊與其他團隊的合作有問題嗎？
• 有沒有任何關於更大組織的問題我可以回答？

Skip-Level 的核心目的#

Skip-level 的目的不只是維持信任和參與感，更重要的是幫助你偵測哪些地方你正被**「向上管理」**（managed up），而這對該經理底下的團隊是不利的。

善於 managing up 的人總是難以偵測和應對——他們先到你面前，所以你先聽到他們的觀點，天然會認為他們是對的、支持他們的決定。Skip-level 會議是聽到故事另一面的機會，是從第一線人員那裡得到現實查核（reality check）的機會。

重點： 即使你與 skip-level 部屬已經很熟，也不要低估這個流程。僅僅因為你曾經直接管理他們，並不保證你會保持緊密聯繫。隨著團隊慢慢改變，關係也在改變。即使團隊成員沒有變動，他們也不會總是主動來找你談他們對經理的問題。

經理的當責性#

無論你管理的是資深經理還是新手，有一個共通的目標：他們應該讓你的工作更輕鬆。你的經理應該讓你能花更多時間在大局上，減少花在任何一個團隊細節上的時間。他們不只是幫你分擔一些 1-1 會議的人——他們負責帶領一個團隊走向成功。當他們反覆做不到這一點時，就是在做不好自己的工作。

然而，有時候經理讓你的工作變輕鬆的方式，是隱藏問題、告訴你你想聽的話，直到幾個月後你看到事情在崩潰。所以你不能只是期望他們能神奇地讓事情變好——你必須要求他們負責（hold them accountable）。學會如何要求經理負責，將是你在這個層級最大的學習機會之一。

棘手但常見的情境#

不穩定的產品路線圖

團隊感覺不太有生產力，系統不穩定，有些人在離職，但產品組織不斷改變團隊的目標，所有事情都是緊急的。經理該負責嗎？

脫軌的 Tech Lead

Tech Lead 掉進了一個兔子洞，試圖重新設計核心系統。設計文件才剛開始，工作堆積如山，但 Tech Lead 堅持這是不能急的大問題。經理該負責嗎？

全職救火模式

經理接手了一個充滿 legacy 系統的團隊，系統不斷壞掉，團隊整天在滅火。他們還要支援使用這些系統的其他團隊。雖然有遷移路線圖，但你沒聽到任何進度報告。經理該負責嗎？

答案是：全部都是。 儘管每個案例都有減輕情節，經理最終需要為把團隊從這些情境中拉出來、讓團隊向前邁進負責，因為經理對團隊的健康和生產力負有責任：

• 當產品組織不斷改目標時，經理應識別出這些變動對團隊造成的問題，與產品部門溝通，重新聚焦重要事項。如果這不奏效，應該來找你幫忙解決
• 當 Tech Lead 掉進兔子洞時，經理必須把他拉出來，協助他讓設計過程更透明，必要時引入其他團隊的資深人員做導師或合作者
• 經理有責任在路線圖因其他問題而停滯時主動告知你。如果團隊只能救火，經理應制定計畫處理火源，並在必要時請求增加人手

在許多這些情況中，你需要幫助你的經理。他們可能沒有足夠的影響力來推回產品的需求，需要你的支持。他們可能需要你幫忙找其他資深人員來搭配他們的 Tech Lead。他們做了辨識問題的辛苦工作，但你需要幫忙找到解決方案或支持他們前進。這就是讓你的工作變輕鬆的真正含義——不是隱藏資訊，而是在問題變成熊熊大火之前帶來清晰的問題。

技巧： 經理和個別貢獻者一樣需要輔導和指引。別忘了花時間與你的經理相處、了解他們、注意他們的長處和發展領域。1-1 中有很多與排程和計畫相關的話題，但也要騰出時間給回饋和輔導。這些人對你整體組織的成敗有最大的影響。

Good Manager, Bad Manager：討好型經理#

Marcus 是一個討好型經理（people pleaser）。他對於直接讓他在乎的人不開心有深深的厭惡。如果你在他在乎的群體中向他提出要求，他總是說好，即使事情太多、他不可能全部處理。討好型經理試圖讓所有人開心，最終常常把自己燒盡（burn out）。

討好型經理的警訊#

• 團隊喜歡她這個人，但越來越對她作為經理感到沮喪，因為她隱藏問題、試圖屏蔽外部世界
• 更在乎團隊順利運作、避免犯錯，而非推動團隊追求卓越
• 心情不好時寫在臉上，讓整個團隊失去信心
• 從不推回工作，但總有大量未完成的任務和藉口
• 過度承諾、交付不足（overpromise and underdeliver），且似乎無法從經驗中學會少承諾一些
• 對所有人說好，對團隊和外部夥伴發送矛盾訊息，造成廣泛的混亂
• 似乎知道公司裡發生的所有問題，但沒有直接處理其中任何一個

兩種類型的討好型經理#

團隊討好型（Team Pleaser）： 像 Marcus 一樣，花大量時間與人相處，想要與你的情緒互動，確保你開心。這種「治療師型」經理能因為願意傾聽而激發巨大的忠誠，但可能放大戲劇性與負面情緒，並做出無法兌現的承諾而令團隊失望。

外部討好型（External Pleaser）： 非常想讓老闆和外部合作夥伴開心，害怕暴露團隊的問題。花大量精力 managing up 和 managing out，特別傾向於大幅過度承諾（overcommit）團隊。儘管想要討好人，卻經常不對團隊提供太多讚賞或回饋——因為她在內部迴避困難對話，這實際上可能導致既不承認好的工作也不處理問題。她永遠不會主動向經理分享問題，並且對任何進來的專案需求都欣然同意。

兩者的共同問題#

兩種類型都難以說不，對團隊和外部發送矛盾訊息。你可能認為討好型經理會創造一個可以安全地脆弱和失敗的環境，但事實恰恰相反——由於經理自身對失敗和被拒絕的恐懼，團隊反而無法以健康的方式失敗。

• 外部討好型透過迴避和情緒操控來關閉誠實對話
• 團隊討好型透過做出不切實際的承諾讓團隊失敗，團隊最終對經理或公司感到極度苦澀

如何處理討好型經理#

• 幫助他感到說不的安全感，將更多決策外化（externalize），讓他不把失敗看作個人的
• 提供強大的合作夥伴來承擔決定工作路線圖的任務
• 討好型經理有時在 agile 框架中運作良好，因為團隊本身承擔工作規劃的所有權
• 建立不完全依賴經理自由裁量的排程和晉升流程
• 最重要的是：讓他意識到自己的行為模式，並強調其負面影響。認知到這通常源於無私和關心他人的個人價值觀，在糾正不健康行為的同時尊重這些價值觀

管理新手經理#

管理對工程師來說是一次職涯轉變，所以新手經理需要大量輔導毫不意外。正如你自己第一次管理團隊時的經歷——你不知道自己不知道什麼。你可能模仿了以前好經理對你做的事情（如果你有好經理的話），或者就是跌跌撞撞地摸索過來。

在新手經理身上花高品質的時間很重要，你應該把這視為前期投資，長期回報。你可能以為有人際技巧的新經理自然就能勝任，新經理本人可能也這麼認為。但你知道當好經理需要一系列技能，即使人際能力紮實也需要訓練。

新手經理的常見問題#

不做管理工作

當你聘用或提拔一位新經理時，你往往急於完全放手讓她接管團隊。但新經理可能對基本功都很生疏。例如，進行 1-1 第一次做會很不安——聊什麼？怎麼給回饋？怎麼追蹤待辦事項？沒有任何書籍或訓練能替代你花時間問問新經理她的 1-1 進行得如何。有時候，你只需要提醒她要舉行 1-1！

當新經理忽略管理工作、在太多管理細節上疏忽時，她的團隊開始受苦，也意味著你開始受苦。當人們因為經理沒有給他們職涯路徑或沒有激勵他們而離職時，最終是你的責任。利用 skip-level 會議來偵測需要支持新經理的地方，並讓她知道你會頻繁地進行 skip-level 來協助引導她。

過度工作

新手經理的一個常見掙扎信號就是過度工作。一個總是在加班的新經理，很可能是未能把舊的職責交接給團隊其他人，試圖同時做兩份工作。一開始忙一些是正常的，但如果她早來晚走、週末回信，就有問題了。很多人從未真正學會放手任務，於是工時越來越長。明確表達你期望新經理移交部分舊工作，並幫她找到這樣做的機會。

權力狂經理

過度工作有時也是另一種新手經理危險的信號：認為自己現在「掌控了一切」的人。覺得管理是實現權威的關鍵而充滿幹勁的經理可能更糟。權力狂（control freak）奪走團隊做決定的能力，把工作視為分配特定任務給特定人來完成。他們通常與產品管理和其他技術團隊的同儕關係不好，因為他們經常獨自做決定而非協作。更糟的是，權力狂經常想對經理隱瞞自己在做什麼，怕控制權被拿走。如果你的新經理在跳過你的 1-1 或迴避團隊在做什麼的問題，你可能碰上了權力狂。

注意： 這與微管理（micromanager）略有不同但相關。微管理者透過要求團隊每位成員隨時提供不必要的細節報告來煩死團隊；而權力狂則是奪走團隊做任何決定的能力，把工作視為指派具體任務。

未能為交付負責

你訓練的新經理最終應該讓你的工作更輕鬆，而不只是把一堆 1-1 會議從你肩上卸下。她還需要掌握團隊的績效和交付，引導他們聚焦目標、產出成果。有時新經理沒有意識到她現在要為交付負責，認為自己面對挑戰性目標或產品路線圖時無能為力。清楚地在一開始就設定期望——你會讓她為團隊負責——並幫助她建立實現目標的技能。

何時需要採取行動#

新手經理很棘手。如果他們真的沒有學習的意願和成為好經理的資質，那就是個大問題。讓錯的人當經理是一個失誤，但在你意識到她不適合後還讓她留在那個位置上就是嚴重的錯誤。作者強烈建議讓想走管理路線的工程師先從導師和管理很小的團隊做起，但這不一定可行，也不一定能在規模出現的問題被暴露出來。例如，權力狂經理在較小的管理情境中通常不會明顯表現出來。

重點： 密切關注你的新手經理。你可能不只需要提供輔導，更需要在前六個月內給出強力的糾正回饋。此外，尋求外部訓練資源——如果 HR 有新手經理課程，確保你的經理有時間參加。也可以尋找公司外部的培訓機會，例如專注於技術領導力的研討會。

管理資深經理#

資深經理帶來截然不同的挑戰。合適的資深經理知道該做什麼，不需要你的幫助就能完成。他熟悉基本功，甚至有自己的獨特技巧。

文化適配的重要性#

管理在公司中往往是高度文化特定的任務。無論最佳實踐說什麼，如果經理與公司的文化不合，就會出問題。這就是為什麼許多年輕公司想用從早期就在的人來填充管理團隊——他們理解公司的 DNA、深知什麼重要、已經建立了完成工作的內部人脈。

經理會創造子文化（subculture），一個創造不相容子文化的經理會讓團隊之間的協作出現問題。例如，你可能因為某人有建立特定類型產品的專業知識而聘用他，但往往我們過度看重產品領域的專業而忽略了文化和流程的適配。一個有深厚企業級倉儲軟體經驗的人，在你的物流新創的敏捷、駐點團隊中，如果他習慣的是每六個月出一次貨、只與不參與產品發想的遠端開發團隊合作，可能就不太合適。

重點： 如果你正在建立一個動態的、以產品為中心的工程團隊，你需要懂得如何與頻繁發佈軟體的團隊合作、熟悉現代開發流程最佳實踐、能激勵有創造力的產品型工程師的經理。這些技能遠比行業特定知識重要得多。別在文化適配上妥協，尤其是在聘用經理時。

與資深經理協作#

資深經理會有與你不同的管理理念，你需要磨合這些差異。但磨合不等於讓經理想怎麼做就怎麼做。即使他的經驗比你多，也要願意向他學習，但也不要害怕提供你自己的回饋。在差異之處合作，讓他教你一些東西，同時在過程中保持積極的參與。

你有責任培養組織的文化。如果你要求透明的團隊，確保經理分享資訊。如果你鼓勵探索，確保經理為團隊安排探索想法的時間和空間。思考你的文化看重什麼，幫助經理體現那些價值，同時尊重每個團隊會有些許不同，每位經理都有需要考慮的長處和短處。

如何激勵資深經理#

資深經理與新手經理的差別在於，資深人士應該能夠獨立管理。因此你提供的輔導將更少是關於管理的基本功，更多是關於他如何在策略和方向設定上發揮更大的影響力。別忘了思考可以委派給他的任務，他應該是你在設定組織方向時的重要顧問。雖然他們可能不需要像新手經理那樣多的訓練，但資深經理通常需要幫助擴展他們在公司內外的人脈，所以尋找能幫他們結識新同儕的機會。

聘用經理#

假設你的組織在掙扎——你招了 10 個工程師，每個都不到 3 年經驗，而現有可能合適的工程師沒人想轉管理，即使有也缺乏經驗、需要大量訓練。於是你決定從外部聘用一位新經理。但怎麼做？

很多人非常不願意從外部聘管理職，理由充分——我們連判斷一位工程師能否在團隊中好好寫程式都很勉強，至少寫程式還能讓人展示。管理是……什麼？怎麼面試？要注意什麼？

面試管理者的技能#

聘用經理是多部分的工作，其實與好的工程師面試流程很相似：首先確保這個人有你需要的技能，其次確保她的文化適配。

管理面試與工程面試最大的差別是，經理理論上更容易說大話（bullshit）。但工程師面試寫程式寫得好的人也可能進了團隊什麼都做不出來。把你對聘用後會發生什麼的恐懼，與你在面試中要評估的東西分開。

1-1 角色扮演

任何你聘的經理都應該在面試過程中角色扮演幾次 1-1。最好的方式是讓即將成為新經理部屬的人來面試她——請他們用自己目前或最近遇到的問題，讓候選人嘗試幫忙。一個好經理——即使不完全了解相關的人或專案——應該有好的直覺，知道該問什麼問題、建議什麼下一步。你也可以進一步角色扮演其他困難情境，例如處理績效不佳的員工或傳達負面績效評估。

團隊除錯能力

經理還必須能夠 debug 團隊。請候選人描述她曾經主導過一個進度落後的專案，以及她在那種情境下做了什麼。或者請她角色扮演與一位正在考慮離職的員工對話。問她如何輔導掙扎中的員工、如何幫助優秀員工成長到新的層次。

管理哲學

問她的管理哲學。如果她完全沒有，這可能是一個紅旗。新手經理可能回答不好這個問題，但一位資深經理如果沒有清晰的哲學就令人擔憂。她認為經理的工作是什麼？她如何保持 hands-on？如何委派？

簡報能力

根據資歷，你可能讓候選人對一群人做一次簡報。重點不是評判簡報內容，而是看她掌控場面的能力——回答提問、結構化思維、站在觀眾面前。但不要過度看重這一步，因為很多優秀的經理在面對陌生觀眾時會不自在。

技術能力

確保你對候選人的技術能力有足夠了解，讓她能在要管理的團隊中建立信譽。如果她需要寫程式，給她一個縮短版的標準技術面試。對於不寫程式的經理，根據經驗問技術問題——設計和架構問題是好的方式，確保她能討論做出的取捨和原因。你也可以讓她在兩位意見不同的工程師之間調解技術辯論。

文化適配的篩選#

文化適配在管理聘用中格外重要。你是否曾與一位不理解公司文化的經理共事？例如從大公司來的人不接受新創的速度和非正式性，或從新創來的人不知道如何在大公司取得共識。

首先你需要理解周圍公司的價值觀：

• 組織是非正式的、不太依賴層級，還是層級被非常重視？兩種文化都會讓習慣另一種的人出問題
• 你重視僕人式領導（servant leadership），卻聘了一個想對團隊下達精確行軍命令的經理，就會不合
• 你重視協作，卻聘了一個認為每次對話中聲音最大的人應該贏的經理，也會出問題

注意： 文化適配在經理身上格外重要，因為他們會把團隊塑造成自己的文化，並根據自己的文化理念聘人。如果你聘的經理與她管理的團隊在文化上不合，兩種結果都可能發生：經理失敗然後你得開除她，或者大部分團隊離職然後你可能還是得開除她。

Reference Check 的重要性#

不要遺漏推薦人查核（reference check）。即使你以前跟那個人合作過，也要做徹底的 reference check。問推薦人描述這個人成功和失敗的方式、是否願意再次與她或為她工作、喜歡她什麼、什麼讓他們抓狂。即使是候選人精心挑選的推薦人，也常常透露出很多關於聘用後會怎樣的資訊。

除錯失能的組織#

作者認為最好的工程經理往往是出色的除錯者（debugger）。為什麼？因為這兩個任務有高度重疊的技能組合。

一位優秀的除錯者會不懈地追尋 bug 的「why」。這在尋找應用邏輯錯誤時很簡單，但在涉及多個獨立部分透過延遲網路運作的複雜系統中，bug 可能深藏好幾層。糟糕的除錯者在並行程式碼中加了一行日誌語句後發現錯誤無法重現，就假設問題已經修好了——這是懶惰的習慣，但很常見。

管理團隊是一系列複雜黑箱與其他複雜黑箱的互動。這些黑箱有可以觀察的輸入和輸出，但當輸出不如預期時，要弄清楚原因就需要打開它們看看裡面發生了什麼。而且就像有時候你沒有原始碼、或原始碼是你不懂的語言、或日誌不可讀一樣——團隊這個黑箱也可能抗拒透露其內部運作。

範例：一個感覺很慢的團隊#

假設你有一個感覺很慢的團隊。你聽到他們的業務夥伴和產品經理抱怨他們慢，你也同意這個團隊就是缺乏其他團隊的那種活力。你該怎麼做？

步驟一：建立假設#

要正確除錯一個系統，你需要一個合理的假設來解釋系統如何進入失敗狀態。要除錯一個團隊，你也需要一個關於為什麼團隊有問題的假設。盡可能以最小侵入性的方式做這件事，以防你的干預遮蔽了問題。團隊問題通常不是單一故障，更像是效能問題——系統在運作，但偶爾變慢；機器都正常，但偶爾當機；人們看起來開心，但離職率太高。

步驟二：檢查數據#

除錯團隊和除錯嚴重的系統問題一樣需要嚴謹。查看記錄——團隊的聊天和郵件、工單、程式碼審查和提交。你看到了什麼？

• 生產事故頻繁，佔用大量時間？
• 很多人在請病假？
• 他們在 code review 中爭論程式風格？
• 工單寫得模糊、太大還是太小？
• 團隊在溝通風格上是否活潑、除了重要工作也會分享有趣的東西，還是純粹公事公辦？
• 查看他們的行事曆——團隊每週花很多小時開會嗎？經理有沒有在做 1-1？

這些東西都不一定是決定性證據，但可能指向需要關注的方向。

步驟三：觀察團隊#

如果所有指標看起來都正常但團隊表現仍然不如預期，就要開始做一些潛在破壞性的調查。坐進他們的會議：

• 會議無聊嗎？團隊覺得無聊嗎？
• 大部分時間是誰在說話？
• 是否有定期的全團隊會議，絕大部分時間都在聽經理或產品負責人講話？

無聊的會議是一種信號。 它們可能代表規劃效率低下、會議太多、團隊成員覺得自己無法幫助設定方向或選擇要做的工作。它們通常顯示團隊中缺乏健康的衝突。好的會議有大量討論元素，從團隊中引出意見和想法。如果會議過度腳本化以至於沒有真正的對話空間、如果人們害怕表達異議、或者經理總是壓制衝突而不讓分歧被表達，這是不健康團隊文化的信號。

補充： 要注意觀察者效應——就像薛丁格的箱子一樣，你無法進入一個團隊而不改變該團隊的行為。你的存在會改變團隊的行為，可能隱藏你正試圖找的問題，就像一行日誌語句可能讓並行問題神奇地消失一樣。

步驟四：提問#

問團隊他們的目標是什麼。他們能告訴你嗎？他們理解為什麼那些是目標嗎？如果他們不理解工作的目標，他們的領導者（經理、tech lead、產品經理）就沒有做好讓團隊參與工作目的的工作。

在幾乎所有的動機模型中，人們需要感到對工作目的的理解和連結——他們為誰建造這些系統、對客戶、業務、團隊的潛在影響是什麼？他們有參與決定這些目標和專案嗎？如果沒有，為什麼？

當你看到一個團隊把所有時間花在工程主導的專案上而忽視產品/業務專案，很可能是因為團隊不理解或不欣賞產品/業務專案的價值，因此缺乏動力去做。

步驟五：檢查團隊動態#

看看實際的團隊動態：

• 人們喜歡彼此嗎？他們友善嗎？
• 他們在專案上協作，還是每個人都在做獨立的事情？
• 聊天室、郵件中有沒有閒聊？
• 他們與相鄰部門和產品經理有良好的工作關係嗎？

即使是非常專業的團隊也傾向於成員之間有一定程度的個人連結。一群從不互相交談、總是做獨立專案的人，不是真正作為一個團隊在工作。

步驟六：主動跳進去幫忙#

有些管理經理的人選擇把這類問題當作團隊經理「應該自己修好」的事。你確實以團隊的產出來衡量經理，修好問題是他的責任。但就像作者有時候會跳進去幫忙除錯複雜的系統故障一樣（即使她很少寫程式），跳進去幫忙除錯團隊問題是 OK 的，特別是當經理在掙扎時。這可以是教導經理、幫助他成長的機會，也可能揭示更根本的組織問題，例如缺乏資深業務領導力——這是即使最好的經理也無法獨自識別或解決的。

保持好奇心#

對組織問題追問「why」，是幫助你建立模式匹配能力和領導經驗的關鍵。我們透過經常做除錯來變得更好，學會哪些區域最先出問題、哪些指標對理解問題最有價值。沒有追問 why 的動力，我們就只能靠魅力和運氣度過管理生涯，在真正從錯誤中學習這件事上有巨大的盲點。

設定期望與如期交付#

工程經理最常被問到的一個令人沮喪的問題是：「為什麼這東西花這麼久？」 作為 hands-on 工程師、tech lead、小團隊經理都曾被問過，但當你管理團隊經理時，這個問題的強度升到全新的層次，因為當你不再深入嵌入細節時，回答它顯著更難。

關於估算#

理想情況下，這個問題是因為某件事大幅超出計畫才被問到。但很多時候，你被問這個問題時，其實並沒有比估計更慢——領導層不喜歡原始估計，或者根本沒要求估計，現在不開心了，但什麼都沒出錯。

因此你必須積極主動地分享估計和估計更新，即使沒人問——特別是當你認為專案是關鍵的或可能超過幾週時。這意味著你必須積極地取得估計。而我們都知道，軟體估算是一個非常困難的過程。協商你的團隊使用什麼流程來估算、在什麼時間尺度上、對哪些專案，可能是你在這個層級工作的一部分。

工程師通常不想估算，或只估到 agile sprint（通常兩週）的範圍。如果你相信估計必須相當準確、需求未知或會頻繁變化、大部分工作應限於一到兩個 sprint 內的功能，這種哲學完全合理。但這些條件很少全部成立：

• 估計即使不完美也很有用，因為它們幫助向團隊其他人呈現複雜度
• 不是每個專案的需求都會頻繁變化
• 可以做前期工作來大幅減少讓軟體估算困難的未知數
• 我們不只在談論工程團隊——企業想要規劃和了解投入的成本
• 我們也在談論目標設定和學習如何更好地理解軟體和系統的複雜度

所以，接受你需要做某種程度的估算。嘗試不同的方法，看看什麼適合你的公司，但讓它成為所有團隊的習慣。

從估算錯誤中學習#

Agile 軟體開發的一個核心元素是強調從過去學習。當估計錯誤時：

• 我們對未知複雜度學到了什麼？
• 我們學到了什麼值得估算、什麼時候估算？
• 我們學到了如何溝通那些估計、誰對失誤感到失望？

你的工作是盡可能清楚地說明「多久」到底是多久——提供你對專案時程的最佳看法，並在它變化時主動更新，尤其是當它變慢時。

當壓力無法避免時#

即使你已經清楚說明了時程、並沒有超出進度、或完全不在你控制範圍內的事情導致了充分溝通過的延遲——有時你還是會被質問。這通常是因為有人感到壓力或被要求比你宣稱的更快地交付。沒有簡單的答案。有時候耐心地提醒對方一切都在按時進行是唯一的解決方案。但責怪通常不是完全理性的行為。對施壓的人表達一些同理心，願意以其他方式幫忙，可以有效地把焦點從責怪轉向行動。

最後，不要害怕與你的經理、tech lead 和業務方合作，在專案尾聲縮減範圍（cut scope）以趕上重要的截止日期。作為資深經理，你可能需要扮演決斷者（tiebreaker），決定哪些功能值得刪減、哪些對專案成功至關重要。

技巧： 對你願意放棄的東西要聰明。如果你只在技術品質上讓步，專案上線後只會讓團隊更慢。確保同時檢視產品功能和技術 nice-to-have，在兩者之間取得平衡。

挑戰性情境：路線圖的不確定性#

各層級的經理都面臨的一個常見問題是不斷變化的產品和業務路線圖。特別是在較小的公司，很難讓人提前一年承諾接下來要做什麼。即使在大公司，市場變化也可能導致看似突然的策略轉變，讓專案被放棄、計畫中的工作被取消。

這對工程經理來說很痛苦。策略變更是「卡在中間管理層」感覺最不舒服的地方——你可能幾乎無力推回來自上方的策略變更，即使你已經向團隊承諾了某些專案，有時候也得食言。這讓團隊不開心，他們向你抱怨，而你什麼都做不了，會覺得自己的無力被暴露了，團隊可能覺得自己不是被當人看，而是企業機器中的齒輪。

還有一個次要挑戰：當沒有明確的流程來排定技術債和其他工程導向的專案時，如何為它們騰出時間？如果你不投入時間處理技術問題，團隊做產品功能的能力會變慢。但產品團隊的路線圖上永遠不會有技術債，所以規劃過程往往沒有為這類工作分配時間。

應對路線圖不確定性的策略#

對計畫變更保持務實

根據你所在公司的規模和階段，對改變計畫的可能性保持務實。如果你的新創每年夏天都會因上半年的業績結果而改變年度計畫，就為夏天的變動做準備，不要向團隊承諾需要超過那個時點的連續性。

把大專案拆成小交付物

將大專案拆解為一系列較小的交付物，這樣即使你不一定完成宏大願景，也能達成部分成果。拆解技術工作需要你與產品或業務經理密切合作，弄清楚如何排定細節的優先順序。所有人現在都應該知道事情會快速變化，所以一切都必須反覆檢視——著眼於現在最有價值的是什麼。

不要過度承諾未來的技術專案

不要向團隊承諾「以後」會有令人興奮的技術專案——因為「以後」的產品路線圖還沒寫出來。這種想法會燃起希望然後令人失望。如果專案重要，現在就排進去——或盡可能接近現在。如果專案不是急迫重要，可以放進 backlog，但要務實地認識到，當「以後」來臨時會有一長串來自業務其他部門的競爭優先事項。

保留 20% 的時間給「維持性工程」

為重構、修復未解決的 bug、改善工程流程、小型清理和持續性支援保留 20% 的團隊排程。在每次規劃會議中考慮這一點。20% 不足以做大型專案，所以主要的技術重寫或重大技術改善需要額外的規劃。但沒有這 20% 的時間，會導致交付目標失誤以及計畫外的不愉快清理工作。

理解工程專案的真正重要性

產品和業務專案通常有價值主張來為自己辯護，但同樣的嚴謹不一定被應用在技術專案上。當工程師帶來一個想做的工程專案時，思考這些問題來框定它：

• 專案有多大？
• 有多重要？
• 你能向任何詢問的人清楚說明這個專案的價值嗎？
• 成功完成這個專案對團隊意味著什麼？

這些問題的價值在於，你開始用與產品計畫相同的方式對待大型技術專案——有倡議者和目標、有時程、像其他大型計畫一樣被管理。

補充： 這個過程可能令人恐懼，因為有時你「知道」某件事很重要，但不知道如何用業務能理解的方式表述。盡力收集數據支持自己，談論完成這項工作後什麼將變為可能。如果你看一個技術專案，發現你在為一個很少被修改的系統提議一堆工作，而且它不會帶來核心的技術或業務改善，那可能不值得投入。

面對變化的心態#

回到不確定的路線圖：專案會改變，團隊甚至可能被解散或以你不理解或不同意的方式重組。作為經理，你能做的最好的事是幫助人們感到有能力收尾、穩定當前進行中的專案、以受控的方式過渡到新工作。在這個領域你可以也應該推回——確保你的團隊有足夠的時間完成當前的工作。此外，推動讓工程師參與新工作的早期規劃，讓人們對即將到來的專案感到興奮。

花時間理解變動的原因，即使你不完全同意，也盡力幫團隊理解新目標。你在面對這些變化時越冷靜，越能展現（或假裝）對新方向的熱情，整個團隊的過渡就會越順利。

技巧： 面對浪潮時，你可以選擇被拉下去，或者學會衝浪。

保持技術敏銳度#

經理們常問的一個問題是：「如何保持技術相關性？」 我們知道如果不投資技術技能，就有變得與領域脫節、提前過時的風險。但技術相關性真正為你做了什麼？要回答這個問題，先釐清你的技術責任。

監督技術投資#

系統需要持續的技術工作：新語言、框架、基礎設施、功能。開發時間和精力有限，你有責任確保團隊把技術賭注押在正確的地方。你透過將提議的技術專案和改善與產品或客戶需求的未來進行匹配來監督這些投資。從整個專案組合的宏觀角度，你可以看到最大需求或機會在哪裡，並相應地聚焦團隊的努力。

問有見地的問題#

你不是識別所有技術專案的人。對團隊技術投資負責不代表你親自做研究去找到潛在投資。相反，你透過提問來引導這些投資：

• 當前專案發現了什麼意外或瓶頸？
• 團隊如何思考系統的未來？
• 哪些團隊在要求更多工程師？為什麼他們認為需要更多人？
• 哪些團隊慢但不想增加人來提升產出？
• 他們為什麼現在倡導這個特定專案？

你需要對工作有足夠的了解，才能嗅出方向錯誤的努力並評估提議的投資。

分析並解釋工程與業務的取捨#

透過了解你的團隊對什麼感到興奮、看重什麼，你可以凝聚他們圍繞產品計畫。你知道得足夠多，能在功能想法技術上很困難時提出關切，也能在技術想法有未預見的業務影響時指出。你確保工程師在理解業務觀點和產品路線圖未來的前提下做決策。當技術工作需要不確定的研究開發時，你能向非技術對口解釋為什麼存在這種不確定性。

提出具體要求#

作為 director 級經理，你仍然需要對組織中的技術有足夠的理解，能提出具體要求而不分散資深工程師的注意力。透過了解團隊的進度、專案和瓶頸，你可以過濾掉技術上不可行的想法，並將新計畫對應到正在進行的專案。

注意： 不夠保持技術能力的經理有時會養成充當傳話人的壞習慣——把高層管理的需求轉達給團隊，然後把團隊的回覆轉達回去。這不是一個增值角色。

用你的經驗做直覺檢驗#

這是一份高度技術性的工作，無法由一個不理解和欣賞軟體工程挑戰和取捨的人來做。如果你的團隊把時間投資在錯誤的地方，這會反映出你作為領導者沒有幫助他們做出更好的決策。依靠你的直覺來引導你在哪裡花時間和注意力，不要因為忙於人員和組織挑戰就忽視你的技術直覺。

保持技術敏銳度的實踐方法#

• 閱讀程式碼： 偶爾花時間閱讀系統中的一些程式碼，提醒自己它長什麼樣。有時候也能看到需要關注的醜陋之處。查看 code review 和 pull request 可以讓你了解正在發生的變更
• 選擇一個陌生領域，請工程師向你解釋： 花幾個小時跟一位正在做你不理解的東西的工程師學習。到白板前或共享螢幕，讓他跟你 pair 做一個小改動
• 參加事後檢討（postmortem）： 當故障發生時，優先參加事後檢討。這些會議充滿了你不寫程式時會錯過的關於編寫和部署軟體流程的細節。你以為理所當然的標準被忽略了，團隊間的溝通缺失，工具反而在幫倒忙。失敗時你能最清楚地看到問題在哪裡累積
• 跟上軟體開發流程的業界趨勢： 經理的一大弱點是與開發、測試、部署和監控程式碼的工具和流程脫節。不是每個趨勢都值得追，但騰出時間了解其他團隊如何交付軟體，讓你的團隊能持續進化
• 培養公司外部的技術人脈： 最好的故事來自你信任的人。維持一個工程和工程管理同儕的網路，讓你有人可以諮詢對新趨勢的意見。用這個網路獲取部落格文章、演講和銷售推薦背後的真實體驗
• 永不停止學習： 閱讀技術文章和部落格、觀看演講。挑一個你真正好奇的東西深入研究，即使它與你的團隊或公司無關。不要害怕向你的團隊提問，尋找向他們學習的機會

自我評估#

• 你多常與 skip-level 部屬交談？是一對一還是團體？你如何主動接觸你的團隊？你花多少時間尋找資訊，而非被動處理到手的資訊？你上次坐進團隊會議是什麼時候？
• 不看現有文件，寫下你對向你匯報的工程經理的工作職責的看法。他們負責什麼？你如何評估他們？你認為哪些領域對成功最重要？現在看看公司使用的工作描述——你寫的和那份描述有差異嗎？根據那份描述，你在評估他們時可能忽略了什麼？
• 對他們目前的表現做一個快速的心理檢視。哪些領域需要輔導和發展？在下次 1-1 中騰出時間來涵蓋這些
• 如果你管理一個在你技術舒適區之外的領域，你多常去確認那個領域一切順利？你是否花了一些時間向那個領域的經理學習在那個角色中取得成功需要什麼？過去三個月你學到了什麼新東西來幫助你更好地理解那個團隊？
• 如果你有一個團隊明顯比其他團隊運作得更順暢，你注意到他們的流程有什麼不同？互動方式呢？他們的經理做的事情和其他經理不同嗎？那個團隊如何與經理互動？經理如何與你互動？
• 你的經理面試流程是什麼？你花時間談論候選人的個人價值觀和管理哲學嗎？你讓團隊面試他們的潛在經理，還是把他們排除在流程之外？你花時間做候選人的推薦人查核嗎？
• 你的組織這季的目標是什麼？今年的呢？你如何將產品目標（如果有的話）與技術目標融合？你的組織是否有一個被團隊充分理解的使命？