Leveling Up As a Tech Lead

全書精華

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

• 主要主題：探討軟體工程師轉型為技術主管（Tech Lead）的歷程，涵蓋在技術、專案以及人員管理三個維度上的全面成長指南。
• 核心論點：即使職稱中帶有「技術（Tech）」，技術主管本質上卻是一個「以人為本」的人員管理角色。日常中多數的技術問題實際上都是「人的問題」，領導者必須將重心從個人的程式碼產出，轉移到賦能團隊、建立關係與解決衝突上。
• 核心訊息：成為卓越的技術主管不需要無所不知，而是需要培養成長心態、建立團隊心理安全感、有效委派任務並建立回饋機制。技術主管的成功不取決於個人產出，而是取決於能否透過提升團隊的整體表現與自主性，來擴大自身的領導影響力。

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

• 角色本質與心態轉變：技術主管的成功等於團隊的成功。這要求領導者從「以個人及程式碼為中心」轉變為「以團隊及價值為導向」，並具備長遠規劃的眼光，學會放下對細節的完美控制與微觀管理（Micromanagement）。
• 建立心理安全感與信任：高績效團隊的基石在於心理安全感。技術主管必須以身作則，將失敗常態化（例如將「我不知道」掛在嘴邊、妥善從事件中學習），並鼓勵多元觀點與公開誠實的溝通，藉此建立團隊的信任感，讓成員敢於承擔風險與提出質疑。
• 透過一對一會議與回饋促進成長：定期的一對一會議（One-on-Ones）是技術主管最強大的管理工具，能用來發現潛在問題、建立關係與支持成員成長。此外，必須在團隊中建立「回饋文化」，遵循及時、具體、明確、誠實與持續的五大原則，給予正面肯定與建設性改善建議。
• 掌握有效委派的藝術：委派（Delegating）不僅是把工作交給別人，更是為了釋放主管的時間、促進團隊成員成長，以及避免主管成為團隊瓶頸以提升整體績效。克服「我自己做比較快」或「害怕失去控制」的心魔，並運用 SMARTT 原則設定清晰期望，能讓團隊更具自主性與韌性。
• 橋接技術與商業的利益關係人管理：技術主管是團隊與企業商業端之間的橋樑。透過主動且透明的溝通，了解各方需求，並運用「重新框架（Reframe）、建立連結（Relate）、持續強化（Reinforce）」的 3R 框架，能夠有效說服非技術背景的利益關係人，取得針對技術債或架構重構等技術投資的支持。
• 平衡創新與穩定的技術決策：技術主管需引導團隊做出明智的技術決策，在擁抱新技術（創新）與維持系統可靠性（穩定）之間取得平衡。同時應適時運用架構決策紀錄（ADR）來追蹤技術選擇的脈絡與權衡，確保團隊能以健康的架構與測試策略支持持續交付。

反主流洞見

科技組長本質上是「人資管理」而非純技術職

• 差異點：主流觀點通常認為科技組長必須是團隊中技術最強的人，主要專注於架構設計與程式碼產出。然而，作者指出，無論紙本上的職務描述看起來多麼偏向技術，這本質上是一個「領導人」的角色。
• 作者論證：作者認為，如果沒有良好的人員管理，根本無法確保交付品質與技術卓越。大部分的技術問題歸根究底都是「人的問題」，解決這些問題需要強大的軟實力，而非單純的技術能力。
• 相關案例：作者曾遇到兩位開發者為該使用哪個 JSON 解析庫而爭論不休。作者起初想介入做出技術裁決，但後來發現這其實是兩人之間長期存在的人際衝突，解決了人的衝突後，技術問題便迎刃而解。

說「我不知道」能建立信任而非削弱權威

• 差異點：許多新任領導者認為自己必須無所不知，才能在團隊與客戶面前維持專業與權威。作者則反其道而行，認為承認無知才是建立信任與心理安全的關鍵。
• 作者論證：掩飾無知會導致巨大的壓力和過度準備，進而引發職業倦怠。相反地，坦承「我不知道」能減輕壓力、促進合作，並讓團隊成員知道承認自己的不足是安全的，進而加速團隊學習。
• 相關案例：作者分享自己初期常因焦慮而過度準備，甚至在客戶面前不敢承認不知道。後來她嘗試在客戶面前坦白「我不知道」，雖然一開始非常困難，但最終反而創造了誠實的氛圍，並引導更多人勇敢展現真實狀態。

不要急著幫團隊解決所有問題

• 差異點：主流思維認為，一位好主管應該隨時準備好為團隊排除萬難、解決問題。但作者警告，過度介入反而會害了團隊與自己。
• 作者論證：如果科技組長總是跳出來解決問題，不僅會導致自己精力耗盡，還會剝奪團隊成員學習與發展自主性的機會，最終使組長成為團隊的單一故障點。
• 相關案例：作者曾主動幫一位剛搬到新城市的團隊成員處理繁瑣的行政文件，甚至為此缺席站會。結果不僅事情沒處理好、雙方關係惡化，作者自己也感到心力交瘁。她體悟到，有時候最好的幫助是引導他們自己解決，而不是越俎代庖。

團隊內有衝突其實是好現象

• 差異點：一般人往往認為和諧、沒有爭執的團隊才是表現最好的團隊。然而，作者指出完全沒有衝突反而令人擔憂。
• 作者論證：健康的衝突意味著團隊成員在乎工作，且具有足夠的「心理安全感」來挑戰彼此與提出疑慮。如果所有人都總是同意，或者根本沒人發言，這表示想法沒有受到檢驗；健康的團隊會透過辯論來做出更好的決策。
• 相關案例：作者提到，若團隊總是安靜或完全無異議，這其實是協作的隱形殺手，因為成員可能因為害怕被批判而不敢發言。在心理安全的團隊中，成員會為了找出最佳解而爭論，並在此過程中變得更強大。

內化行動計畫

01. 釐清期待基準線

• 行動目標：確保 Tech Lead 清楚了解公司與團隊的真實期望，避免努力錯方向。
• 記憶鉤子：對齊優於盲幹——「你以為的不是老闆以為的」。
• 故事或例子：作者輔導一位新任 Tech Lead，她以為只要專注架構與寫出最難的程式碼，結果卻被主管批評缺乏跨團隊溝通的能見度。若她能及早透過訪談與主管、團隊對齊期待，就能避免這場誤會，並確立正確的領導方向。
• 觸發情境：剛接任 Tech Lead 角色，或感到工作方向與團隊、主管脫節時。
• 對象與場景：主管、團隊成員與利害關係人的 1-on-1 會議。
• 具體步驟：
  • 步驟一：閱讀官方職位描述，將模糊的期望（如「推動創新」）轉化為具體日常情境。
  • 步驟二：與主管、團隊及利害關係人進行訪談，詢問他們對你的具體期望。
  • 步驟三：彙整回饋，定義 1 到 10 分的自我評估基準，並與主管確認這些重點目標是否務實。
• 可衡量的成果：產出一份與主管、團隊達成共識的角色期望清單與當前能力評分。
• 失敗補救機制：若公司沒有官方職缺描述，請自行草擬一份並主動向主管與利害關係人尋求共識與修正。

02. 使用艾森豪矩陣奪回時間

• 行動目標：區分重要與緊急任務，防止 Tech Lead 陷入永無止盡的救火狀態。
• 記憶鉤子：別當救火隊長——「不是每件急事都重要」。
• 故事或例子：許多 Tech Lead 總覺得每件事都很重要而將清單塞滿。作者發現，如果不果斷把「為下週客戶準備 Demo」這類任務移交給成員，Tech Lead 只會陷入無止盡的救火。透過委派與刪減，終於找回規劃團隊長遠目標的時間。
• 觸發情境：感到工作超載、每天都在解決突發狀況，無暇思考技術策略時。
• 對象與場景：Tech Lead 自己的日常時間與任務管理規劃。
• 具體步驟：
  • 步驟一：盤點所有任務，將其填入「重要／不重要」與「緊急／不緊急」的 2x2 矩陣中。
  • 步驟二：勇敢把「緊急但不重要」的任務委派出去，並刪除「不緊急且不重要」的雜事。
  • 步驟三：根據整理後的矩陣安排下週行事曆，並為突發狀況預留合理的緩衝時間。
• 可衡量的成果：每週行事曆上至少有 2-3 個時段被保護為不被打擾的「思考與規劃時間」。
• 失敗補救機制：若突發事件不斷打亂計畫，於週末回顧分析是任務預估不切實際，還是沒有果斷拒絕非必要請求。

03. 運用 SMARTT 原則委派任務

• 行動目標：有效下放任務給團隊成員，確保執行方向一致且成果易於追蹤。
• 記憶鉤子：授權不等於放生——「說清楚，少重做」。
• 故事或例子：作者曾請一位開發者準備 Showcase，卻沒給予具體要求。結果對方只準備了一張投影片並花一分鐘報完，讓作者當下傻眼。這讓作者學到，未明確定義期待的委派失敗責任在主管，改用 SMARTT 後成效大增。
• 觸發情境：團隊成員需要成長機會，或自己手邊工作過載需要交辦時。
• 對象與場景：面對團隊中的工程師，進行任務分配與目標設定時。
• 具體步驟：
  • 步驟一：具體定義 (Specific) 產出與參與者，並確保目標可衡量 (Measurable) 且可達成 (Achievable)。
  • 步驟二：與成員溝通此任務的商業關聯性 (Relevant) 與明確的完成期限 (Time-bound)。
  • 步驟三：建立可追蹤的機制 (Trackable)，例如約定使用共用文件或每週快速同步進度。
• 可衡量的成果：被委派者能獨立產出符合標準的成果，且任務執行過程中的重工率減少。
• 失敗補救機制：若成員卡關，退回「教練模式」，透過提問引導他們自行尋找答案，而非直接拿回來自己做。

04. 透過 SBI 模型給予建設性回饋

• 行動目標：降低接收者的防衛心，提供具體且能促成行為改變的回饋。
• 記憶鉤子：對事不對人——「用事實取代批評」。
• 故事或例子：一位資深工程師常在會議中打斷別人，導致團隊士氣低落。作者運用 SBI 模型向他溝通：「你在規劃會議上打斷發言，這讓大家不敢繼續發表意見。」對方才意識到盲點並開始改善，團隊的信任感也隨之回升。
• 觸發情境：發現團隊成員有不良行為模式，或任務未達預期需要即時糾正時。
• 對象與場景：與團隊成員進行 1-on-1 會議，或需要即時導正行為的場合。
• 具體步驟：
  • 步驟一：描述具體情境 (Situation)，明確指出行為發生的時間與地點。
  • 步驟二：描述觀察到的行為 (Behavior)，僅陳述客觀事實，絕不加入個人猜測或評判。
  • 步驟三：說明該行為帶來的影響 (Impact)，包含對團隊協作或專案進度的具體效應。
• 可衡量的成果：回饋接收者能明確指出自己需要修正的行為，且雙方對話中未發生防衛性爭吵。
• 失敗補救機制：若對方情緒激動或出現抗拒，先給予空間消化，稍後再透過引導式問題共同探討未來的解決方案。

05. 翻譯並處理高價值技術債

• 行動目標：讓技術債的商業影響視覺化，並成功取得利害關係人的資源支持。
• 記憶鉤子：翻譯技術價值——「技術債是商業風險」。
• 故事或例子：團隊面對不斷導致記憶體洩漏的關鍵系統，卻總因專案壓力被擱置。作者將其重構為商業風險（停機與營收損失），成功說服利害關係人給予時間修復，事後更展現了省下的成本與提升的穩定性，贏得了深度信任。
• 觸發情境：技術債嚴重拖慢開發速度或引發線上問題，但業務端持續施壓要求新功能時。
• 對象與場景：開發團隊、產品經理與業務利害關係人的排程會議。
• 具體步驟：
  • 步驟一：與團隊列出所有技術債，用 2x2 的「努力-價值矩陣」進行評估，挑出高價值、低努力的項目。
  • 步驟二：運用 3R 原則（重構 Reframe、關聯 Relate、強化 Reinforce），將技術債翻譯為商業痛點向利害關係人提案。
  • 步驟三：將技術債處理常態排入 Sprint 中，或採用 80/20 法則保留固定產能進行清理。
• 可衡量的成果：每個月穩定推進並消除 1-2 項高價值技術債，減少線上問題發生率。
• 失敗補救機制：若無法取得專屬大塊時間，則採用「童子軍原則」，要求團隊在開發新功能時順手清理周邊的小型技術債。

06. 撰寫架構決策紀錄 (ADR)

• 行動目標：記錄技術決策的上下文與妥協，確保未來團隊有跡可循，減少重複討論。
• 記憶鉤子：好記憶不如爛筆頭——「讓未來的自己不抓狂」。
• 故事或例子：開發者常為了是否採用某個 JSON 函式庫爭論不休，浪費大量時間。如果團隊在幾個月前已寫下 ADR，記錄當初放棄該選項的考量與妥協，就能迅速終止無意義的辯論，讓團隊在爭議中快速推進開發進度。
• 觸發情境：團隊面臨重大架構變更、技術選型，或需權衡多個解決方案時。
• 對象與場景：整體開發團隊、技術架構師與未來的團隊成員。
• 具體步驟：
  • 步驟一：建立一個輕量級的 ADR 模板（包含：背景、決策內容、預期後果與妥協）。
  • 步驟二：在技術討論會議達成共識後，立即將決策與放棄的選項清楚寫入文件中。
  • 步驟三：將「更新 ADR」列入特定功能開發的 Definition of Done (DoD) 中以養成習慣。
• 可衡量的成果：團隊的所有重大架構變動都有對應的 ADR 檔案，新進人員能藉此快速理解系統演進。
• 失敗補救機制：若無人主動撰寫，可設立輪值的「文件管理員」，在 Code Review 階段強制檢查是否遺漏 ADR 更新。

整體執行建議

• 搭配方式：從「自我管理」（釐清期待、矩陣時間管理）開始，穩固自身步調後推展至「人際與團隊管理」（SBI 回饋、SMARTT 委派），最後落實於「系統管理」（技術債翻譯、撰寫 ADR），形成由內而外的影響力。
• 執行週期：每週五下午進行時間與任務的艾森豪矩陣檢視；每雙週透過 1-on-1 練習SBI 回饋與委派進度追蹤；每個月與團隊檢視一次技術債矩陣與 ADR 產出狀況。
• 防棄機制：
  1. 將這些行動排入行事曆並與常態性的 1-on-1 綁定，讓既有的會議行事曆自動推動你執行。
  2. 建立專屬的「成就罐（Brag Document）」，每週記錄執行這些行動帶來的小勝利（例如成功擋下一件急事、某成員順利完成委派），做為持續推動自己的燃料。

記憶卡片總表