Will Larson 談工程管理的新修訂規則

Will Larson 曾擔任三次 CTO，現任 Imprint 的 CTO。他主張，2010 年代的管理規則已經顛倒：當年主管被要求絕不插手技術決策，資深工程師則被視為理應拿到「有趣」的工作；如今情況相反，高階主管必須緊盯技術細節，同時還得承擔官僚職能，而願意解決業務痛點的工程師，會比那些只等有趣題目上門的人活得更久。整場對談大部分時間都在討論：零利率時代的誘因如何塑造了整整十年的管理習慣、CTO 與中階主管的職涯路徑如今長什麼樣子，以及 AI 如何改變軟體工程這個角色本身；「工程管理修訂版法則」這個框架，主要是透過 Larson 的常駐團隊論述，以及他對 Digg 改版事件的回顧浮現出來。

Larson 確實有資格談這個題目：他在 Uber 負責基礎架構，當時公司人數每六個月翻一倍；之後在 Stripe 任職四年，匯報層級只比執行長低一階；此後陸續出任 Calm、Carta 與 Imprint 的 CTO，並著作《The Elegant Puzzle》、《Staff Engineer》與《Crafting Engineering Strategy》。讀者讀完後應能帶走三件事：CTO 具體在做什麼的模型、中階主管此刻為何處境危險，以及 Larson 為何說他在 Imprint 的 18 個月裡寫的生產程式碼，比他先前整個職涯加起來還多。

2010 年代的主管被要求別再做技術決策，這個角色因此崩壞

Larson 的核心診斷是：零利率時代不只是把估值吹大，它還改寫了主管被獎勵什麼。他在 2010 年代踏入管理職時，「你最早學到的幾件事之一就是：嘿，你以後再也不能做技術決策了。」他說這「真的就是我被交代的話」，而這「絕對不是今天的風氣」。

他描述的機制是這樣：主管若不能提出技術方案，手上就只剩流程、排程與人力這幾根槓桿。這會把聰明的主管推向討好眾人、把工程師擋在業務之外，以及過度看重招募與員工滿意度分數。Larson 對後果說得很直白——「招募是解決所有問題裡最無趣的一種方式」——並指出，在主管碰不到技術的世界裡，「他們唯一能真正加快執行速度的槓桿，就是用人頭來排優先順序」，他直接把這點連到「我們過去看到的那些臢腫組織」。

他把「零利率解釋一切」這個框架（他引用 The Margins，他 Digg 時期的前同事 John Durek 與 Ranjan Roy 在那裡寫作）歸功於精準捕捉了那十年：搶工程師的競爭把籌碼推到員工手上，公司則在福利與「有趣的工作」上較勁。Larson 特別指出一個症狀，認為它很能說明問題——「工程師也許不該輪值 on‑call」的想法，改由二線 SRE 來接頁——因為「我合作過的每一個人都知道，讓工程師為自己的工作輪值 on‑call，軟體才會更好。」

| 時代訊號 | 2010 年代的做法 | Larson 今天的看法 |
|---|---|---|
| 主管的技術角色 | 絕不做技術決策 | 必須掌握細節，而且往往被要求如此 |
| 資深工程師的任務 | 做自己覺得有趣的題目 | 解決業務上真正痛的問題 |
| 招募 | 補人頭是主要槓桿 | 解決任何問題裡最無趣的方式 |
| On‑call | 把工程師擋在外面，叫別人接頁 | 工程師為自己的軟體輪值 |
| 晉升標準 | 詳盡的職能矩陣、校準會議 | 判斷力加上硬性限制（例如 staff 人數比例） |

想要「有趣工作」的資深工程師，是誤讀了這份契約

在 Stripe，Larson 的團隊成長到約 250 至 260 人，其中幾位他最強的工程師來要求更有趣的題目。他的回答後來變成他反覆引用的一句話：「我手上只有苦差事可以給你，但這份苦差事正是讓業務成功的關鍵。」他說，其中不少人把這個請求當成「管理契約被違反」——彷彿主管的義務就是給資深員工有回報的工作。

Larson 認為這種看法在高階主管圈從來不成立：他待過的每一家公司，最資深的那批人「都在做公司真正需要、真正有價值的工作」。他把相反的觀點歸因於某些新進員工的前東家（「某些公司……對這套有非常強硬的版本」），但沒有點名，並說整個產業後來已經回擺。

他對 staff‑plus 影響力的定義，是在模糊情境下做決策，而不是寫多少程式碼。他舉了一個 Stripe 的例子：帶頭做多區域（multi‑region）專案的工程師，不斷要求產品團隊決定跨區域複寫該怎麼運作——等於要產品去扛 CAP 定理的取捨。「他們做的事，其實是在找方法讓自己卡住。」Staff 層級的本事，是做出取捨、建立信念，並用原型驗證假設。他補充，代理（agent）並不擅長這件事：「代理往往根本認不出這些取捨，因為它們不在上下文視窗裡」——那些幽微、隱含的限制條件，存在於軟體之外。

常駐、高當責的團隊，勝過把所有人輪流丟進火場

Larson 稱常駐團隊（durable teams）是「打造有技能組織的唯一方法」，但也承認這「算是個不太有共識的看法」，因為從表面上看起來不對。失敗模式就是《人月神話》那一招——合作夥伴專案延遲了，於是再加 15 個人進去。Larson 說，這往往「是做給人看的，營造出已經竭盡全力的觀感，這樣一來，當你沒達標時，錯就不在你身上」，而它會摧毀原本真正有效的東西。

他的操作模式，在 Uber、Stripe、Calm 與 Imprint 都用過（他到 Carta 時，那邊已經規模化了）：把組織切成各自擁有領域的小隊（pod），然後就不再管它們，直到出事為止，把自己的注意力留給槓桿最高的問題。在 Stripe，他接手時團隊約 30 人，其中約 23 至 24 人直接向他匯報，他做的第一件事就是定義小隊。

另一種做法——每次都把同一批強將拉去救火——會導致過勞，因為「在一家真正在成長的公司，天天都有危機」。他轉述一位 Stripe 同事的比喻：大家沿著城牆跑，哪裡快被攻破就往哪裡跑，跑得越來越快，卻永遠不可能同時守在所有地方。解法是讓很多人在很多位置上，各自守好自己的點。他也提到 AI 的但書：注意力耗盡的臨界點現在可能遠得多，「但我還是認為，他們的注意力會比寫程式碼的能力更早耗盡。」

CTO 的工作是技術人加官僚，而舊的職涯階梯把前一半給最佳化掉了

Larson 心目中稱職的工程高階主管，必須具備兩半。一半是深厚的技術判斷力——知道該做什麼、該怎麼做。另一半是當「一個好的官僚」：經營一個職能、設計誘因、在推行流程之前就知道哪些會失敗。他引用 James C. Scott 的《Seeing Like a State》，稱之為談制度如何觀看與形塑行為的經典之作。

2010 年代的路徑——工程師、然後主管、再一路爬過中階管理到 CTO——篩選的是官僚那一半，卻往往把技術那一半濾掉了，因為一心拚晉升的人很早就離開細節。Larson 有個反直覺的論點：「一線主管其實是比中階主管更憑本能行事的高階主管」，因為他們實際處理細節，在非官僚的面向判斷力更好，儘管他們的官僚判斷力偏弱。舊階梯會教會你官僚那一套；如今這條階梯已不復當年深度，所以官僚那一半反而變成更難補的一塊。

他也把 CTO 這個角色描述為本質上跨職能。在 Imprint，他現在除了工程之外也帶領產品設計；過去一年大半時間，他還在這裡管過客戶營運；在 Stripe 時，他管過支援工程與資料工程——這些職能他自己都沒親自做過。他把工程、產品、設計合一的架構，定位成對當前劇變時刻的回應，而不是長期趨勢：「現階段我盡量避免對太遠的未來做預測。」

「2010 年代當工程主管最糟的部分之一就是……你最早學到的幾件事之一就是：嘿，你以後再也不能做技術決策了。」

中階管理是處境最危險的一層，Larson 的建議是往程式碼靠攏

Larson 同意「現在當中階主管很難熬」，尤其是那些在 2010 年代賦權模式下被挑選、被訓練出來的人，如今發現評分標準在他們腳下被換掉了。他的處方很直接：「你要嘛得重新鑽回細節，要嘛這個世界變化得太劇烈，你熟悉的那個職業三年後就不值錢了。」他把這個選擇講成「我是現在就退休，還是重新學技能？」

他自己就是這樣做的。離開團隊約 250 人的 Carta，他加入 Imprint 帶領約 25 人——刻意縮小管轄範圍，重新學習如何用 AI 打造軟體。他說在 Imprint 約 18 個月裡，他送出了超過 500 個 pull request，「比我先前整個職涯加起來還多得多。」

他提供了一個招募範本：Jasmine 是他在 Carta 共事過的人，加入 Imprint 擔任 VP，直接帶人，現在寫的軟體量之大，是她在 Carta 時根本撥不出時間做的。「那些願意真的回去動手的人太有價值了……這種人我整天都想多僱幾個。」他的面試建議也順著這個邏輯：先篩選出優秀的 EM，然後問他們，如果不能多寫點軟體會不會覺得難受——「那才是我們真正想要的人。」

至於 tech lead manager（TLM）這個角色，他和 Orosz 先前都稱之為職涯陷阱，Larson 現在修正了說法：「它還是個陷阱，但現在是需求很高的陷阱。」組織扁平化之後，總監愈來愈常管理 TLM 而不是一線主管，有些 EM 現在要帶 12 至 14 個下屬，而不是四到八個。他想要的人，是有能力做官僚工作、但沒有那個意願的人——這種人預設就會去寫軟體。

flowchart TD
    A["技術判斷力強的工程師"] --> B{"願意接受平調或降級嗎？"}
    B -->|不願意| C["留在中階管理，承受扁平化衝擊"]
    B -->|願意| D["一線主管或親自動手的角色"]
    D --> E["用 AI 工具重建技術細節"]
    E --> F["在較小範圍內累積官僚經驗"]
    F --> G["可信的高階主管人選"]
    C --> H["與重視細節的同儕競爭更少的 VP 職缺"]

Digg 改版是「在未經證實的基礎架構上線」的警世故事

Larson 在 Digg v4 改版上線前約三到六個月加入，那是他離開 Yahoo 後的第二份工作。背景是：Digg 當時是前十大網站，流量有 60% 至 70% 來自搜尋導向的永久連結頁面，而 Google 演算法變動（他點名 Panda 等）正在侵蝕這塊流量。公司約有 110 至 120 人，錢快燒完了。

那次改版把分片 MySQL 換成 Cassandra。Larson 對壓力測試缺口的那段描述，是整集最生動的工程軼事：上線前兩天，他和另一位工程師 Rich 被拉到一旁，因為壓力測試從來沒做過。在與 Cassandra 計畫負責人 Chris 的對話中，Larson 確認了這套系統無法同時讀寫——「如果我在寫 Cassandra，我就不能從 Cassandra 讀。如果我在讀 Cassandra，我就不能寫 Cassandra」——而他們還是照樣上線了。

上線當天：穿燕尾服的餐飲人員端著壽司和香檳，樓上有按摩，有桌球，工程師圍坐在房間正中央的一張大桌旁。因為 Digg 自有硬體，無法讓新舊系統並行，伺服器是一臺一臺抹掉的，所以根本沒有回滾這回事。網站掛了約 24 小時。Rich 和 Larson 在頭兩天寫了一層 Redis 快取，讓網站一次能撐幾個小時；一個記憶體洩漏逼得每個行程都得輪流重啟。根本原因花了約四週才找到：一個 Python API 服務用了可變的預設引數（一個使用者 ID 清單），這個引數會跨呼叫持續存在，一路連鎖，直到 memcache 掛掉，連帶把 Cassandra 也拖垮。Larson 修好那天，新執行長上任；接下來一年，公司大規模裁員。

Larson 的結論並不是改版本身錯了：「如果他們只是繼續維持舊站，也一樣會死。」他事後懊惱的是決策過程，而不是結果。

職涯階梯仍然重要，但硬性限制勝過繁複的評分矩陣

Larson 依然相信職涯階梯，因為有評分矩陣總比沒有更能做出公平的決定；沒有它，維護性工作和黏合性工作（glue work）相對於風光的產品上線就會被低估。但他對許多公司直接買現成階梯的做法存疑，稱之為「真的很過時」，也對虛假的精確度存疑：「Eng1 和 Eng2 到底差在哪裡？……我覺得那其實很難講得非常具體。」

比起包山包海的標準，他更偏好硬性限制。在 Carta，面對成本壓力，他對 staff 工程師佔總人力的比例設了硬上限——「我們的 staff 工程師不能超過這個數字」——這逼得招募必須往漏斗更前端走，找資歷較淺的人，從而建立人才管道。他拿 Imprint 對比：那裡要的是速度與品質而不是成本，所以沒有這種比例。他的領導心得是：「知道自己在做什麼、說明你怎麼做，然後讓人們接受後果。」

他警告評分矩陣會被鑽漏洞——在某家公司，staff 晉升的導師要求，養出了一批「收集 mentee」的人，而那些被找上的人根本不太清楚自己為什麼被找。談到 AI 與初階職級，他指出有了寫程式的輔助工具，初階工程師「什麼都做得出來，但真正難的是判斷這件事該不該做」，而且在錯誤的情境下，「你甚至看不出他們的判斷力。」

寫作是一個人能對整個產業發揮最大槓桿的事，而 AI 垃圾內容正在糟蹋它

Larson 在網路上寫作近 20 年，2007 年開了 irrationalexuberance.com，寫教學文，目的是靠寫作建立人脈、找到工作。他把產出加速歸功於 Stripe 的寫作文化，也把四本書——《The Elegant Puzzle》、《Staff Engineer》、《Crafting Engineering Strategy》以及另一本——視為形塑了產業談論資深個人貢獻者（IC）的方式。他說「staff plus」這個概念出自《Staff Engineer》，而且沒有任何一個公司職位能帶來同樣的影響力。

他斬釘截鐵地說自己不用 AI 寫作：「用 AI 寫作等於把那些全部丟掉。」他的論點是經濟性的，不是浪漫情懷——他花了數萬小時建立可信度，AI 生成的文章會是「一筆沒有回報的損失」，因為根本沒人會讀。他也反駁「影響力需要產量」這個前提：一篇真正打動人的文章，勝過 200 篇沒人理的；他舉 Tanya Reilly 量少但影響力大的部落格寫作（他點名〈Being Glue〉）為典範。他說他面試過大量產出 AI 內容的求職者，並把這種做法解讀為判斷力不佳——「盲目模仿……他們其實不知道自己為什麼要這樣做。」

Orosz 補充，寫作是他思考的方式，而用一位寫作者過去的作品訓練出來的 AI，只會 regurgitate 過時的立場——一個「Will Larson 機器人」到現在還會說 TLM 是職涯陷阱，而 Larson 本人早已修正了這個說法。

Larson 在讀什麼，以及藏在一切底下的驗證問題

他的推薦書單：Donella Meadows 的《Thinking in Systems: A Primer》，他說這本書形塑了他對管理以及在公司內部運作的理解；Hillel Wayne 談 TLA+ 的書（Wayne 先前上過這個節目）；以及談型別系統的書。串起這些書的主線是可驗證性。如果代理寫掉愈來愈多軟體，「讓驗證變便宜就非常關鍵」；即使 TLA+ 不是那個工具，用語言來提高可驗證性的思維，也是這個時刻最大的挑戰之一。

整集的綜合結論是：Larson 所說高階主管能力的兩半——技術細節與官僚技藝——正好就是 AI 正在不均勻顛覆的兩件事。代理擅長寫程式這種細節工作，卻不擅長官僚所處理的隱含取捨與制度設計。正因為這種不對稱，他認為仍摸得到細節的一線主管，比那些被教了十年「別碰技術」的中階主管更有勝算。尚未解決的張力是：他現在偏好的扁平組織，還能不能把官僚那一半教給任何人——他自己的答案，是在帶過 250 人的團隊之後去接 25 人的團隊，先重新學會技術那一半，再相信其餘的會跟著來。值得持續追蹤的是：Imprint 那套由工程主導的設計模式，以及它從 Jira 遷移到 Linear 的專案（他說不到四週就完成，而且當時內部幾乎一面倒懷疑），能不能站得住腳，成為他那套「賦權贊助者」出貨理論的證據。