管的是管人的人，不再是人本身。因此動作與結果之間隔著至少兩層，回饋延遲以季為單位——這一格的判斷幾乎都要在確認得到結果之前就下。要判斷的東西落在團隊與團隊之間：邊界畫在哪、交接面誰負責、哪些事情沒有人特別該負責但一定會出問題。

改組織圖而沒有改任何人的實際約束，是這個位置代價最高的失敗。畫新的框、宣布新的分工，隔天每個人面對的優先序、被誰打斷、被誰評分都沒有變。三個月後一切照舊，信任被消耗掉一次。與它相鄰的是把每一個跨團隊問題都當成溝通問題處理——那個解釋的吸引力在於它不必動結構。

對組織結構負責時，成文制度與否的差別

制度成文的大組織裡，這個位置的動作要穿過既有制度，於是變更成本高到讓錯誤結構被保留。具體長這樣：某個服務跨在兩個團隊的邊界上，每改一次都要兩邊各自排期，通常差兩到三週；提議把它併進其中一邊，就要動另一邊的 headcount，而 headcount 綁在年度預算裡、還要說服兩位主管跟他們共同的上級；於是這件事每季被提一次，每次都合理地被延後。這裡需要的是判斷哪些結構債值得付這個代價去修，哪些改用介面設計繞過——把跨團隊的協作改成一方提供穩定介面、另一方自助使用，不動組織圖也能減少排期依賴。

制度還沒定型、但層級已經出現的公司（人數常落在五十到兩百之間，但決定性的是制度而非人數）問題相反：改組織幾乎沒有成本，於是改得太頻繁。每次重組都重置一次團隊的默契與領域知識；那個成本不會出現在任何報表上。這裡需要的是知道重組的代價在哪裡、以及什麼訊號才真的構成重組的理由。

這個位置該讀什麼

Team Topologies（Skelton & Pais）是這個位置的主要書。它在這個位置的用途是把切分決定寫成別人可以反駁的形式——這條路線的決定會被上下兩層檢視，而「我覺得這樣切比較好」擋不住任何一次質疑。書的完整描述在主題篇。

An Elegant Puzzle（Will Larson）處理的是這裡的日常：團隊規模怎麼定、技術債怎麼排進計畫、接班怎麼安排、組織成長時哪些結構會先斷。它的團隊狀態模型在這個位置的用途是分配資源時的共同語言：這裡的判斷單位是團隊之間的介面，而爭資源的場合需要一個雙方都認的分類，否則討論會退回誰的嗓門大。模型本身的四種狀態與各自的介入方式在主題篇。

How Big Things Get Done（Flyvbjerg & Gardner）處理的是這個位置躲不掉的承諾問題。它區分的兩個失準來源對這條路線特別重要，因為到這裡的所有估算都經過至少兩層轉述，每一層都有調整它的誘因——分不出手上這個數字失真在哪一層，加再多緩衝也押錯地方。兩個來源各是什麼、為什麼其中一個靠方法修不了，在主題篇。

The Fearless Organization 在這個位置讀出來的東西，跟直接帶人的人讀到的不同。這裡的問題是壞消息在兩層轉述中會不會被磨平——每一層都做了合理的摘要，而合理的摘要累積起來就是失真；自己的團隊敢不敢講是 對人負責 那一篇的題目。

Quality Software Management, Vol. 4（Gerald Weinberg，繁中譯名《溫伯格的軟體管理學：擁抱變革》，四卷各自獨立、不必從第 1 卷讀起）處理推動組織轉變時的人的阻力，是這條路線上唯一一本把抗拒當資訊而不是當障礙的書。完整的性質判定與讀的時機在主題篇。

想往哪裡走

進到這個位置的方式通常是組織長大，而不是換了工作內容——原本帶的一個團隊裂成兩個，人就在這裡了。準備好的訊號是兩個團隊之間的事已經在處理：協調誰做哪一段、決定介面長什麼樣、被找去仲裁優先序。沒有這些累積就直接接下多團隊，最常見的結果是把時間全部花在其中一個團隊上，因為那是唯一熟悉的工作。

這個位置往上走，書能提供的比重快速下降。位置越高，同一個職稱在不同公司對應的實際工作差異越大，決定成敗的是這個組織的規模、產業與治理結構，而那些沒有通用解。

比較有用的方向是往深處而非往上：Wiring the Winning Organization 嘗試解釋為什麼同樣的工作在某些組織裡很難、在另一些組織裡很簡單，適合手上已經有一批彼此不相干的做法、想找共同解釋的人。Software Engineering at Google 提供的是規模與時間如何反轉工程判斷的具體案例，可以拿來校準自己組織的規模對應到哪些問題。

要把結構決定落到實際的評估動作，發射管制隊視角：評估工作團隊設計 提供的是把這類框架用在既有團隊上的判讀步驟。