當工程師的時候，我最喜歡的事情就是解 bug。問題明確、解法可驗證、修完就是修完了。
後來開始帶團隊，才發現人的問題沒有 stack trace。
團隊不是機器，是有機體
Will Larson 在 《An Elegant Puzzle》 開頭就說了一件很多工程主管不願意面對的事——你不能用 debug 的思維去管理團隊。
程式碼是確定性的：給同樣的 input，永遠得到同樣的 output。但人不是。同一個決策，在不同的團隊狀態下，會產生完全不同的結果。他把團隊分成四個階段：
| 階段 | 狀態 | 該做的事 |
|---|---|---|
| Falling behind | 持續欠債、士氣低落 | 減少需求、增加人力 |
| Treading water | 能完成工作但沒有進步 | 減少技術債 |
| Repaying debt | 開始償還技術債 | 給空間持續還債 |
| Innovating | 有餘裕做新東西 | 保持節奏、不要過度擴張 |
大部分的管理問題，不是人的問題，是階段的問題。 我以前帶團隊的時候犯過一個錯——團隊還在 Falling behind 的階段，我就在推新功能。結果不是功能做不好，是整個團隊的信心都被磨掉了。Larson 這段，寫的就是那段日子。
先認識一下作者，這會幫你抓到這本書的「口音」。Larson 的職涯橫跨 Yahoo!、Digg、Uber（帶平台工程組織）、Stripe（創立 Foundation Engineering 團隊）、Calm（當 CTO），後來是 Carta 的 CTO。他從大學就開始經營部落格 lethain.com，而這本書，其實就是把那些部落格文章整理集結而成的（他後來還寫了《Staff Engineer》）。記住「Uber、Stripe」和「部落格合集」這兩件事——等一下談反面角度時，它們就是關鍵。
System Design 不只是畫架構圖
這本書最有意思的地方在於，它把 System Design 的思維用在了組織設計上。
Larson 認為工程主管最重要的工作不是寫 code、不是開會、不是做 code review——是設計系統。只不過這個系統不是 microservices，而是團隊的運作方式。包括：一個團隊該多大（他的答案是 6-8 人，超過 8、9 人，主管就會退化成被動救火）？什麼時候該拆團隊、什麼時候該合併？Tech Lead 和 Engineering Manager 的職責要怎麼切？
好的組織設計跟好的系統架構一樣——解耦、高內聚、介面清晰。 之前讀《Team Topologies》的時候就有類似的感覺：Conway’s Law 不只是一個觀察，它是一個設計原則。你的組織結構會直接映射到你的系統架構。
關於技術債的真話
有一段我畫了重點線。
Larson 說大部分公司處理技術債的方式都是錯的——要嘛完全忽略它，要嘛搞一個大規模的「技術債清償計劃」然後半途而廢。他的建議是把技術債當成持續性的投資，而不是一次性的專案：固定留一部分時間給技術改善，不需要申請、不需要審批。
技術債不是 bug，也不是 feature。它是利息。你不處理它，它會自己長大。
這讓我想到之前在團隊裡推「Tech Health Friday」的經驗。每週五下午固定拿來處理技術債和工具改善。一開始 PM 會質疑為什麼要「浪費」這個時間，但三個月後大家都感受到 deploy 速度變快、on-call 事件減少了。
工程師的職涯不只有管理這條路
書的後半段談到 Staff+ Engineer 的角色——不想當主管的資深工程師該何去何從？
Larson 自己就是從 IC（Individual Contributor）一路做到 VP of Engineering 再回到 Staff 角色的人。他說這兩條路沒有高下之分，但公司的 career ladder 通常只設計了管理這條。如果你的公司只有管理一條升遷路徑，那你遲早會失去最好的工程師。
這件事我深有感觸。見過太多優秀的工程師被「升」成主管後不開心的例子——寫程式是他們的超能力，結果升遷之後反而不能用了。
但這是一本「大公司」的書
寫到這裡，得插一段誠實話。這本書我給五星，但它有三個前提，你不先看清楚，照著做反而會受傷。
第一，它的脈絡是「大公司、高速擴張」。 別忘了作者的履歷——Uber、Stripe，都是那種「人數每年翻倍、問題多到滿出來」的超高速成長公司。書裡的痛點（怎麼拆團隊、怎麼設計升遷委員會、怎麼盤點組織），是那個規模才會遇到的。如果你帶的是一個 5 個人的小團隊，硬套這套組織理論，會像拿著航空母艦的操作手冊去開一艘快艇——不是手冊不好，是你根本還用不到那些艙室。早期團隊真正缺的，往往不是制度，而是「先把東西做出來」。
第二，它偏系統，輕人際。 這本書最迷人的一招，就是把工程管理當成一道 system design 的題目來解——但這也是它最大的盲點。它幾乎刻意略過了管理裡最軟、也最難的那一塊：怎麼開一場好的一對一、怎麼給一個會痛但有用的回饋、怎麼跟一個表現變差的部屬好好談、怎麼處理跨文化的溝通。這些「帶心」的功夫，沒有 mini-framework 可以套，而它們往往才是新手主管真正會卡死的地方。書能教你設計制度，但帶人這門手藝，它幫不上太多忙。
第三，它讀起來像部落格合集，因為它本來就是。 章節之間的順序不總是合理，有些論點會重複，行文偶爾冗長。它不是一本從頭到尾有嚴謹結構、能線性讀完的教科書，比較像一本「隨時翻到需要那頁」的工具箱。當參考書讀很好，當入門教材讀會有點散。
不過，也正因為它是真槍實彈踩過的坑集結而成，它讀起來特別真實。每一章都是 Larson 在 Uber、Stripe、Calm 親手做過的決定，不是理論，是手感。
誠實地說：規模到了再讀它，如獲至寶；規模還沒到就照搬，反而綁手綁腳。 它最大的價值，不是給你標準答案，而是讓你知道，你正在面對的這些難題，前人已經想過了，你不是一個人。
工程管理沒有標準答案。但有些問題，前人已經想過了——你要做的，是判斷自己現在在哪個階段、需不需要那個答案。
📚 「科技與工程」系列延伸閱讀
📚 書籍資訊
- 書名：An Elegant Puzzle: Systems of Engineering Management
- 作者：Will Larson
- 出版：2019（Stripe Press）
- 核心主題：工程團隊管理、組織設計、技術領導力
🖼️ 圖片說明
文中插圖為 AI 生成插畫（Gemini 3.1 Flash Image / Nano Banana 2）。本站使用 AI 圖作為視覺輔助，依書中概念意象生成，非實拍紀錄。