Your architecture diagram and your org chart are the same diagram. You just haven't overlaid them yet.
In 1967, computer scientist 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, regardless of what your architecture documents say.
What Conway's Law Actually Says
The formal statement is simple: 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. The friction between your departments becomes the API contracts between your systems.
This isn't a suggestion or a tendency. It's closer to a physical law. 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. The teams didn't choose to mirror the org chart - they couldn't help it.
Real-World Examples That Make It Click
The Amazon two-pizza teams story. When Amazon shifted from a monolithic architecture to microservices in the early 2000s, 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. The result? Hundreds of small, autonomous services - each owned by a small, autonomous team. The architecture followed the org chart, exactly as Conway predicted.
The monolith-to-microservices migration that failed. I watched a 200-person engineering org attempt a microservices migration while keeping their existing team structure intact. They had a "platform team," a "product team," and a "data team." After 18 months of effort, they had three large services - one per team - that were essentially the same monolith split into three pieces with network calls in between. They called it microservices. It was a distributed monolith. Conway's Law doesn't care what you call things.
The cross-functional squad that shipped faster. A fintech company I worked with reorganized from function-based teams (frontend, backend, QA) 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 code followed the people.
Conway's Law in Software Engineering: Why It Matters Now
Three trends make Conway's Law more relevant in 2026 than when Conway first proposed it:
Microservices made it visible. In a monolith, Conway's Law is hidden inside the codebase - you see it in module boundaries and package structures, but it's subtle. With microservices, every organizational boundary becomes a network call, an API contract, a deployment pipeline. The mirror between org and architecture is now explicit and measurable.
Remote and distributed teams amplified it. When your frontend team is in San Francisco and your backend team is in Bangalore, the communication latency between those teams becomes architectural latency. The handoff points, the misunderstandings, the timezone gaps - they all show up as integration complexity in the code. A 40-person distributed team running TypeScript and Go tracked their inter-team PRs over one quarter and found that cross-team changes took 3.2x longer to merge than within-team changes. That delay is Conway's Law in action.
AI code generation doesn't override it. Tools like Copilot and Cursor generate code at the individual developer level, but they don't change how teams communicate. An AI assistant can write a function, but it can't negotiate an API contract between two teams that don't talk to each other. If anything, AI accelerates the production of code that reinforces existing organizational boundaries, because it generates code based on patterns it sees - patterns shaped by the current team structure.
The Inverse Conway Maneuver: Using the Law Strategically
Here's where Conway's Law becomes a tool instead of just an observation.
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, a term popularized by Jonny LeRoy and Matt Simons and later developed extensively in the book "Team Topologies" by Matthew Skelton and Manuel Pais.
The logic is straightforward: want a modular, domain-driven architecture? Create small, autonomous teams aligned to business domains. Want a platform architecture? Create a dedicated platform team. Want tight integration between mobile and backend? Put mobile and backend engineers on the same team.
How to apply it:
Start by drawing the architecture you want. Not the one you have - the one that would best serve your business in 18 months. Then ask: "What team structure would naturally produce this architecture?" That's your target org design.
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. The key insight: they didn't refactor the code first. They restructured the teams, and the code refactored itself through natural development patterns.
The "Team Topologies" framework provides a practical model for this: four team types (stream-aligned, enabling, complicated subsystem, and platform) with three interaction modes (collaboration, X-as-a-service, and facilitating). This gives leaders a vocabulary for designing organizations that produce specific architectural outcomes.
How to Measure Conway's Law in Your Organization
You can't manage what you can't measure, and most teams have never actually measured the alignment between their org structure and their architecture. Here's how to do it:
Step 1: Map code ownership to team boundaries. Look at your version control history. For every file or module, identify which team contributes the most commits. This gives you a de facto ownership map - not who the CODEOWNERS file says owns it, but who actually works on it.
Step 2: Identify cross-team coupling. Find modules where multiple teams are making frequent changes. These are your Conway's Law violation points - places where the architecture says "this is one component" but the org chart says "this requires coordination between three teams." These coupling points are where bugs cluster, deployments slow down, and engineers get frustrated.
Step 3: Measure coordination cost. Track how long cross-team pull requests take compared to within-team PRs. The ratio tells you how much organizational friction is embedded in your architecture. A healthy ratio is under 1.5x. If cross-team changes take 3x or longer, your architecture and your org structure are fighting each other.
Step 4: Visualize the alignment. Overlay your team structure onto your service dependency graph. Where teams map cleanly to services, you have alignment. Where a single service requires three teams to modify, or one team spans five services, you have misalignment - and that misalignment is costing you velocity.
This is precisely where codebase intelligence tools become critical. (For more on how architecture decisions affect sprint delivery, see our post on why sprint planning is broken, and for a framework on modeling system architecture, check out our C4 Architecture Diagram guide.) Trying to do this analysis manually with git logs and spreadsheets is possible but painful. Tools like Glue automate the mapping between team activity and code architecture, surfacing the organizational dynamics that Conway's Law predicts. Glue's codebase intelligence agents analyze contribution patterns, identify cross-team coupling hotspots, and make the invisible relationship between your people and your code visible - without requiring engineers to manually tag ownership or maintain stale documentation.
When Conway's Law Works Against You
Conway's Law is neutral - it describes a force, not a value judgment. But that force can produce architectures that actively harm your product:
Silos create integration nightmares. When teams don't communicate, their components don't integrate well. The seams between teams become the weakest points in your system. A 60-engineer e-commerce platform with siloed teams found that 73% of their production incidents originated at service boundaries between teams that had no regular communication channels.
Reorgs create architectural whiplash. Every time you restructure teams, you're implicitly restructuring your architecture. Frequent reorgs mean your codebase never settles into a coherent design. The code accumulates layers of organizational history - this module was built when Team A and Team B were combined, that API was created when the platform team split from the product team.
Conway's Law doesn't reverse cleanly. When you split a team, the code they worked on doesn't automatically split too. You end up with shared ownership of legacy components that neither team wants to maintain but both teams depend on. This is one of the primary generators of technical debt - organizational changes that leave architectural residue.
Conway's Law, Microservices, and Domain-Driven Design
The connection between Conway's Law, microservices, and Domain-Driven Design (DDD) is not coincidental. All three converge on the same principle: system boundaries should align with business domain boundaries, which should align with team boundaries.
When these three layers are aligned - domain boundaries, service boundaries, and team boundaries - you get what the industry calls "high cohesion, low coupling" at every level. Each team owns a complete business capability. Each service encapsulates a bounded context. Changes to one domain rarely require coordination with others.
When they're misaligned, you get distributed monoliths, cross-cutting changes that require four teams to coordinate, and deploy trains that run weekly because no single team can ship independently.
Practical Steps: What to Do Monday Morning
If you're a tech lead or architect: Map your actual code ownership (not the documented ownership) against your team structure. Where they diverge, you've found your highest-friction points. Prioritize refactoring those areas - or better yet, propose team structure changes that align with the architecture you want.
If you're an engineering manager: Before your next reorg, draw the architecture that would result from the proposed team structure. If that architecture doesn't match what you need, redesign the teams - not the code.
If you're a VP of Engineering or CTO: Treat organizational design as architectural design. They're the same decision. Use codebase intelligence to make this relationship visible to your leadership team. When a PM asks "why is this feature taking so long?", the answer might not be technical - it might be organizational. Glue makes it possible to show exactly how team structure impacts delivery speed by connecting code-level activity to organizational patterns.
Frequently Asked Questions
What is Conway's Law in simple terms?
Conway's Law says that the structure of any software system will end up looking like the structure of the organization that built it. If you have four separate teams, you'll get four separate components. The communication patterns between people become the integration patterns between code.
Is Conway's Law good or bad?
Neither - it's a force, like gravity. It becomes "bad" when your organizational structure doesn't match the architecture your product needs. It becomes a powerful tool when you deliberately design your team structure to produce the architecture you want (the Inverse Conway Maneuver).
What is Conway's Law in Agile and microservices?
In Agile, Conway's Law explains why cross-functional squads produce better-integrated features than function-based teams. In microservices, it explains why you should organize teams around business domains rather than technical layers. The Agile principle of autonomous, cross-functional teams is essentially the Inverse Conway Maneuver applied at the squad level.
What is the Inverse Conway Maneuver?
The Inverse Conway Maneuver means deliberately structuring your teams to produce the software architecture you want. Instead of letting your org chart accidentally determine your architecture, you design the org chart intentionally. This concept was formalized in the book "Team Topologies" by Matthew Skelton and Manuel Pais.