《亞馬遜逆向工作法》消化輸出 - 5
可分拆的單一執行團隊
爆炸性的成長，很快的就帶來了爆炸性的依賴關係。不只是開發上的依賴關係，也包含組織/資源的依賴關係。人多事情就多，一心多用的需求，讓所有的發明及執行效率注定變得停滯不前。
首先是開發上的依賴，像是常見的共享程式碼機制，這造成每個團隊都受到一定的牽制，只要我們想變更共享程式碼的部分，就得跟原開發團隊協商討論，看修改是否安全，反之亦然。共享資料庫更是如此，任何對資料庫設計想提出變更的提案，都必須"被批准"才有可能改變，也就是風險低的，值得去做的，被批准的可能性才會比較高。不管是哪種狀況，都得開上好幾次會，等候審查才行。「共享」的好處，在開發人數規模變大的狀況下，就會變成動彈不得的致命傷。
組織/資源上的依賴，更是令人喪氣的難題。每個團隊在無法自給自足的前提下，都需要別的團隊分配資源來協助完成自己的目標，反過來自己的團隊也是會收到許多其他團隊的需求。每個團隊都需要花上大把的時間去調整，要花多少時間在自己和別人的專案。許多辦公室政治說穿了就是資源分配問題，人越多這種問題就越嚴重。
貝佐斯真的是比軟體開發者更像開發者，面對這樣的問題，他很快的看出root cause為何：「追求更有效的溝通」的本身就是問題。亞馬遜自然也試過許多以組織或以個人為單位的流程或制度，嘗試去達到"更有效"的溝通。但成等比級數上升的溝通成本，無論用什麼方法都不會有效抑制，人太多，組織太多。貝佐斯提出的解法，就是許多人聽過的「API Mandate」。也就是專注在「服務」的介面上，把「人」給徹底抽離，讓所有的溝通成本從原本的等比/等差成長，瞬間變成常數值。
書中餐館的例子非常具像化。我們去餐館吃飯，並不會直接跑進廚房拿東西吃，而是找服務生，看菜單，等餐點送上來。這全程服務生可以換人，菜單可以更新，餐點怎麼做是廚房內的事情，餐點只要送得過來，我們都不會在意，都會欣然享用眼前的美食。
我本來是在亞馬遜的高效會議原則中，聽到「2個比薩團隊」這個名詞的。起初，我本以為這是指高效會議的與會人數，不能超過2個比薩餵不飽的人數。但原來2個比薩團隊只是「單一執行團隊」的前身而已，主要的訴求也只是想要以「小」團隊去嘗試優化溝通及執行效率。但最終確定的是，其實人數並不是主要的問題，問題是在於這個團隊是否有足夠的自主權，以及是否有一個具執行力及經驗的領導人。如果這個團隊不能將依賴性降到最低，它的執行力及彈性就不能獲得最好的成效。
這一段的面向很廣，歷史很多，但濃縮起來的觀念可用一句話描述，就是「降低依賴」。