Your architecture diagram and your org chart are the same diagram. You just haven't overlaid them yet.
In 1967, Melvin Conway submitted a paper to the Harvard Business Review with an observation so accurate it became a law: "Any organization that designs a system will produce a design whose structure is a copy of the organization's communication structure." The HBR rejected it. The idea stuck anyway.
Nearly six decades later, Conway's Law isn't just an interesting observation — it's the single most reliable predictor of how your software will actually be structured.
What Conway's Law Actually Says
Organizations design systems that mirror their own communication structures. But the implications run deeper than most teams realize.
If you have three teams — frontend, backend, and infrastructure — you will build a three-tier architecture. Not because three tiers is the right design, but because that's how information flows between the people building it. The boundaries between your teams become the boundaries between your services.
A 2008 study by researchers at MIT and Harvard Business School examined multiple codebases and found that organizational structure was a stronger predictor of software modularity than any technical decision the teams had made.
Real-World Examples
The Amazon two-pizza teams story. When Amazon shifted from monolith to microservices, Jeff Bezos didn't start with a technical mandate. He started with an organizational one: every team should be small enough to feed with two pizzas. Hundreds of small, autonomous services — each owned by a small, autonomous team. Architecture followed the org chart.
The monolith-to-microservices migration that failed. A 200-person engineering org attempted a microservices migration while keeping their existing team structure. They had a "platform team," "product team," and "data team." After 18 months: three large services — one per team — that were essentially the same monolith split into three pieces with network calls in between. A distributed monolith.
The cross-functional squad that shipped faster. A fintech company reorganized from function-based teams to cross-functional squads aligned to business domains (payments, onboarding, lending). Within one quarter, their architecture naturally decomposed along those same domain boundaries. No architect mandated it.
The Inverse Conway Maneuver
If your architecture inevitably mirrors your org structure, then you can design your organization to produce the architecture you want. This is the Inverse Conway Maneuver.
Want a modular, domain-driven architecture? Create small, autonomous teams aligned to business domains. Want a platform architecture? Create a dedicated platform team.
A B2B SaaS company with 35 engineers reorganized from technology-layer teams (frontend, backend, data) to domain-aligned squads (billing, user management, analytics, integrations). Within two quarters, their architecture shifted from a layered monolith to domain-bounded services. They didn't refactor the code first. They restructured the teams, and the code refactored itself.
Why It Matters More in 2026
Three trends make Conway's Law more relevant now:
Microservices made it visible. Every organizational boundary becomes a network call, an API contract, a deployment pipeline.
Remote teams amplified it. When your frontend team is in San Francisco and your backend team is in Bangalore, the communication latency becomes architectural latency. Cross-team changes take 3.2x longer to merge.
AI code generation doesn't override it. Copilot can write a function, but it can't negotiate an API contract between two teams that don't talk to each other.
How to Measure It
Step 1: Map code ownership to team boundaries. Look at your version control history. For every module, identify which team contributes the most commits. Tools like codebase intelligence platforms can automate this.
Step 2: Identify cross-team coupling. Find modules where multiple teams make frequent changes. These are your Conway's Law violation points — places where the architecture says "one component" but the org chart says "three teams."
Step 3: Quantify the cost. Cross-team PRs take longer to merge, produce more bugs, and create more deployment conflicts. Measure the difference.
The Takeaway
Conway's Law is not a suggestion. It's closer to a physical law. You can fight it or use it. The teams that use it — designing their organization to produce the architecture they want — consistently outperform those that don't.
The best architecture decisions are often org design decisions in disguise.
Originally published on getglueapp.com/blog/conways-law
Want to see how Conway's Law plays out in your codebase? Glue maps code ownership, team coupling, and knowledge silos automatically from your git history.
Top comments (0)