Viết trước

Kiến trúc phần mềm của bạn không phải do đội kỹ thuật “thiết kế” ra, mà là do kiến trúc tổ chức của bạn “mọc” ra. Định luật được đề xuất năm 1968 này đang được lặp lại chứng minh trong thời đại AI.
Nghiên cứu thực nghiệm từ Trường Kinh doanh Harvard chứng minh: Khoảng cách tổ chức dự đoán tỷ lệ lỗi phần mềm tốt hơn cả độ phức tạp mã nguồn. Những gì bạn tưởng là “nợ kỹ thuật”, thực chất có thể là “nợ tổ chức”.
Đế chế vi dịch vụ của Amazon, mô hình đội nhỏ của Spotify, bế tắc của Siri tại Apple — ba công ty trị giá hàng nghìn tỷ đô la đã dùng số phận hoàn toàn khác nhau để minh họa cùng một định luật.
Các đại diện AI đang bước vào sơ đồ tổ chức. Khi các “nút” trong đội ngũ không còn toàn là con người, Định luật Conway sẽ được viết lại theo cách bạn không ngờ tới.

Năm 1968, một lập trình viên vô danh viết một bài luận, bị Harvard Business Review từ chối vì “chưa chứng minh được luận điểm”. 56 năm sau, quan điểm cốt lõi trong bài luận này đã trở thành định luật được cả ngành phần mềm công nhận — và vào năm 2026, khi AI đang tái định hình mọi thứ, nó còn quan trọng hơn bao giờ hết.

Một: Bài luận bị từ chối trở thành “định luật vạn vật hấp dẫn” của kỹ thuật phần mềm

Tiên tri bị HBR khước từ

Tháng 4 năm 1968, Melvin Conway đã công bố một bài báo trên tạp chí Datamation với tiêu đề khiêm tốn: “How Do Committees Invent?” (Các ủy ban sáng tạo như thế nào?).

Lập luận cốt lõi của bài báo chỉ gồm một câu, nhưng đủ khiến bất kỳ CTO nào cũng trằn trọc suốt đêm:

“Các tổ chức thiết kế hệ thống sẽ tạo ra các thiết kế phản ánh chính cấu trúc giao tiếp của tổ chức đó.”

Nói một cách dễ hiểu: Sơ đồ tổ chức của công ty bạn chính là bản sao của sơ đồ kiến trúc phần mềm của bạn.

Conway mô tả một ví dụ tinh tế trong bài báo: Một công ty giao cho 8 người chia thành hai nhóm để xây dựng hai trình biên dịch: một nhóm 5 người và một nhóm 3 người. Kết quả? Nhóm 5 người tạo ra một trình biên dịch 5 giai đoạn, nhóm 3 người tạo ra một trình biên dịch 3 giai đoạn. Không phải vì kỹ thuật đòi hỏi phải chia thành các giai đoạn như vậy, mà vì — mỗi người đều cần “sở hữu” một đơn vị công việc riêng của mình.

Conway diễn đạt mối quan hệ này bằng ngôn ngữ toán học là “homomorphism” — tồn tại một ánh xạ bảo toàn cấu trúc giữa cấu trúc tổ chức và thiết kế hệ thống. Đây không phải là sự trùng hợp, cũng không phải ngẫu nhiên, mà là một quy luật mang tính toán học gần như tất yếu.

Thú vị thay, Conway ban đầu đã gửi bài luận này đến Harvard Business Review, nhưng biên tập viên đã từ chối với lý do “chưa chứng minh được luận điểm”. Bảy năm sau, Fred Brooks đã trang trọng trích dẫn quan điểm này trong tác phẩm kinh điển The Mythical Man-Month, và chính thức đặt tên cho nó là “Định luật Conway” (Conway’s Law).

Từ đó, một quan sát bị các tạp chí kinh doanh hàng đầu từ chối đã trở thành một trong những định luật được trích dẫn rộng rãi nhất trong lĩnh vực kỹ thuật phần mềm. ## “Lời kết luận cuối cùng” của Martin Fowler

Nếu Conway là Copernicus đưa ra giả thuyết, thì hai thập kỷ nghiên cứu thực nghiệm chính là kính thiên văn.

Năm 2022, nhà khoa học hàng đầu của ThoughtWorks, Martin Fowler, đã viết một nhận xét được cộng đồng rộng rãi lan truyền: “Nếu trong lĩnh vực kiến trúc phần mềm có một nguyên tắc mà mọi thực hành viên đều đồng thuận, thì đó chính là Định luật Conway. Nó quan trọng đến mức ảnh hưởng đến mọi hệ thống tôi từng thấy; nó mạnh mẽ đến mức bất kỳ ai cố gắng chống lại nó đều chắc chắn thất bại.”

Đây không phải là một suy luận lý thuyết trong tháp ngà của một học giả. Fowler đã lặp lại hiện tượng này hàng trăm lần trong các dự án tư vấn toàn cầu: sơ đồ tổ chức chính là bóng đổ của bản thiết kế phần mềm — bất kể ban lãnh đạo có nhận ra điều đó hay không.

Ở đây có một ý nghĩa tinh tế nhưng then chốt mà nhiều người bỏ sót: Fowler nói rằng “bất kỳ ai cố chống lại nó đều chắc chắn thất bại”, chứ không phải “bất kỳ ai cố sử dụng nó”. Sự khác biệt ở đâu? Chống lại Định luật Conway có nghĩa là ép buộc thay đổi kiến trúc mà không thay đổi cấu trúc tổ chức; còn sử dụng nó có nghĩa là điều chỉnh tổ chức trước, để kiến trúc “phát triển tự nhiên”.
Sự khác biệt này quyết định thành bại của các dự án chuyển đổi số. Chúng ta sẽ trình bày chi tiết chiến lược then chốt “Inverse Conway Maneuver” trong bài thứ hai về Team Topologies — về bản chất, đó là cách tận dụng chứ không chống lại định luật này.

II. Từ phòng thí nghiệm đến chiến trường: Ba nghiên cứu củng cố vững chắc định luật này

Giả thuyết “Ảnh phản chiếu” của Trường Kinh doanh Harvard

Năm 2012, MacCormack và các đồng nghiệp tại Trường Kinh doanh Harvard công bố một nghiên cứu trọng điểm, được giới học thuật gọi là “Giả thuyết ảnh phản chiếu” (Mirroring Hypothesis).

Phương pháp nghiên cứu rất tinh vi: họ tìm kiếm các phần mềm thương mại và phần mềm mã nguồn mở thực hiện chức năng hoàn toàn giống nhau để so sánh. Phần mềm thương mại được phát triển bởi các đội ngũ doanh nghiệp có cấu trúc phân cấp, trong khi phần mềm mã nguồn mở được phát triển bởi các cộng đồng phân tán lỏng lẻo.

Kết quả đúng như dự đoán của Định luật Conway: sản phẩm do các tổ chức có độ gắn kết lỏng lẻo phát triển có tính mô-đun rõ rệt hơn nhiều. Các đội ngũ doanh nghiệp gắn kết chặt chẽ, dù có chủ ý theo đuổi thiết kế mô-đun, cuối cùng vẫn tạo ra hệ thống thể hiện đặc tính gắn kết chặt chẽ phù hợp với cấu trúc tổ chức của họ.

Cấu trúc tổ chức giống như một “trường hấp dẫn” — bạn có thể chống lại nó trong thời gian ngắn, nhưng theo thời gian, kiến trúc hệ thống sẽ bị kéo trở lại trạng thái đồng cấu với cấu trúc tổ chức.

Thông điệp thực sự dành cho nhà ra quyết định doanh nghiệp từ nghiên cứu này là gì? Khi đội kỹ thuật của bạn liên tục nói “Chúng ta cần重构”, điều thực sự cần “重构” có thể không phải là mã nguồn, mà là tổ chức. Nhưng làm thế nào để phân biệt giữa “nợ kỹ thuật” và “nợ tổ chức”? Cần một phương pháp chẩn đoán hệ thống — chúng tôi sẽ cung cấp mô hình đánh giá đầy đủ trong Bài 12: “Khung quyết định áp dụng công cụ AI trong phát triển doanh nghiệp”.

Thí nghiệm “Windows Vista” của Microsoft Research

Năm 2008, Nagappan và các đồng nghiệp tại Microsoft Research đã thực hiện một nghiên cứu định lượng quy mô lớn về dự án Windows Vista. Họ cố gắng trả lời một câu hỏi then chốt: yếu tố nào dự đoán chính xác nhất các lỗi (bug) trong phần mềm?

Các ứng cử viên bao gồm: độ phức tạp mã, số dòng mã, tần suất thay đổi mã, kinh nghiệm của nhà phát triển… và một biến số dường như không liên quan đến “kỹ thuật” — khoảng cách tổ chức (tức là khoảng cách trong cấu trúc tổ chức giữa các đội phát triển các mô-đun liên quan).

Kết luận nghiên cứu khiến nhiều người theo chủ nghĩa công nghệ cảm thấy lo lắng: Khoảng cách tổ chức dự đoán tỷ lệ lỗi phần mềm tốt hơn độ phức tạp của mã nguồn. Nói cách khác, các mô-đun được phát triển bởi hai nhóm “ở xa nhau” trên sơ đồ tổ chức sẽ dễ gặp lỗi hơn so với các mô-đun cực kỳ phức tạp nhưng được duy trì bởi nhóm hợp tác chặt chẽ. Bạn nghĩ lỗi là do mã viết xấu, nhưng thực ra có thể do thiết kế tổ chức kém.

Khía cạnh doanh nghiệp của phát hiện này sâu sắc hơn nhiều so với vẻ ngoài. Nó ngụ ý rằng — chiến lược QA của bạn nên theo cấu trúc tổ chức, chứ không phải theo độ phức tạp mã nguồn. Các mô-đun cần hợp tác giữa các nhóm cần được kiểm thử và đánh giá kỹ lưỡng hơn, ngay cả khi mã nguồn trông đơn giản. Trong bối cảnh mã do AI tạo ra đang bùng nổ ngày nay (Copilot hiện đang tạo ra 46% mã do người dùng viết), nguyên tắc này càng trở nên then chốt — chúng ta sẽ phân tích chi tiết trường hợp của Coinbase khi bàn đến “nghịch lý năng suất” ở bài thứ 8.

“Tăng tốc” và “Nỗi lo ẩn” từ nghiên cứu DORA

Đội nghiên cứu DevOps Research and Assessment (DORA) thuộc Google, do Nicole Forsgren, Jez Humble và Gene Kim dẫn dắt, đã công bố nghiên cứu hiệu suất giao phần mềm lớn nhất từ trước đến nay.

Phát hiện cốt lõi trùng hợp chặt chẽ với Định luật Conway: “Nếu chúng ta triển khai kiến trúc có độ gắn kết lỏng và đóng gói tốt, kết hợp với cấu trúc tổ chức tương ứng, chúng ta không chỉ tăng tốc độ và độ ổn định trong giao hàng, mà còn duy trì sự tăng trưởng năng suất tuyến tính hoặc thậm chí vượt tuyến tính khi đội ngũ kỹ sư mở rộng đáng kể.” Tuy nhiên, báo cáo DORA năm 2022 cũng phát hiện một tác dụng phụ đáng chú ý: kiến trúc có độ gắn kết lỏng dù nâng cao hiệu quả giao hàng, nhưng có thể làm tăng cảm giác kiệt sức trong đội ngũ. Nguyên nhân có thể là: khi các đội tự chủ cao và cách ly lẫn nhau, thành viên có thể đánh mất cảm nhận về ý nghĩa tổng thể, sinh ra cảm giác “Tôi chỉ là một chiếc bánh răng”.

Đây là lời nhắc nhở quan trọng — việc đồng bộ kiến trúc và tổ chức không phải là viên đạn bạc; nó giải quyết vấn đề hiệu suất, nhưng có thể tạo ra vấn đề văn hóa. Một suy luận sâu sắc: nếu kiến trúc gắn kết lỏng + tổ chức gắn kết lỏng đã khiến các nhà phát triển con người cảm thấy cô lập, thì điều gì sẽ xảy ra khi chúng ta thêm các đại diện AI vào đội ngũ? AI không “cảm thấy cô lập”, nhưng con người sẽ càng cô lập hơn. Góc nhìn này hiếm khi được bàn đến, nhưng trong tài liệu nghiên cứu của chúng tôi, một báo cáo của BCG năm 2025 đã nêu ra “khó khăn trong điều phối của các nhà quản lý cấp trung” — đây cũng là chủ đề trung tâm của bài viết số 11 của chúng tôi.

Ba. “Thời điểm Conway” của ba công ty trị giá nghìn tỷ USD

Amazon: Một email của CEO thay đổi tất cả

Vào khoảng năm 2002, Jeff Bezos đã gửi bức thư nổi tiếng “API Mandate” nội bộ tại Amazon — tất cả các đội phải giao tiếp thông qua giao diện dịch vụ (API), và tuyệt đối cấm các đội truy cập trực tiếp vào kho dữ liệu của đội khác.
Câu cuối cùng trong bức thư được cho là: “Những người không tuân thủ các quy định trên sẽ bị sa thải.”
Nhiều người coi kiến trúc vi dịch vụ của Amazon là một quyết định kỹ thuật. Nhưng theo định luật Conway, điều Bezos thực sự làm là một quyết định tổ chức: ông trước tiên dùng các biện pháp quản lý để cắt đứt các “con đường tắt” trong giao tiếp giữa các đội, sau đó kiến trúc phần mềm tự nhiên phát triển thành các mô-đun dịch vụ tách biệt.

Đó chính là khái niệm “đội hai chiếc bánh pizza” (Two-Pizza Team) mà Bezos sau này đề xuất — quy mô mỗi đội không vượt quá số người có thể ăn no với hai chiếc bánh pizza (thường 5-8 người), mỗi đội sở hữu dịch vụ riêng, triển khai độc lập, và tương tác với bên ngoài thông qua API.
Đế chế vi dịch vụ của Amazon không phải do các kiến trúc sư vẽ ra, mà là do cấu trúc tổ chức “phát triển” ra. Đây là ví dụ kinh điển nhất về mặt tích cực của định luật Conway.

Nhưng ở đây có một khía cạnh mà nhiều bài viết không đề cập đến: sự thành công của Amazon không chỉ vì Bezos hiểu định luật Conway, mà còn vì ông đồng thời giải quyết được vấn đề “căn chỉnh động lực”. Mỗi “đội hai chiếc bánh pizza” đều sở hữu P&L (báo cáo lợi nhuận và tổn thất) riêng, không chỉ tự chủ về mặt kỹ thuật mà còn tự chủ về mặt kinh doanh. Điều này có nghĩa là các đội có động lực nội tại để duy trì ranh giới rõ ràng giữa các dịch vụ — vì ranh giới mờ nhạt đồng nghĩa với trách nhiệm mờ nhạt, và trách nhiệm mờ nhạt dẫn đến đánh giá mờ nhạt. Sự căn chỉnh tam giác giữa cơ cấu tổ chức + cơ cấu động lực + kiến trúc kỹ thuật mới là toàn bộ bức tranh của mô hình Amazon. Những doanh nghiệp chỉ học theo cơ cấu tổ chức mà bỏ qua thiết kế động lực, phần lớn chỉ bắt chước được hình thức chứ không nắm được tinh thần.

Spotify: Mô hình lý tưởng va chạm với “tăng entropy” thực tế

Mô hình “Squad” của Spotify từng được thung lũng Silicon tôn làm kinh thánh thiết kế tổ chức: các đội nhỏ tự chủ 5-8 người (Squad), nhiều đội hợp thành bộ lạc (Tribe), các chuyên gia kỹ thuật xuyên bộ lạc tạo thành hội nhóm (Chapter), và các cộng đồng dựa trên sở thích tạo thành hội (Guild).

Tư tưởng thiết kế这套 mô hình hoàn toàn nhất quán với định luật Conway — thông qua cấu trúc đội nhỏ và tự chủ, thúc đẩy ra các dịch vụ phần mềm nhỏ và tự chủ.

Nhưng Spotify sau đó cũng thừa nhận rằng thực tế phức tạp hơn nhiều so với mô hình. Khi quy mô kinh doanh tăng lên đến một mức nhất định, các phụ thuộc xuyên đội nhóm không thể tránh khỏi gia tăng, và sự tự trị thuần túy bắt đầu sinh ra chi phí phối hợp. Điều này làm nổi bật một hệ quả ít được chú ý của Định luật Conway: cấu trúc tổ chức không phải là thứ được thiết kế một lần rồi xong việc mãi mãi — nó cũng như phần mềm, có xu hướng “tăng entropi”. Khi độ phức tạp của doanh nghiệp tăng lên, các ranh giới tổ chức dần mờ đi, các tuyến giao tiếp trở nên dài hơn, và kiến trúc hệ thống cũng suy thoái theo. Một tổ chức công nghệ xuất sắc không phải là “đã thiết kế một kiến trúc tốt”, mà là xây dựng được khả năng điều chỉnh liên tục sự đồng bộ giữa tổ chức và kiến trúc. Khả năng này chúng ta sẽ mở rộng trong bài thứ 2 về Team Topologies — nó cung cấp một khung làm việc hệ thống và khả thi hơn mô hình của Spotify. ## Apple: Vì sao Siri bị ChatGPT “đánh bại”
Kế hoạch nâng cấp AI cho Siri của Apple trong giai đoạn 2024-2025 gần như trở thành “bài học ngược” của Định luật Conway.

Vấn đề không nằm ở công nghệ. Apple sở hữu đội ngũ nghiên cứu AI hàng đầu thế giới cùng nguồn vốn dồi dào. Nhưng việc phát triển Siri lại liên quan đến hai đội nhóm có sự rạn nứt cấu trúc trong cơ cấu tổ chức: đội nghiên cứu AI (do John Giannandrea dẫn dắt) và đội phát triển sản phẩm (do Craig Federighi dẫn dắt).

Hai đội nhóm này có những ưu tiên khác nhau, nhịp độ khác nhau, tiêu chuẩn thành công khác nhau. Đội nghiên cứu AI theo đuổi những bước đột phá về khả năng mô hình, trong khi đội sản phẩm theo đuổi việc giao hàng ổn định về trải nghiệm người dùng. Khi cấu trúc giao tiếp giữa hai “nút” tổ chức này bị cắt đứt, hệ thống đầu ra tất yếu cũng sẽ bị cắt đứt.

Siri mà người dùng cuối cùng nhận được là gì? Một “trợ lý tầm thường được ghép nối” — từng mô-đun trông có vẻ ổn, nhưng khi tích hợp lại thì thiếu đi trải nghiệm thông minh thống nhất. Đây chính là kết quả mà Định luật Conway tiên đoán: những vết nứt trong hệ thống phản chiếu những vết nứt trong tổ chức.

Ví dụ của Apple đặc biệt đáng chú ý với các nhà lãnh đạo doanh nghiệp Trung Quốc. Nhiều doanh nghiệp đang trải qua chính hoàn cảnh tương tự — đội AI và đội nghiệp vụ thuộc về các VP khác nhau, các dự án triển khai AI trở thành “cuộc đấu tranh chính trị giữa hai phòng ban” thay vì “sự phối hợp cùng giao hàng một sản phẩm”.

Nếu công ty bạn đang thúc đẩy việc ứng dụng AI, hãy quay lại nhìn sơ đồ tổ chức của bạn: năng lực AI tồn tại như một bộ phận độc lập, hay được nhúng vào các đội ngũ kinh doanh? Câu trả lời cho câu hỏi này có thể quyết định thành bại của dự án còn hơn cả việc bạn chọn mô hình AI nào.

Bốn: Thời đại AI — Định luật Conway đang được viết lại

Khi “nút tổ chức” không còn toàn là con người

Năm 2026, Định luật Conway đang đối mặt với thách thức sâu sắc nhất kể từ năm 1968. Khi Conway phát biểu về định luật này, ông có một tiền đề ngầm: mọi “nút” trong tổ chức đều là con người. Cấu trúc giao tiếp là giao tiếp giữa người với người.

Nhưng hôm nay, các đại lý AI đang bước vào sơ đồ tổ chức. Claude Code có thể tự động thực hiện các nhiệm vụ phát triển đa bước, hệ thống Minions của Stripe tạo ra hơn 1.000 PR được gộp mỗi tuần, Cursor đã thay đổi cách làm việc của 100% kỹ sư tại NVIDIA. Báo cáo của Gartner cho thấy lượng tư vấn về việc sắp xếp AI đa đại lý trong doanh nghiệp đã tăng 1.445% vào năm 2025.

Điều gì sẽ xảy ra với Định luật Conway khi một số nút trong tổ chức không còn là con người nữa?

Vấn đề này sẽ được thảo luận sâu trong nửa sau của toàn bộ chuỗi bài viết của chúng ta — hiện tượng “One-Person Unicorn” ở bài 10, “Conway’s Law gặp AI Agents” ở bài 11, và “Agentic Engineering” ở bài 14 — nhưng ở đây, hãy bắt đầu với ba phán đoán sơ bộ để xây dựng khung tư duy cho bạn:

Thứ nhất, cấu trúc giao tiếp sẽ trở thành cấu trúc chiến lược. Giao tiếp giữa con người với con người dựa trên văn hóa, sự thấu hiểu ngầm và giao tiếp phi chính thức. Nhưng giữa con người và AI agent không có “sự thấu hiểu ngầm” — bạn phải xác định ranh giới tương tác thông qua các chiến lược, quy tắc và quyền hạn rõ ràng. Khả năng quản trị sẽ thay thế khả năng giao tiếp, trở thành biến số cốt lõi trong thiết kế tổ chức.

Thứ hai, sơ đồ tổ chức sẽ trở thành sơ đồ quyền hạn. Sơ đồ tổ chức truyền thống mô tả mối quan hệ báo cáo và phân công chức năng. “Sơ đồ” trong thời đại AI giống như một đồ thị có hướng không chu trình (DAG), định nghĩa năng lực và ràng buộc — agent nào có thể truy cập dữ liệu nào, thực hiện thao tác nào, và trong điều kiện nào cần sự phê duyệt của con người.

Thứ ba, kiến thức thể chế sẽ chuyển từ con người sang chiến lược. Trước đây, “nhân viên kỳ cựu rời đi là mang theo kiến thức” là nỗi đau của mọi công ty. Trong tương lai, kiến thức then chốt sẽ được mã hóa vào chiến lược và ngữ cảnh của AI agent — đây vừa là cơ hội (kiến thức không còn bị mất đi), vừa là rủi ro (lỗi trong chiến lược có thể khuếch đại hệ thống).

Mỗi phán đoán đều có nền tảng là hàng loạt thực tiễn ngành và dữ liệu. Ví dụ, điều thứ ba về “chuyển giao tri thức thể chế” — trường hợp của Klarna cung cấp một bài học vừa kinh hoàng vừa phản diện: sau khi sa thải 40% nhân viên, họ phát hiện hệ thống AI không thể thay thế được những kiến thức ẩn mà nhân viên bị sa thải mang theo, buộc phải tuyển lại người. Câu chuyện này sẽ được trình bày đầy đủ trong bài thứ 9, “Bài học Klarna”.

Việc phán đoán thứ nhất và thứ hai không chỉ có chúng tôi nhìn nhận như vậy. Trong podcast của a16z vào tháng 7 năm 2026 mang tên “Software in the Age of Agents”, đối tác đội ngũ doanh nghiệp của a16z là Seema Amble và cựu tổng giám đốc Windows của Microsoft, Steven Sinofsky, đã rút ra kết luận cực kỳ nhất quán từ quan sát thực tế đầu tư. Steven đã khái quát gọn gàng trọng tâm của phán đoán thứ nhất: “Hiệu ứng mạng lớn nhất trong phần mềm doanh nghiệp nằm bên trong một công ty” (The biggest network effect in enterprise software is inside of a company): Mạng lưới được dệt nên bởi các mối quan hệ cá nhân, quy trình và hệ thống bên trong tổ chức mới chính là yếu tố tạo độ bám dính thực sự. Agent không thể tiếp cận mạng lưới này bằng “sự đồng cảm ngầm”, mà chỉ có thể thông qua chiến lược và quyền hạn rõ ràng — đây chính là lực đẩy thực tế khiến “cấu trúc giao tiếp trở thành cấu trúc chiến lược”. Seema thì xác nhận phán đoán thứ hai từ góc độ agent truy cập hệ thống doanh nghiệp: Khi một agent muốn “thực thi” (viết bản ghi hệ thống, thay đổi tài chính), nó ngay lập tức đối mặt với toàn bộ vấn đề về danh tính, chứng chỉ, vị trí thanh toán và quyền phê duyệt — sơ đồ tổ chức đang được viết lại thành một bản đồ quyền hạn: “ai được truy cập gì, ai cấp quyền gì”. Hai phán đoán này không phải là dự đoán, mà là những điều đang xảy ra trong các dự án mà các nhà đầu tư mạo hiểm đang đầu tư ngay lúc này. (Khách mời là đối tác a16z / cựu giám đốc Microsoft, quan điểm VC.)

Năm: Tự kiểm tra: Tổ chức của bạn đang phạm phải loại “lỗi Conway” nào?

Nếu bạn đọc đến đây mà vẫn nghĩ “Tôi đều hiểu những lý lẽ này”, thì tôi muốn bạn làm một bài tập nhỏ.

Dưới đây là năm mô hình “sai lệch tổ chức - kiến trúc” phổ biến mà chúng tôi tổng hợp dựa trên Định luật Conway và các nghiên cứu mở rộng. Hãy đối chiếu với công ty của bạn, xem bạn mắc bao nhiêu điểm:

❶ Microservice giả tạo: Mã đã chia nhỏ, nhưng 50 người vẫn đang cãi nhau trong một nhóm chat.
❷ Ảo tưởng trung tâm dữ liệu: Trung tâm dữ liệu trở thành điểm nghẽn giao tiếp cho mọi tuyến kinh doanh.
❸ Đảo AI: Mô hình do nhóm AI tạo ra không thể tích hợp vào hệ thống kinh doanh, vì về mặt tổ chức, họ “không cùng đường”.
❹ Suy thoái hợp tác từ xa: Sự tách biệt vật lý dẫn đến sự chia cắt hệ thống không cần thiết.
❺ Nuốt không trôi vụ mua lại: Sự không tương thích văn hóa tổ chức gây thất bại trong tích hợp công nghệ.

Bước tiếp theo

Đây là bài đầu tiên trong chuỗi 15 bài viết “Sự biến đổi kỹ thuật phần mềm thời đại AI”. Chúng ta bắt đầu từ Định luật Conway để xây dựng nhận thức cơ bản: kiến trúc tổ chức quyết định kiến trúc hệ thống — đây không phải là ẩn dụ, mà là mối quan hệ nhân quả đã được kiểm chứng thực nghiệm.

Nhưng biết định luật này chỉ là điểm khởi đầu. Vấn đề thực sự là: Chúng ta có thể ngược lại khai thác nó không? Bằng cách thiết kế chủ động cấu trúc tổ chức để định hướng kiến trúc hệ thống mong muốn — đây chính là tư tưởng cốt lõi của “Inverse Conway Maneuver”.

Trong bài tiếp theo, Team Topologies — Phương pháp luận thiết kế tổ chức thời hậu Agile, chúng ta sẽ đi sâu vào cách Matthew Skelton và Manuel Pais phát triển tư tưởng này thành một phương pháp luận đầy đủ, có thể thực thi, bao gồm bốn loại đội cơ bản, ba mô hình tương tác, và khái niệm “cognitive load” — một khái niệm bị đánh giá thấp nghiêm trọng. Các trường hợp thực tiễn từ Netflix, Adidas, Accenture sẽ minh họa: Inverse Conway Maneuver hiệu quả trong điều kiện nào, và thất bại trong điều kiện nào.

Ghi chú chuỗi bài: Chuỗi bài này sẽ liên tục theo dõi sự tiến hóa mới nhất của công cụ lập trình AI, kiến trúc tổ chức và mô hình kỹ thuật phần mềm, như sự thay đổi của định luật Conway trong thời đại AI agents năm 2026, mức độ trưởng thành của hệ sinh thái công cụ mới nhất… Theo dõi chuỗi bài để nhận insights cập nhật liên tục.

Về chuỗi bài này

“AI 时代软件工程变革” là chuỗi nghiên cứu sâu dành cho nhà ra quyết định công nghệ doanh nghiệp, gồm 15 bài. Dựa trên nghiên cứu hệ thống hơn 200 bài báo học thuật và báo cáo ngành, cung cấp cho bạn tham khảo ra quyết định có ghi chú cấp độ bằng chứng. Đón chờ thêm nội dung khác.

Nguồn tham khảo:

Conway, M. (1968). How Do Committees Invent? Datamation, 14 (4), 28-31.
Brooks, F. P. (1975). The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley.
MacCormack, A., et al. (2012). Exploring the Duality between Product and Organizational Architectures: A Comparative Study of Commercial and Open Source Software. Harvard Business School Working Paper.
Nagappan, N., et al. (2008). The Influence of Organizational Structure on Software Quality. ICSE ‘08 Proceedings.
Forsgren, N., et al. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press.
Fowler, M. (2022). Conway’s Law. Martinfowler.com/bliki/ConwaysLaw.html.
Gartner (2025/26). Predicts 2026: AI Agents in Software Engineering.
a16z (2026). Software in the Age of Agents. The a16z Podcast. (Câu nói nổi bật của Steven: “Hiệu ứng mạng lớn nhất trong phần mềm doanh nghiệp nằm ngay trong một công ty” + quan sát của Seema Amble về agent truy cập hệ thống doanh nghiệp gặp rào cản về quyền truy cập/credentials/vị trí thanh toán, hỗ trợ các phán đoán 1 và 2 ở phần 4; nguồn cấp một — bản ghi gốc podcast. Ghi chú lập trường: Đối tác a16z / cựu giám đốc điều hành Microsoft, lập trường VC. Xác minh khách mời: Seema Amble, đối tác đội ngũ doanh nghiệp a16z; Steven Sinofsky, cựu tổng giám đốc Windows Microsoft (board partner); Elena Burger, biên tập viên a16z; phát hành tháng 7 năm 2026.)