事件起點：一個 1967 年的觀察，至今仍在每家公司上演
Melvin Conway 在 1967 年發表了一篇幾乎被退稿的論文，裡面有一句話後來被稱為「軟體業最被低估的定律」：
> *「系統設計者所產出的設計，必然 mirror 該組織的溝通結構。」*
他舉的例子極其具體：如果你把寫 compiler 的工作分給 4 個 team，最後你一定會得到一個 4-pass compiler，無論技術上有沒有必要這樣做。組織的切割方式，決定了產品的切割方式。
這不是比喻，是一個關於資訊流動的鐵律。
為什麼這會發生：溝通成本驅動架構決策
工程師做設計決策時，幾乎從不在真空中操作。他們面對的是：哪個 team 擁有哪個 codebase、誰跟誰開會很貴、API 邊界定在哪裡讓我的 team 不用等別人。
在這樣的現實下，介面（interface）往往不是根據最佳技術設計來劃分，而是根據最小化跨 team 協調成本來劃分。 這是完全理性的個人決策，但累積起來，就把組織結構直接烙印進了產品。
Microsoft 早期的 Office 就是教科書案例。Word 有自己的格式引擎、Excel 有自己的渲染邏輯、Outlook 有自己的資料模型——三者幾乎不共享底層基礎設施。對使用者而言，這三個產品在同一個公司出品，卻像三個陌生人。原因不是工程師不夠聰明，而是三個 team 彼此的溝通成本太高，高到各自關起門來做才是最理性的選擇。
Bezos 的反擊：用組織指令重寫架構
2002 年，Jeff Bezos 發出了一封現在被稱為「Bezos Mandate」的內部信，內容大致如下：
1. 所有 team 必須透過 service interface 暴露資料與功能 2. Teams 之間只能透過這些 interface 溝通 3. 不允許任何其他形式的 IPC（interprocess communication） 4. 違者開除
這封信的技術意圖，是強制 Amazon 建立 service-oriented architecture（SOA），也就是後來 AWS 的基礎。但更深層的邏輯是：Bezos 在用組織指令對抗康威定律——他知道如果不強制規定 team 的溝通方式，產品架構就會自然長成組織的形狀。
結果是 Amazon 的工程 team 在被迫設計對外 API 時，同時也在訓練自己建立真正模組化的系統。AWS 的誕生，某種程度上是這個組織實驗的副產品。
逆康威策略：先想清楚產品，再設計組織
康威定律原本是一個「這就是現實」的觀察，但被聰明的人反轉成一個設計工具：如果產品架構必然反映組織架構，那就先設計你想要的產品架構，再倒推出你應該有的組織結構。
這個策略有時被稱為「Inverse Conway Maneuver」（逆康威操作），在現代微服務架構的推廣中被廣泛引用。
實務上的含義： - 一家 startup 想做高度模組化、可插拔的平台？→ 從第一天就不要讓工程師橫跨所有模組，建立清晰的 team 邊界與 API 契約 - 想讓前後端高度解耦？→ 先確認前後端 team 之間有清晰的介面協議，而不只是「大家坐在一起溝通」 - 想做跨平台產品（Web/iOS/Android 行為一致）？→ 不要讓三個 platform team 各自為政，需要共享一個 product spec 流程
組織結構是最被低估的架構決策。 大多數公司花大量時間討論技術選型，卻在 hiring 和 team 劃分時隨機應變——而康威定律告訴你，後者其實比前者更決定性。
超越軟體：康威定律的普適版本
康威定律本質上在說的，是一個更古老的道理：任何複雜系統的輸出，都受限於產生它的溝通網絡的形狀。
這在軟體之外同樣成立： - 一部由多個導演聯合執導的電影，往往在敘事上有明顯的風格斷裂點 - 一份由多個部門聯合撰寫的政策報告，往往在邏輯上有縫隙——每個縫隙正好是一個部門的邊界 - 一個由多個國家聯合開發的武器系統（如早期歐洲航太合作），往往在零件介面上出現奇怪的妥協設計
溝通結構塑造輸出結構，這是一個跨領域的原則。
給建造者的問題
在你現在的組織裡，有沒有一個讓你覺得「這個介面設計得好奇怪」的地方？現在問自己：這個介面是技術決策，還是組織邊界的化石？