原章：Organizing — Separable, Single-Threaded Leadership
Amazon 變大之後，一個看似合理的問題開始反覆出現：專案需要愈來愈多團隊一起合作。Colin 回憶自己管理 Amazon Associates 時，即使只想改善追蹤與支付推薦費的流程，也會碰到共用程式碼、資料庫與其他團隊的優先順序。每個依賴本身都合理，但全部加在一起，組織就變慢了。
一般公司遇到這種問題，很自然會想「改善協調」。Amazon 最後得到的結論卻相反：如果協調本身是問題的一部分，那真正的解法也許不是更好的協調，而是讓某些工作不再需要協調。
Amazon 先嘗試 New Project Initiatives（NPI）制度，把需要跨團隊資源的專案集中排序。它確實讓公司可以做全域優先順序，但代價是團隊要反覆爭取資源、估算回報、等待核准；沒有被選上的團隊也容易士氣低落。
Jeff 接著提出 Two-Pizza Team：團隊要小、自治、有自己的指標、能即時監控、對業務結果負責。這個實驗推動 Amazon 拆掉部分單體系統並建立更自治的產品團隊，但它也暴露新問題：不是所有工作都適合小團隊；複合式「fitness function」有時比單一指標更難用；能同時懂技術、產品與管理的優秀小隊主管也很稀缺。
最後演化出的不是「兩個披薩」這個人數規則，而是 Single-Threaded Leader（單線領導者）：由一位領導者把主要注意力放在一個明確任務，並配上一個盡可能可分離、可以自己前進的團隊。
| 故事節點 | Amazon 當時的解法 | 為什麼不夠 | 下一步學到什麼 |
|---|---|---|---|
| 跨團隊依賴增加 | 更多協調與溝通 | 溝通本身消耗速度 | 要思考如何消除依賴 |
| NPI | 全公司集中排序專案與資源 | 流程沉重、士氣受影響，團隊仍依賴共享資源 | 全域排序不是最終答案 |
| Two-Pizza Team | 小型自治團隊 | 並非所有工作都適合，領導者與衡量方式也成為瓶頸 | 真正核心不是團隊大小 |
| Single-Threaded Leader | 一位領導者只專注一項任務，團隊盡量可分離 | 需要清楚邊界與真正授權 | 專注與所有權比形式上的小團隊更重要 |
組織成長後最稀缺的資源之一是高階注意力。若一個主管同時負責核心業務、日常營運與新事業，新事業即使「很重要」，也常永遠排在今天最急的事情後面。
Amazon 逐步把組織設計從「所有人合作把事做完」改成「誰真正擁有這件事，而且他能不能不依賴太多人就把它做完」。作者以 Fulfillment by Amazon 等例子說明，當一位領導者真正有單一任務與對應團隊後，原先一直推不動的工作才有機會加速。
Two-Pizza Team 並沒有原封不動成為 Amazon 所有部門的固定模板，但它促成更成熟的單線領導者制度。作者認為，這種模式讓 Amazon 即使規模龐大，仍能維持較高的創新速度。
很多組織問題被誤認為「溝通問題」，但其實是結構讓太多人必須彼此等待。若依賴不變，再好的會議、專案管理與協作工具也只能減輕症狀。