前言#

歡迎來到多團隊管理的世界。本章討論「管理多團隊」先於「管理管理者」，因為這兩件事雖然相關，但並不必然同時發生。此時你可能已經有 Tech Lead 向你匯報，而同時要直接管理三、四位以上的人，還要理解多個團隊的狀況，這幾乎意味著一件重要的事：你不再寫（多少、任何）production code 了。

作者在前公司建立職涯階梯時，Engineering Director 通常是一個人開始管理多個大型團隊的層級。以下是她為這個角色所定義的職涯描述摘要：

Engineering Director 角色定義：

• 負責技術團隊中一個重要的領域，通常橫跨多個產品領域或多個技術功能。Tech Lead 和 Individual Contributor 都向其匯報
• 不被期望每天寫程式，但負責組織整體的技術能力，透過訓練和招聘來引導和培養團隊的技術水平
• 應具備深厚的技術背景，花部分時間研究新技術並掌握業界趨勢。需要能夠 debug 和 triage 關鍵系統，理解所管理的系統到足以做 code review 和研究問題的程度
• 主要透過擔任「懂技術且會問商業和產品問題」的角色來參與架構與設計，確保程式碼符合產品和商業需求並能隨需求成長而擴展
• 首要關注確保複雜交付項目的順暢執行，持續評估和改進開發/基礎設施標準與流程，以創造為業務帶來持續價值的技術
• 負責建立高效能、高速度的組織，隨著業務成長不斷衡量和迭代流程。是招聘、人數管理與規劃、職涯成長和培訓的領導者
• 影響力應跨越技術組織的多個領域。負責培養下一代領導和管理人才，幫助他們學會平衡技術與人員的領導和管理
• 專注於建立高效能、投入且有動力的組織，並為留任率負責
• 負責在即時的產品/業務導向工作與技術債和策略性技術開發之間取得平衡
• 是跨職能協作的表率，在技術與公司其他領域之間、以及技術內部各部門之間促進合作，目標是創建涵蓋商業需求、效率與營收、以及基礎技術創新的策略性與戰術性技術路線圖
• 是非常強的溝通者，能向非技術夥伴簡化技術概念，也能以激勵和引導的方式向技術團隊解釋業務方向
• 負責引導所有團隊的目標設定流程，幫助團隊制定既支持業務計畫又支持技術和組織品質的目標

不再寫程式的現實#

作者特別強調 Engineering Director 不會每天寫程式，因為她認為一個負責直接管理多團隊的人很難同時寫程式。到了這個階段，你的行程已經從「Maker Schedule」完全轉向「Manager Schedule」。在 1-1、與其他工程主管的會議、團隊規劃會議、以及與產品管理或其他業務夥伴的會議之間，你已經非常忙碌了。對自己的行程要務實——如果你無法保證每週至少有幾天有完整的時間區塊，你寫出的程式碼進度會非常緩慢。

保持技術參與的方式#

即使不寫大量 production code，仍有方法保持 hands-on：

• Code Review：至少作為次要審查者保持參與，特別是你過去建立的系統，你比多數人記得更多細節
• Debugging 和 Production Support：根據你的技能組合而定，如果你過去擅長除錯，可以參與 incident 處理
• Pair Programming 或修復小 bug/功能：這些小努力常被低估，但它們很好地讓你保持對軟體開發感覺的同步，也向團隊展示你願意且有能力幫忙

注意： 如果你在進入管理前沒有花足夠時間寫程式來達到至少一種程式語言的深度流暢（fluency），完全放手技術的風險會大大增加。作者強烈建議在轉入管理前花時間掌握程式設計，對她自己而言這花了約 10 年（包括大學和研究所）。語言的流暢性——包括對其標準工具、函式庫和執行環境的熟悉——會伴隨你很長時間。沒有這種對軟體開發節奏的內化理解，你將在這個層級的關鍵部分掙扎：診斷團隊問題和確保團隊持續產出高品質軟體。

為創造力留出空間#

即使不打算寫太多程式碼，作者強烈建議每週至少保留完整的半天，完全沒有會議或其他義務，並利用這段時間從事某種創造性追求——例如為工程部落格寫文章、準備技術研討會演講、或參與開源專案。做些能滿足你創造慾望的事情，因為作為管理者，這種需求很難以其他方式滿足。

時間管理：什麼才是重要的#

當管理職責多到幾乎沒時間寫程式時，你可能會覺得自己的一天被他人的需求綁架了。會議堆積：1-1、規劃會議、狀態更新、站立會議。是時候弄清楚如何管理自己的時間了，否則你會發現日子一天天過去，卻沒什麼成果。

作者推薦 David Allen 的 Getting Things Done 一書中的觀念。而她個人的時間管理哲學歸結為一件重要的事：理解「重要性」（importance）與「緊急性」（urgency）的差異。幾乎所有任務都落在這兩個維度構成的四個象限中：

重要且緊急#

這類事情你一定會做：重大 outage、明天到期的績效評估、必須在兩天內回覆的候選人 offer。如果在這個類別掉球，你會失去實際的東西。

緊急但不重要（誘人的干擾）#

緊急感往往比重要性更容易被感知。 回覆 email 是個好例子——紅點讓你覺得有新東西需要立即處理，但 email 很少真的緊急。這也是為什麼許多時間管理建議都鼓勵在特定時段讀取和回覆 email。

我們也傾向用「顯而易見」來替代「緊急」。如果行事曆上有個會議，你很明確知道那個時間該在哪裡——但那個會議真的緊急嗎？還是你只是用它來逃避思考如何最好地運用時間？

社群媒體、新聞、即時通訊軟體（如 Slack）都讓人感覺緊急，但其實不然。即時通訊雖然有優點，但資訊持續流動的本質可能讓你更加分心。

重要但不緊急（需要主動安排的策略性工作）#

你很可能把大量時間花在緊急但不太重要的事上，犧牲了重要但不緊急的事。例子包括：

• 準備會議使其能有效進行——健康的會議需要所有參與者預先做準備
• 撰寫職缺描述或制定招聘計畫
• 審查進行中的專案以確保沒有明顯問題滲入
• 與其他團隊的管理者溝通以解決衝突或分歧
• 思考未來——你的團隊現在在哪裡、將來需要在哪裡、需要什麼才能到達那裡

技巧： 作為多團隊管理者，你可以透過向下推動高效會議文化來贏回大量時間。要求提前準備議程、讓人們為出席負責任地預做準備。任何涉及群組的標準會議——無論是規劃、回顧還是事後檢討——都應有明確的流程和預期成果。

管理者的成熟度期望#

與前一個層級相比，一個重大變化是：你的老闆會期望你足夠成熟，能夠獨立管理自己和你的團隊。這意味著你的主管信任你能主動處理那些重要但不緊急的事，在它們變得緊急之前——尤其是在它們對你的主管變得緊急之前。沒有人會告訴你如何管理行事曆來給自己時間做這些事。

會議出席的取捨#

會議可能落入「緊急但不重要」的類別，你可能決定不出席那些你明顯不需要的會議。但在這個管理層級要非常小心地使用這個策略。保持團隊成功前進和快樂投入的責任在你肩上。當你停止出席他們的內部會議時，你可能會錯過幫助你及早發現問題的線索——其中一個主要線索就是太多無聊的會議。

在會議中，觀察你的團隊：

• 如果半數人快睡著、發呆、玩手機或筆電——會議在浪費他們的時間
• 快樂的團隊會表現得有活力和投入
• 不快樂或缺乏動力的團隊會表現得疲憊或無聊

你出席這些會議的部分目的就是觀察團隊的動態和士氣。

決策與委派#

管理多團隊的最初幾個月可能感覺像死亡行軍，即使工時並不誇張。你過去專注的注意力被切割成碎片，分散在一天中各種會議之間。作者在管理多團隊的頭幾個月反覆失聲——她完全不習慣每天說那麼多話。

壞消息： 走出這個狀態的唯一方法是硬撐過去。如果你完全沒有這種感覺，要麼你極其幸運，要麼你可能遺漏了某些需要注意的事。根據作者的經驗，如果你沒有感到一點被淹沒，你很可能漏了什麼。

轉盤比喻#

從此以後，管理的最佳比喻是轉盤（plate spinning）——雜耍表演者在多根竿子上各轉一個盤子，必須在每個盤子減速掉落前去照顧它。你的盤子就是你管理的人和專案，你的工作是判斷每一個在什麼時候需要多少注意力。

用學習者的心態來面對：你正在學習轉盤，你會因為忽略太久而掉落一些。磨練判斷何時碰觸哪個盤子的直覺，就是這場遊戲的核心。

好消息： 隨著時間你會越來越好。你會開始辨識出專案出問題的早期徵兆、準備離職的人、和表現不佳的團隊。這也是為什麼作者強烈建議維持與所有直屬下屬的定期 1-1 會議。如果人太多，可以縮短會議時間或改為雙週一次，但因為太忙而跳過 1-1 是錯過員工即將離職徵兆的最佳方式。

委派框架#

委派是你擺脫盤子太多感覺的主要方法。當任務來臨時，問自己：這件事需要我親自完成嗎？根據任務的複雜度和頻率來決定：

簡單且頻繁的任務——委派出去： 例如主持每日站立會議、撰寫每週進度摘要、進行基本的 code review。你的 Tech Lead 或資深工程師可以接手，甚至不需要額外培訓。

簡單且不頻繁的任務——自己做： 如果自己做比解釋給別人聽還快，而且很少需要做，就捲起袖子做吧，即使你覺得這個任務「低於你的層級」。例如為團隊訂購會議門票或執行產生季度報告的腳本。

複雜且不頻繁的任務——作為培訓機會： 例如撰寫績效評估和制定招聘計畫。這些是你的責任，但也是你想傳授給新興管理者的技能。你可以讓 Tech Lead 陪你一起為實習生寫績效評估，或請資深工程師提供明年支持某專案所需人數的意見。

複雜且頻繁的任務——委派以發展團隊： 例如專案規劃、系統設計、或在 outage 期間擔任關鍵角色。這是你培養團隊人才的最大機會，同時也讓團隊運作得更好。你的目標是讓團隊能在沒有太多你的投入下高水準運作。

重點： 列出只有你才知道如何為團隊完成的任務。有些可能是適當的（如績效評估），但很多都應該教會團隊自己完成：專案管理、新成員到職、與產品團隊拆解路線圖目標為技術交付項、Production Support。這些都是團隊需要學習的技能。前期教學雖花時間，但長期節省時間。更重要的是，培養團隊人才是你作為管理者的職責。

委派是一個開始緩慢但會成為職涯成長核心要素的過程。如果團隊沒有你就無法正常運作，你將很難獲得升遷。

說不的策略#

管理者的工作包括為員工創造有利於工作的環境——聚焦團隊、培養同事情誼、幫助人們學習新技能。她是賦能者、教練和擁護者。

但為了創造這樣的環境，她有時必須說不——對團隊說不、對同儕說不、甚至對老闆說不。每一種「不」都有其困難之處，強大的管理者需要發展有效的說不策略。

“Yes, and”#

對老闆說不很少看起來像是直接的「不」。取而代之的是借用即興喜劇的**「Yes, and」技巧**：「是的，我們可以做那個專案，而我們只需要推遲路線圖上另一個專案的啟動時間。」用正面的態度回應，同時清楚表達現實的界限，會讓你進入資深領導的殿堂。

這對工程師來說是一項很難掌握的技能——我們習慣指出專案的缺點，很難改掉膝跳反射式的「不，那做不到」。開始練習「Yes, and」策略，特別是在與老闆和同儕互動時，看看它如何經常將對立的意見分歧轉變為務實的優先順序談判。

制定政策#

面對團隊時，你要幫他們理解達到「yes」需要什麼。例如一位工程師想用團隊不使用的新語言。你可能想直接說不並給出理由，但你可能發現自己一遍又一遍地說同樣的「不」和同樣的理由：「不，我們需要更多人懂那個語言」「不，我們需要了解如何在生產環境運行它」「不，我們需要有日誌標準和測試方案」。

當你開始重複自己，你就有了制定合理政策的基礎。 該政策包含必須滿足的硬性要求和一些思考指南。制定政策幫助你的團隊提前知道達到「yes」的代價。

“Help Me Say Yes”#

政策不能涵蓋所有情況。「幫我說 yes」這個策略適用於沒有明確政策的一次性情況。當你聽到看似考慮不周的想法時，透過好奇的提問深入探究那些讓你質疑的部分。這種提問方式往往幫助人們自己意識到計畫不好，但有時他們的思路會讓你驚喜。無論哪種方式，好奇的質詢能幫你在說不的同時進行教學。

訴諸預算#

面對團隊和同儕時，你可以訴諸時間和預算。用明確的方式陳列目前的工作量，展示幾乎沒有調整的空間。有時這搭配「現在不行」（not right now），暗示你可能同意但目前做不到。但要注意：當你暗示承諾「以後會做」，你需要確保那個「以後」真的會到來。

團隊合作說不#

有時你和同儕（特別是跨職能的產品或業務夥伴）需要一起說不。有時你會運用技術權威來以有利於產品團隊的方式說不。有時你會借助財務部門來幫助你拒絕某些預算超支。適度使用「好警察/壞警察」的策略——可以借出你的權威來支持一個「不」，然後在你自己需要支持時收回這個人情。

不要含糊其辭#

當你知道需要說不，快速說出比拖延更好。如果你有權威說不，且不認為某件事應該發生，就別折磨自己。你有時會判斷錯誤，所以當發現自己太快說不時，為這個錯誤道歉。你不會有餘裕仔細調查和分析每個決策，所以練習對低風險、低影響的決策做出快速的「不」（和快速的「是」）。

超越程式碼的技術元素#

在這個層級，管理變得令人困惑。我們基於技術能力招聘管理者，但許多人認為這個工作「不再是技術性的」——畢竟管理者大概不怎麼寫程式碼或做系統設計了。假設這個層級的工作本質上變成非技術性的是一個錯誤。 有效地管理工程團隊需要的不只是純管理技能，而在這個層級你需要學習一些新技能——如果你理解軟體工程的實務和紀律，會更容易學會。

你的技術關注點現在轉向觀察和改善開發者在其中運作的工作系統。特別是，你需要培養對團隊整體技術健康信號的敏銳度。

管理暢銷書 First, Break All the Rules 討論了幾個可以預測團隊生產力和滿意度的問題：

• 我知道工作中對我的期望是什麼嗎？
• 我是否擁有做好工作所需的材料和設備？
• 我每天是否有機會做自己最擅長的事？

對大多數工程師而言，這些問題的答案可以從他們推送程式碼的速度和頻率看出。如果需要做的工作很清楚，他們知道該寫什麼程式碼；如果工具、ticket、自動化和流程可用且易用，他們能把程式碼寫出來；如果不被過多會議淹沒或被支援和 incident 管理壓垮，他們每天都有機會寫程式碼。

重點： 團隊技術健康的關鍵指標是：

• 程式碼發布的頻率（frequency of releases）
• 程式碼提交的頻率（frequency of code check-ins）
• 事件發生的頻率（infrequency of incidents）

這三個指標分別對應：團隊知道該做什麼、有工具去做、以及每天有時間去做。

衡量開發團隊的健康#

當你關注開發團隊的健康時，戴上你的技術帽子來設計系統和流程。創建開發者需要的工具，幫助他們專注以便輕鬆弄清楚下一步該做什麼，審查每個流程以確定其應提供的價值，並持續問自己能否進一步自動化。

發布頻率（Frequency of Releases）#

發布頻率是衡量團隊是否在交付程式碼的最直接指標。在現代，程式碼變更的頻率是健康工程團隊的領先指標之一。優秀的工程管理者知道如何創造讓團隊快速移動的環境，而快速移動的一部分就是將工作拆解成小塊。

如果你的團隊沒有持續或每天發布，檢視發布流程：

• 流程需要多長時間？
• 過去幾個月有多少發布出過問題？
• 需要多常延遲或回滾發布？
• 如何判斷程式碼是否可以進入 production？

如果你誠實地審視一個不頻繁發布的團隊，你可能會看到裂縫：執行發布花費很長時間、工程師不對程式碼品質負責而把工作全推給 QA 團隊造成大量來回溝通延遲、回滾耗時、發布過程中的問題導致 production incident 或壞掉的開發 build。

技巧： 推動更頻繁的發布往往會揭示一系列有趣的挑戰——自動化、feature toggle、向前相容的架構設計、滾動升級、小變更而非大補丁。你負責領導這方面的努力，即使你不親自做這些工作。爭取從產品路線圖中騰出時間來支持提升工程生產力，並為團隊設定激勵他們更快行動的目標。

作為技術領導者，雖然你可能不常寫程式碼，但你仍然對技術端的工作完成負責。你也負責保持團隊快樂和有生產力——而解決方案往往不是打氣或加薪或更多讚美，而是讓他們更有生產力、挑戰他們更快更好地工作、幫他們找到時間讓工作更有趣。

程式碼提交頻率（Frequency of Code Check-ins）#

很難擁有一個不理解將工作拆分成小塊價值的敏捷團隊。你可能需要教新進的畢業生這項技能，但即使是資深開發者有時也需要推動。不寫測試的工程師通常更難拆分工作，學習 TDD（即使不每天實踐）可以幫助他們改善這項技能。

作者特別提到這個話題，因為作為新管理者，告訴可能跟你一樣資深甚至更資深的人「你的風格需要更新」會非常不舒服。衝突迴避根深蒂固，而關於個人風格的問題尤其困難。但如果你的公司期望快速的產品開發，想要離開數週獨自寫程式碼而不推送到共享版本控制的工程師會拖慢團隊。你有權期望進行中的工作被定期更新。

事件頻率（Frequency of Incidents）#

團隊產出的軟體有多穩定？品質在改善、惡化還是保持不變？根據你正在構建的產品判斷所需的軟體品質水準並隨時間調整，是你作為管理者需要幫助解決的技術挑戰。

• 如果是全新的小產品，可能功能比穩定更重要
• 如果是關鍵任務系統，穩定性和減少 incident 可能是最高優先

目標是平衡風險，讓 incident 頻率和 incident 預防都不會變成讓開發者數天無法寫程式碼的工作。

如果你的公司讓開發者支援自己寫的程式碼（on-call），要注意：期望團隊成員頻繁在夜間和週末值班是造成倦怠的主要因素。作為管理者，你可以轉向升級支援的角色——不會那麼頻繁管理 incident，但需要在支援系統的人需要你時可以聯繫到。

注意： 過度強調 incident 預防同樣會降低團隊的生產力。過度專注於零缺陷或透過放慢開發流程來防錯，往往跟太快移動並發布不穩定程式碼一樣糟糕。當風險降低變成數週的手動 QA、過度且緩慢的 code review、不頻繁的發布、或冗長的規劃流程時，增加的分析反而讓開發者閒置和焦躁，同時不一定降低 incident 風險。

好管理者 vs. 壞管理者：「我們 vs. 他們」與團隊合作者#

壞管理者：Diana 的案例#

Diana 加入一家中型新創公司管理一個長期被忽視的 mobile 團隊。被告知團隊一團糟的她，迅速從前公司 BigCo 招入一批舊部。這些人不太適應公司文化，團隊很快變成一個自認比組織其他人優越的小圈圈。雖然技術有所改善，但他們與產品團隊持續衝突，app 的進化速度並不快。一年後 Diana 受夠了離職，她帶來的新團隊也跟著走，公司回到原點。

「我們 vs. 他們」的問題#

許多新管理者難以建立共享的團隊認同，預設用工作職能或技術的特殊性來建立認同——強調他們與其他團隊的不同，甚至讓團隊覺得自己比公司其他人優越。這種淺層的認同紐帶容易產生以下功能失調：

• 對領導者離去脆弱：小圈圈團隊極度依賴領導者，一旦管理者離開，小圈圈很可能解散並離開公司
• 抵制外部想法：小圈圈傾向拒絕非團體內部的想法，錯過學習和成長機會。最優秀的成員因缺乏成長而離開公司——他們以為自己已經在最好的團隊了，看不到換團隊可能帶來的成長
• 帝國建設：「我們 vs. 他們」風格的領導者傾向擴張團隊和職責範圍，不考慮對整體組織最好的方案，導致與其他領導者爭搶人數和專案控制權
• 缺乏彈性：這類團隊對來自外部的變化掙扎——組織重組、被取消的專案、焦點轉移都可能打破其脆弱的團隊認同

注意： 作為管理者，即使你被聘來修復一個團隊，也要記住公司能走到現在是因為一些根本的優勢。在試圖改變一切以符合你的願景之前，花時間理解公司的優勢和文化，思考如何建立一個與文化合作而非對抗的團隊。訣竅不是聚焦於什麼壞了，而是辨識現有的優勢並加以培養。

好管理者：Neil 的案例#

Neil 也加入了一家混亂的新創。他謹慎地處理人事變動，確保新員工總是由公司老員工參與面試評估。他花大量時間與產品同儕密切合作，提出一條強調跨職能協作的前進路線，專注於設定清晰的目標並傳達給團隊。開始時緩慢，但隨著時間推移，整個組織變得更強大，技術和產品都有了顯著改善。

以目標驅動的團隊#

持久的團隊建立在來自公司本身的共享目標之上，並與公司價值觀保持一致。他們清楚理解公司的使命，看到自己的團隊如何融入這個使命。這種以目標為基礎的紐帶讓團隊：

• 對個人離去有韌性：因為忠於更大組織的使命，即使經歷人員和領導層的流失，他們也能看到前進的道路
• 被驅動去尋找更好的方式達成目標：更開放接受新想法，更在意想法的優劣而非來源，積極尋求跨職能合作
• 以「第一團隊」（first team）為重：強大的團隊合作者理解，向他們匯報的人不是他們的第一團隊——他們的第一團隊是公司內的同儕。這種認知幫助他們做出優先考慮公司整體需求的決策
• 對服務於目標的變化保持開放：團隊會改變結構，人員需要轉移到業務需要的地方。有了這樣的認知，這些領導者建立出更靈活、更能理解頻繁變化的團隊

技巧： 在新創中，目標有時很模糊、使命有時不清楚。在這種情況下，盡力理解公司文化，思考如何讓你的團隊在這個文化中運作良好。透過跨團隊和跨業務功能的合作，你的團隊會逐漸理解更大的圖景，並在其中找到自己的使命。

懶惰與不耐煩的美德#

Larry Wall 在 Programming Perl 中提出「懶惰、不耐煩和自負」是工程師的美德。這些特質延續到領導力中，學會如何將它們導向優勢，是作者鼓勵所有管理者做的事。

作為管理者，面對個人時你不想表現得不耐煩（那很無禮），也不想看起來懶惰（沒什麼比為一個看起來很輕鬆的老闆拼命工作更糟的了）。但不耐煩搭配懶惰，如果導向流程和決策，則是了不起的組合。

弄清楚什麼是重要的#

隨著你成長為領導角色，人們會以你為行為模範。你要教他們的是如何聚焦。為此，作者鼓勵你練習示範兩件事：弄清楚什麼是重要的和準時回家。

作者受不了看人們用蠻力和花時間（而非思考）來解決問題。任何鼓勵持續加班的文化幾乎肯定在做這件事。自動化的價值在於讓工作更輕鬆——而有趣的工作是那些需要用到大腦的工作，通常不是你能連續做好幾個小時、日復一日的事。

所以要不耐煩地找出什麼是重要的核心。作為領導者，每次看到感覺效率低下的事情，都要質疑它：為什麼這感覺沒效率？我們正在做的事情的價值是什麼？我們能更快地交付那個價值嗎？我們能把這個專案精簡成更簡單的東西並更快完成嗎？

準時回家#

這裡的問題是，當管理者問「能不能更快」時，他們通常明示或暗示地想知道團隊是否能加班來在更少天數內交付。這就是為什麼作者鼓勵你展現和彰顯懶惰的價值。因為「更快」不是「相同小時數但更少天數」，「更快」是「相同的公司價值但更少的總時間」。如果團隊用一週 60 小時來交付原本一週半的工作量，他們沒有更快——他們只是把更多私人時間給了公司。

重點： 準時回家！停止在深夜和週末發 email！強迫自己脫離工作對你的心理健康至關重要。倦怠（burnout）是真實的問題，對個人、家庭和團隊都是災難。

但這不只是防止你自己的倦怠——更是防止團隊的倦怠。當你比所有人工作得更晚、在各種時間發 email 時，即使你不期望團隊回覆或加班，他們看到你這樣做就會認為這很重要。而過度工作讓他們的效率降低，特別是工程師需要進行的細緻知識工作。

如果你作為新管理者需要更多時間來完成工作，那暫時可以，但要想辦法在不鼓勵團隊效仿的情況下做到：將週末和深夜的 email 排程到下一個工作日發送、在非工作時間將即時通訊狀態設為「離開」、休假時不回覆 email。

懶惰和不耐煩。 我們聚焦以便能回家，我們鼓勵回家因為它迫使我們持續聚焦。這就是優秀團隊擴展的方式。

評估你自己的經驗#

• 你上次審視自己的行程，找出那些你在做但對你或團隊沒有提供太多價值的事情是什麼時候？回顧過去幾週、展望未來幾週——你完成了什麼、希望完成什麼？
• 如果你還在寫程式碼，它如何融入你的其他行程？你是在下班後做嗎？是什麼驅使你繼續花這個時間？
• 你上次委派給團隊成員的任務是什麼？是簡單還是複雜的？被委派的人處理得如何？
• 誰是你團隊中正在崛起的領導者？你有什麼計畫來指導他們承擔更大的領導角色？你給了他們什麼任務來為更多責任做準備？
• 撰寫、發布和支援程式碼的流程在你的團隊中是否順暢運作？上次流程出現明顯問題是什麼時候？發生了什麼，團隊如何回應？這個流程多常遇到異常狀況？
• 你上次推動團隊縮減專案範圍是什麼時候？縮減範圍時你削減的是功能、技術品質，還是兩者都有？你如何決定？
• 你上次在晚上 8 點後或週末發 email 是什麼時候？收到 email 的人有回覆嗎？你需要他或她回覆嗎？