#254《An Elegant Puzzle》工程師當上主管後，沒人教你的那些事

當工程師的時候， 我最喜歡的事情就是解 bug。 問題明確、 解法可驗證、 修完就是修完了。

後來開始帶團隊， 才發現人的問題沒有 stack trace。

---

團隊不是機器， 是有機體

Will Larson 在 《An Elegant Puzzle》 開頭就說了一件很多工程主管不願意面對的事—— 你不能用 debug 的思維去管理團隊。

程式碼是確定性的。 給同樣的 input， 永遠得到同樣的 output。 但人不是。 同一個決策， 在不同的團隊狀態下， 會產生完全不同的結果。

他把團隊分成四個階段：

階段	狀態	該做的事
Falling behind	持續欠債、 士氣低落	減少需求、 增加人力
Treading water	能完成工作但沒有進步	減少技術債
Repaying debt	開始償還技術債	給空間持續還債
Innovating	有餘裕做新東西	保持節奏、 不要過度擴張

大部分的管理問題， 不是人的問題， 是階段的問題。

我以前帶團隊的時候犯過一個錯—— 團隊還在 Falling behind 的階段， 我就在推新功能。 結果不是功能做不好， 是整個團隊的信心都被磨掉了。

讀到 Larson 這段的時候， 腦子裡閃過的就是那段日子。

---

System Design 不只是畫架構圖

這本書最有意思的地方在於， 它把 System Design 的思維用在了組織設計上。

Larson 認為工程主管最重要的工作不是寫 code、 不是開會、 不是做 code review—— 是設計系統。 只不過這個系統不是 microservices， 而是團隊的運作方式。

包括：

• 怎麼決定一個團隊該多大？（他的答案是 6-8 人）
• 什麼時候該拆團隊？ 什麼時候該合併？
• Tech Lead 和 Engineering Manager 的職責要怎麼切？

好的組織設計跟好的系統架構一樣—— 解耦、 高內聚、 介面清晰。

之前讀 《Team Topologies》 的時候就有類似的感覺。 Conway’s Law 不只是一個觀察， 它是一個設計原則。 你的組織結構會直接映射到你的系統架構。

---

關於技術債的真話

有一段我畫了重點線。

Larson 說大部分公司處理技術債的方式都是錯的—— 要嘛完全忽略它， 要嘛搞一個大規模的「技術債清償計劃」然後半途而廢。

他的建議是把技術債當成持續性的投資， 而不是一次性的專案。 每個 sprint 固定留 20% 的時間給技術改善， 不需要申請、 不需要審批。

技術債不是 bug，也不是 feature。 它是利息。 你不處理它，它會自己長大。

這讓我想到之前在團隊裡推「Tech Health Friday」的經驗。 每週五下午固定拿來處理技術債和工具改善。 一開始 PM 會質疑為什麼要「浪費」這個時間， 但三個月後大家都感受到 deploy 速度變快、 on-call 事件減少了。

---

工程師的職涯不只有管理這條路

書的後半段談到 Staff+ Engineer 的角色—— 不想當主管的資深工程師該何去何從？

Larson 自己就是從 IC（Individual Contributor）一路做到 VP of Engineering 再回到 Staff 角色的人。 他說這兩條路沒有高下之分， 但公司的 career ladder 通常只設計了管理這條。

如果你的公司只有管理一條升遷路徑， 那你遲早會失去最好的工程師。

這件事我深有感觸。 見過太多優秀的工程師被「升」成主管後不開心的例子。 寫程式是他們的超能力， 結果升遷之後反而不能用了。

---

不完美但真實

要說缺點的話， 這本書的結構有點散。 它更像是一系列的 blog posts 集結成冊（事實上確實如此）， 而不是一本有嚴謹結構的教科書。

但正因為這樣， 它讀起來特別真實。 每一個章節都是 Larson 在 Stripe、Uber、Calm 實際踩過的坑、 做過的決定。 不是理論， 是手感。

工程管理沒有標準答案。 但有些問題， 前人已經想過了。 這本書最大的價值不是告訴你怎麼做， 而是讓你知道你不是一個人在面對這些困難。

---

📚 書籍資訊

• 書名：An Elegant Puzzle: Systems of Engineering Management
• 作者：Will Larson
• 出版：2019
• 核心主題：工程團隊管理、組織設計、技術領導力