團隊該多大:6 到 8 這個數字在買什麼

「團隊該幾個人」聽起來像 HR 的題目——其實它是這本書第一個、也是最有操作性的系統設計題。Larson 給的數字很直接:一個 manager 帶 6 到 8 個工程師,一個帶 manager 的 manager 帶 4 到 6 個 manager。

但數字本身不是重點。重點是每個區間會把你這個 manager 變成一個完全不同的角色——而且多數人是在人數已經錯了之後,才發現自己的工作內容不知不覺換了一種。

6 到 8:這個數字在買什麼

先看整條軸。人數不是「你管得動幾個」的極限測試,而是你每週還剩多少時間做投資型的事:coaching、寫策略、推動跨團隊的改變。

把四個區間攤開來講:

直屬人數	你實際變成什麼	代價
少於 4	TLM(tech lead manager)——還在分擔設計與實作	Larson 講得很白:這個位置對某些人是強項的舞台,但職涯機會有限。它是一個位置,不是一個階段
4–5	勉強是一個團隊	輪替得動,但一個人請長假就見底(下一節專講)
6–8	投資者——時間夠做 active coaching、協調、寫策略、推動改變	這是 Larson 給的甜蜜點,原因不是「管得動」,是投資型工作還塞得進行事曆
超過 8–9	教練 + 安全網——別人撞牆你接住	忙到沒辦法投資團隊、也沒辦法投資團隊負責的那塊領域。看起來很忙、很重要,但你已經停止改變任何事

這張表最值得停下來的一格是 9 人以上。它的症狀不是「有人沒被照顧到」——那太明顯了,反而會被處理;真正的症狀是你每天都很忙、每件事都有接到、但這一季你沒有改掉任何一個系統。對照第一篇講的:你變成了一台專門接事件的機器,而源頭一根寒毛都沒動。

下限比上限更重要:少於四個人,不是團隊

多數人講團隊規模只講上限——「超過幾個人就該拆」。Larson 反過來也給了下限,而且措辭很狠:少於四個人的團隊是一個會漏的抽象(leaky abstraction),行為上跟個人沒兩樣。

「抽象會漏」在這裡是精準的技術比喻:你以為你在跟一個團隊講話,實際上你在跟某個人講話。團隊這層抽象本來要提供的東西——能輪替、能吸收波動、能在某個人不在時繼續運作——三個人以下通通提供不了。一個人請假,團隊就不是「產能降 33%」,是某一塊區域直接停擺。

Larson 在這一節的原文(lethain.com 的〈Sizing engineering teams〉)其實算過這筆帳,而且是從輪值算的:要撐起兩層、24 小時的 on-call 輪值,大約需要八個人。 換句話說,真正的下限計算機是輪值:一個要 on-call 的團隊,人數不夠就沒有輪值表可言,只有「那個人」——他休假、他生病、他離職,系統就沒有人接。SRE 那篇講告警與 on-call 的機制,但機制的前提是有人可以輪;人數不足時,再漂亮的 runbook 都只是給同一個人看的。

所以三人以下的隊伍不是「小團隊」,是「一個人加上兩個幫手」。這不必然是壞事——很多階段就是這樣,而且跑得很快。壞的是你用團隊的語言去管理它:訂了團隊的 KPI、設計了團隊的流程、期待它有團隊的韌性,然後在那個人離職的那一天發現什麼都沒有。

團隊怎麼長出來:養到 8–10 再分裂,絕不開空團隊

那要怎麼從一隊變兩隊?Larson 的做法違反直覺,但邏輯很硬:先把現有團隊養到 8 到 10 人,再分裂(bud)成兩個 4 到 5 人的團隊——絕對不要先開一個空團隊再往裡面招人。

「絕不開空團隊」這條在小公司特別容易被違反,因為開一個團隊的名字幾乎零成本:寫進組織圖、開個 channel、指定一個 owner,就宣告成立了。但團隊是一種承諾,不是一個標籤——它一旦存在,就會有人把需求丟進去、把 roadmap 上的工作算給它;而它在真的招到人以前,唯一的產能來源是原團隊。

同樣的邏輯也適用於「我們人太多了,拆成兩隊吧」:把 8 個人拆成 4+4 是分裂,把 6 個人拆成 3+3 是同時製造兩個跟個人沒兩樣的隊伍,而且你還多了一條需要協調的邊界。多數團隊在拆之前該問的不是「幾個人」,是「這兩塊工作真的可以獨立走嗎」——不行的話,拆完只是把原本的內部溝通變成跨團隊溝通,成本翻倍。

管理幅度不等於人頭

書的第 4 章有一節專門講 managerial scope(管理幅度),和這章配起來讀剛好補上一個常見誤會:想成長不是去要更多人頭,是去接更重要、更複雜的一塊。

這節的實用價值在於它給了一條不需要組織擴張也能成長的路:接下沒人想接的爛攤子、接下跨團隊的協調、接下一塊會上新聞的系統。人頭要等公司長大才有,scope 往往只需要你舉手。

順帶劃一條線:這裡的「管理幅度」和我在責任漏斗裡講的「頸寬」不是同一件事——scope 是你負責的面積,頸寬是你驗收的頻寬;面積變大而頻寬沒跟著變,結果就是你簽了一堆自己沒看懂的東西。

四個工程師版

這一章對四人團隊最有用的,不是叫你去湊到 6–8 人(你湊不到),而是三件可以馬上做的事:

1. 承認你是 TLM,並且說出口。 四個人的 lead 沒有「離開產線」這個選項,這不是失敗,是這個規模的正常型態。但要誠實面對 Larson 那句「職涯機會有限」——TLM 是一個位置,不是一個會自動長大的階段;想成長,走的是 scope 那條路,不是等人頭。
2. 替下限買保險。 人數補不上,就用別的東西補抽象的漏:每塊區域至少兩個人碰過、決策寫下來而不是留在腦裡、輪值表就算只有兩個人也要有。目標不是變成真的團隊,是讓某個人消失時,系統不會跟著消失。
3. 不要為了「看起來像組織」而拆線。 四個人拆成 2+2,你不會得到兩個團隊,你會得到兩個個人加一條新的協調成本。

反思

商城線四個人,剛好卡在 Larson 說的下限上

那篇團隊的文章裡算過一次帳:六個工程師,但商城這條線實際上是四個——一個 backend lead(我)、一位後端、兩位前端,再加一位不寫程式、專職做 PM 的 CTO。前面十七章寫的所有系統,是這四個人做出來的。

用這章的標準回頭看,這個編制剛好踩在下限線上:再少一個人,團隊這層抽象就漏光了。而這種脆弱有個特性:平常看不見——人都在的時候,團隊看起來就是一個團隊;要等到有人請長假、有人遞辭呈,才會知道每一塊實際上是靠誰撐著。這正是〈四個工程師版〉第二條要買的那份保險:每塊區域至少兩個人碰過。

後來的發展是:暫停開發一個月後,團隊剩下三個人——我、一個前端、CTO。按這章的標準,這已經不是「勉強是團隊」,而是跟個人沒兩樣。

TLM 是被規模推上去的位置,不是會自己往上走的路

我自己的軌跡,在團隊那篇裡記過:最早後端只有我一個,招到第二個後端那天,我開始做 lead。小團隊的 lead 沒有「離開產線」這個選項——維持高輸出之外,多扛三個把關點:task 的技術拆解(工作的入口)、review(程式碼的出口)、技術選型(系統的邊界)。

對照這章,這段工作內容很接近 Larson 說的 TLM——還在分擔設計與實作,同時要替團隊的產出把關;也就是前面那張表裡,寫著職涯機會有限的那一格。這個角色是跟著人數一起出現的,而跟著人數出現的位置有個內建的陷阱:它很容易被誤認成一條會自動往上走的路,好像只要把 lead 該做的事做好,下一階就會自己出現。

這章給的出口不是人頭,是 scope。對一個四人團隊的 lead 來說,最近的那塊 scope 往往就在隔壁:另一條線、兩條線之間的技術邊界、沒有人負責的那段串接。人頭要等公司給,scope 只要舉手。

拆線就是拆組織,而且資訊邊界會跟著長出來

同一篇也寫了商城與選標兩條線:各有各的人、各有各的 PM,到那篇為止的十七章裡,選標幾乎沒有登場,唯一有故事的那一次還是二手轉述——那篇講得很白:選標系統我不熟。同一篇的反思裡,還有我自己的一句話:「這件事當年看是分工自然,現在看是伏筆:組織怎麼分,系統就怎麼長;牆砌在哪裡,拆分線就落在哪裡。」

把這句話放進這一章的脈絡:當你把人分成兩堆,你同時也在決定誰會知道什麼。Conway 定律講的是組織形狀會長進系統裡,但反過來也成立——組織的邊界會決定資訊的邊界,而資訊的邊界最後會變成人的邊界。一條線的人不熟另一條線,是這種邊界的預設結果。

所以「要不要拆成兩隊」從來不只是人數問題,也是在決定這兩塊從此以後是不是只靠會議溝通。拆之前值得先問一句:拆完之後,兩邊的人還會不會讀對方的 code? 答案是不會的話,這條邊界的成本就不只是一次重組——人數會再長,邊界一旦立起來就很難拆掉了。