The question
What changes when architecture is treated as a coordination design, not only a technical design?
Team structure is already an architectural decision. Not because developers mechanically reproduce reporting lines, but because every system interaction needs someone to agree on its contract. The people who can make that agreement determine which interfaces stay simple, which grow exceptions, and which never become viable.
API, data contract, deployment rule
ownership, vocabulary, decisions
The diagram is an explanatory model, not evidence that every component requires its own team.
What Conway actually argued
In 1968, Melvin Conway described system design and design organizations as graphs. A subsystem interface requires the responsible groups to negotiate an interface specification. His thesis: an organization designing a system is constrained to produce a design whose structure copies its communication structure.
Constrained does not mean every team chart maps one-to-one onto modules. It means the available communication paths limit the designs that can be pursued effectively. Organizing and delegating work also narrows the alternatives that remain practical.
An interface is therefore more than a function signature, message schema, or database boundary. It is a repeated agreement about allowed changes, decision rights, version coexistence, and failure behavior. If owners cannot make those agreements efficiently, the interface has a hidden cost.
Do not turn the heuristic into a rule
Martin Fowler describes three responses: ignore the law, accept communication patterns when choosing architecture, or deliberately change communication patterns to encourage a desired architecture—the inverse Conway maneuver. He also notes that a small group may sensibly build a monolith, and that changing the organization does not instantly repair rigid existing code.
Empirical evidence is mixed. A 2019 study of open-source projects found that the projects it examined did not closely obey a simple structural mapping, partly because code and contributor networks had scale-free shapes. Treat Conway's Law as a testable explanation for coordination pain, not as proof that a reorganization or microservices is required.
Architecture is an agreement budget. A team can sustain a few expensive relationships through shared context and joint ownership. It cannot make every component pair expensive to coordinate without slowing down. As systems grow, timely, informed agreement can become scarcer than coding hours.
Read symptoms as hypotheses
| Symptom | Possible coordination cause | Question before changing code |
|---|---|---|
| API special cases multiply | Domain decisions happen after implementation starts. | Which decision lacks a named owner or shared definition? |
| Releases need many approvals | The release crosses independent risk boundaries. | Which approval protects a distinct risk? |
| A shared database blocks work | Teams lack a workable contract for changing shared facts. | Which facts need one owner? |
| One team integrates everything | Architecture and ownership disagree about who coordinates. | Can the interface narrow, or should ownership move? |
These are hypotheses. A special-case API can reflect a real domain. A shared database can be the right short-term choice. The diagnostic matters only when it identifies a repeated decision that can become cheaper or less frequent.
The agentic twist
Agents can prepare code, tests, migrations, and documentation quickly. They reduce the time between an idea and the moment it meets a boundary. They do not establish cross-team contracts merely by producing a plausible schema. Someone still decides whether the boundary is correct, who owns it, and what compatibility promise applies.
Faster implementation can increase the arrival rate of proposed changes at review, integration, security, product, and architecture decisions. If those remain unclear, a team may see more pull requests, rework, and escalations without delivering more value. This is inference, not a measured result for a specific team.
A two-graph diagnostic
- Pick one integration that repeatedly needs escalation.
- Draw a runtime graph: components and interfaces used at runtime.
- Draw a change graph: people or teams who communicate when the interface changes.
- Use the last three changes, not job titles: who asked, decided, implemented, reviewed, and needed notice?
- Compare the graphs and name one mismatch.
How to interpret the mismatch
- Aligned and expensive: the interface is inherently complex. Improve contract, test harness, and documentation.
- Technically narrow, socially wide: one small API change needs many people. Look for duplicated approvals, unclear ownership, or an unnecessary dependency.
- Technically wide, socially narrow: one team silently coordinates many components. Make hidden coupling explicit before that team becomes a bottleneck.
Change both sides, at different speeds
Team membership can change quickly. Domain knowledge, deployment ownership, data contracts, and customer commitments often cannot. A reorganization can create a temporary mismatch in which a new team inherits an old dependency structure. Treat that mismatch as a migration state with named work.
- Select one boundary with an observable problem.
- State the decision owner and compatibility promise.
- Reduce one technical dependency or one unnecessary handoff.
- Measure whether the next changes need fewer participants, less waiting, or less rework.
- Keep the change only if it improves the outcome without creating an unowned risk.
Open questions
- Which interfaces consume the most cross-team coordination, rather than the most lines of code?
- Where does an architectural problem originate in ambiguous product or data ownership?
- Which decisions need a durable owner, and which can be delegated to a stable contract?
- How should an agent be constrained at a boundary with unresolved ownership?
Sources
- Melvin E. Conway, How Do Committees Invent? (1968) — primary source.
- Martin Fowler, Conway's Law (2022) — practitioner interpretation.
- Mariusz Kamola, How to Verify Conway's Law for Open Source Projects (2019) — empirical counterweight.