1. What Is Conway's Law?
Melvin Conway put it in one sentence in his 1968 paper How Do Committees Invent?, published in Datamation after Harvard Business Review turned it down:
"Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure."
Fred Brooks named it "Conway's law" in The Mythical Man-Month (1975). In plain terms: if two teams rarely talk, the parts they build will meet at a narrow, awkward interface. If one team owns two things, those things end up tightly coupled. The org chart leaks into the system.
It's not just folklore. A Harvard Business School study by MacCormack, Rusnak and Baldwin compared matched products built by tightly knit companies and by loosely coupled open-source communities, and found the open-source versions were consistently more modular, as the law predicts. A later review of 102 empirical studies by Colfer and Baldwin found the "mirroring" effect supported in 69% of them. And Microsoft Research found that org-structure metrics predicted which Windows Vista binaries would fail better than any code metric they tested: 86.2% precision, against 78.6% for code churn.
2. Why Does Conway's Law Hit AI Systems Harder?
A classic web service has a few clear owners. An AI feature has more moving parts, and each one invites a different owner: the model vendor relationship, the gateway that holds the API keys, the prompts and tool definitions, the retrieval pipeline and its data, the evals, the guardrails, and the tracing that shows what an agent actually did. Every handoff between those owners becomes a seam in the system.
Two examples. When a central "AI team" owns all model access, every product team's request routes through one shared service, and that team's backlog becomes the system's throughput limit. When each product team owns everything itself, you get one gateway, one vector store and one eval script per team, none of which share traces, so nobody can debug a request that crosses two of them. Same company, same models, different architecture, purely because of who talks to whom. The same logic applies inside the system too: how you split work between multiple agents tends to mirror how the teams that build them are split.
3. Team Topologies, Mapped to AI Work
Team Topologies, the 2019 book by Matthew Skelton and Manuel Pais (second edition September 2025), turns Conway's law into a design tool. It names four team types and three ways they interact, and its core constraint is cognitive load: a team that owns too much slows down and makes poor decisions. Here are the four types and what each should own in an AI organization:
| Team type | What it is | What it owns in AI work |
|---|---|---|
| Stream-aligned | A product team that owns one flow of user value end to end | The AI feature: its prompts, tools, UX, and the test cases that define "good" for it |
| Platform | A group of teams offering internal services other teams use without waiting on them | The AI gateway, model access and routing, the eval harness, tracing, cost tracking, guardrail enforcement |
| Complicated subsystem | A team for a part that needs deep specialist knowledge | Retrieval and ranking at scale, fine-tuning, custom models, speech or vision pipelines |
| Enabling | Specialists who help other teams learn a skill, then step away | Prompt and eval practices, agent patterns, AI security reviews: the useful half of an AI center of excellence |
The Team Topologies authors make the same call for generative AI: their own analysis suggests a stream-aligned team is usually the right home for AI features, with enabling teams helping teams over the first hurdles. Patrick Debois argued at PlatformCon 2025 that any serious generative AI effort deserves a dedicated platform team, covering model providers, RAG as a service, a gateway for cost and access control, and tracing.
4. Who Should Own Each Part of an AI System?
The useful split is by how often something changes and who knows what "good" looks like. Things that change with the feature belong to the product team; things every team needs the same way belong to the platform.
| Component | Owner | Why |
|---|---|---|
| Model access, keys and routing | AI platform | Without one owner, every team signs its own vendor contract and hard-codes one model |
| Prompts and tool definitions | Product team | They change with the feature; central ownership turns each prompt edit into a ticket |
| Eval harness (the runner, CI gate, dashboards) | AI platform | One harness, so results are comparable across features |
| Eval cases (what "good" means) | Product team | Only the team that knows the users can write them |
| Retrieval / RAG pipeline | Product team at first; a specialist team once several products share it | Splitting too early adds a hand-off; splitting too late gives you five vector stores |
| Guardrail policy | Security / risk, through an enabling team | Policy is a governance decision |
| Guardrail enforcement | AI platform (in the gateway) | Enforced in one place, it can't be skipped by a team in a hurry |
| Tracing and cost dashboards | AI platform | A shared trace format is what lets you debug across teams |
| Fine-tuning and custom models | Complicated-subsystem team | Rare, specialist work that most product teams shouldn't carry |
The eval split is the one teams get wrong most often. A central team can build an excellent harness but can't write good test cases for a feature it doesn't own; a product team can write great cases but shouldn't each build its own runner. Our RAG evaluation guide covers what those cases should measure, and AI agent observability covers the shared tracing layer.
5. Which Interaction Mode Fits Which AI Work?
Team Topologies defines three ways teams work together. Each fits a different stage of AI work:
- • Collaboration (two teams working closely for a set period): the first agent or RAG feature, when the product team and the platform or data team are both still learning what's needed. Put an end date on it.
- • X-as-a-Service (one team provides, others consume with little contact): the steady state for the gateway, the eval harness, tracing and a shared retrieval service. If product teams have to file tickets to use them, it isn't a service yet.
- • Facilitating (one team coaches another): the enabling team teaching prompt design, eval writing or guardrail practices, then moving on to the next team.
The common failure is getting stuck in collaboration: the AI platform team stays embedded in every product team's work, so it can never become a service and never scales.
Get the Conway's law for AI cheat sheet
Subscribe and download the one-page cheat sheet: team types, who owns which AI component, warning signs and the setup by company size. Plus one practical AI engineering email a week.
By subscribing you agree to receive emails from AI Engineer Insights. Unsubscribe anytime. See our Privacy Policy.
6. Which Team Structures Produce Bad AI Architecture?
Each of these org shapes predictably produces the architecture in the middle column:
| Org shape | Architecture it produces | Fix |
|---|---|---|
| One central AI team builds every AI feature | Every feature routes through one shared "AI service"; it becomes a queue | Move features into product teams; keep the central team as a platform offering self-service |
| Every product team builds its own stack | Five gateways, five vector stores, five eval scripts, no shared traces | Stand up a thin AI platform team and offer the gateway and eval harness as a service |
| An AI center of excellence that only writes guidelines | Policy documents that the running system doesn't enforce | Turn the CoE into an enabling team with a time limit, and put enforcement in the platform |
| Nobody owns evals | No regression gate; prompt and model changes ship on vibes | Platform owns the harness, each product team owns its cases, and CI blocks on them |
| Data team and AI team never talk | RAG over stale exports instead of governed, fresh sources | Short collaboration period between the two, then a data service the AI teams consume |
7. What Is the Inverse Conway Maneuver?
If the org shapes the system, you can shape the system by changing the org first. Martin Fowler describes the inverse Conway maneuver as changing how designers communicate to encourage the architecture you want. Thoughtworks put it on its Technology Radar as a technique to trial in 2014–2015, and the term itself goes back to a 2010 article by Jonny LeRoy and Matt Simons.
For AI, that means deciding the target architecture first (for example, one gateway, a shared eval harness, product-owned prompts) and then creating the teams that would naturally build it: a small platform team with a clear service to offer, and product teams with the skills to own their features. Fowler's caveat applies: reorganizing won't instantly fix a system that already exists, so expect the architecture to follow the new teams over months, not weeks.
8. Which AI Team Structure Fits Your Company Size?
| Company size | Team setup | Notes |
|---|---|---|
| Startup (under ~30 engineers) | No separate AI team. Product teams build AI features directly on a model API. | One shared wrapper for model calls and one eval script, owned by whoever wrote it |
| Scale-up (~30–150 engineers) | Product teams build features; a thin AI platform team (2–4 people) runs the gateway, evals and tracing | The platform team publishes what it offers, like any internal product |
| Enterprise (150+ engineers) | Platform grouping, one or more specialist teams for retrieval or models, an enabling team for adoption | Microsoft calls the common shape "hub and spoke": central platform, federated delivery |
Microsoft's agent center of excellence guidance describes the same progression: start centralized, and federate delivery when the central team becomes a source of approval delays and knowledge bottlenecks.
9. AI Center of Excellence vs AI Platform Team
An AI center of excellence (CoE) sets standards, governance and training. An AI platform team builds and runs the shared services. In Team Topologies terms, a good CoE is an enabling team and the platform team is a platform team; trouble starts when one group tries to be both, or when a CoE becomes a permanent approval gate.
Microsoft's Cloud Adoption Framework recommends folding AI into an existing cloud CoE where one exists, creating a standalone AI team only if current teams can't support adoption, and over time handing AI delivery to platform teams while the CoE becomes advisory. McKinsey's 2025 State of AI survey found the same split in practice: risk, compliance and data governance are the parts companies most often centralize, while AI talent and adoption are usually run as a hybrid. Your AI operating model is simply the decision of which of these you centralize and which you federate.
10. What Changes When AI Agents Join the Team?
Coding and task agents add a new kind of team member, and Conway's law applies to them too. OpenAI's guide Building an AI-Native Engineering Team splits each phase of development into what you delegate to the agent, what you review, and what you keep. Matthew Skelton made a related point at QCon London 2026, per InfoQ: the main obstacles to using AI agents are usually organizational, and teams need clear boundaries that give agents bounded agency.
In practice, an agent works inside the same boundaries as the team that runs it. Give it a team's repository, tools and skills, and it produces that team's slice of the architecture. Give it access everywhere, and it will couple things no team agreed to couple. If you're building that harness yourself, see what an agent harness is.
Go deeper on Conway's law for AI with AI
Ask your next question with this article as context. Opens in a new tab; you can edit the question before sending.
11. Frequently Asked Questions
What is Conway's law in simple terms?
Conway's law says the systems an organization builds end up copying how that organization communicates. Teams that rarely talk build parts that connect poorly, and parts owned by one team end up tightly coupled. Melvin Conway stated it in 1968, and Fred Brooks named it in The Mythical Man-Month in 1975.
What is the inverse Conway maneuver?
It means changing your team structure on purpose to get the architecture you want, instead of letting the existing org chart decide it. For AI, that usually means creating a small platform team to own the gateway, eval harness and tracing, and giving product teams ownership of their own AI features.
What are the four team types in Team Topologies?
Stream-aligned teams own a flow of user value, platform teams offer internal services, complicated subsystem teams own parts that need deep specialist knowledge, and enabling teams coach other teams and then step away. They work together through three modes: collaboration, X-as-a-Service and facilitating.
Should AI be a central team or embedded in product teams?
Both, for different parts. AI features, prompts and eval cases belong in product teams; the shared gateway, eval harness, tracing and guardrail enforcement belong in a platform team that offers them as a service. A central team that builds every AI feature becomes a bottleneck, and fully separate teams end up duplicating the stack.
Who should own AI evals?
Split it. The platform team owns the eval harness, the CI gate and the dashboards so results are comparable across features. Each product team owns its own eval cases, because only it knows what a good answer looks like for its users.
12. Sources
- • Melvin Conway — Conway's Law
- • MacCormack, Rusnak, Baldwin — Exploring the Duality between Product and Organizational Architectures (HBS)
- • Colfer, Baldwin — The Mirroring Hypothesis: Theory, Evidence and Exceptions (HBS)
- • Nagappan, Murphy, Basili — The Influence of Organizational Structure on Software Quality (ICSE 2008)
- • Martin Fowler — Conway's Law · Thoughtworks Radar — Inverse Conway Maneuver
- • Team Topologies — Key concepts · Second edition announcement
- • Team Topologies — How Team Topologies can transform generative AI integration
- • Patrick Debois — Why AI needs a platform team (PlatformCon 2025)
- • InfoQ — Matthew Skelton on AI agency and Team Topologies (2026)
- • Microsoft — Establish an AI Center of Excellence · Agent CoE operating models
- • McKinsey — The state of AI: How organizations are rewiring to capture value (2025)
- • OpenAI — Building an AI-Native Engineering Team
Team type names and interaction modes are from Team Topologies by Matthew Skelton and Manuel Pais; the mapping to AI components is our own. Sources checked November 11, 2026.