7 minute read • Understanding the invisible forces shaping your architecture
Here’s a question that might make you uncomfortable: Did your team choose microservices because they were the best technical solution, or because you had five separate teams that needed to ship independently? Be honest.
If you’re feeling defensive, you’re not alone. We engineers like to think we make purely rational, technically-driven decisions. But there’s a law—backed by decades of observation—that suggests something different: our systems inevitably reflect our organizational structures, whether we intend them to or not.
This is Conway’s Law, and understanding it is crucial for anyone involved in building software at scale. It’s not just an interesting observation; it’s a fundamental constraint that shapes every architectural decision you make.
1. The Original Observation
“Any organization that designs a system will inevitably produce a design whose structure is a copy of the organization’s communication structure.”— Melvin Conway, 1967
Melvin Conway made this observation in 1967, long before microservices, DevOps, or Agile existed. He submitted his paper to the Harvard Business Review, but they rejected it—allegedly because he hadn’t “proved” his hypothesis. Yet anyone who’s worked in software for any length of time recognizes the truth in his words immediately.
Conway noticed that if you ask four teams to build a compiler, you’ll get a four-pass compiler. If you have separate frontend, backend, and database teams, you’ll end up with a three-tier architecture. The structure of your system mirrors the structure of your organization because systems are built through communication, and communication follows organizational lines.
1.1 Why This Happens
The mechanism behind Conway’s Law is surprisingly straightforward. When people design systems, they need to coordinate with others. That coordination happens along organizational boundaries because that’s where communication channels already exist. You talk to your teammates daily, your manager weekly, and that person three teams over… maybe never.
This creates what we might call communication gradients—it’s easy to make decisions with people close to you in the org chart and hard to make them with people far away. So naturally, system boundaries form along organizational boundaries. It’s not laziness or poor planning; it’s basic human nature encountering organizational friction.
2. The Evidence Is Everywhere
Once you know to look for Conway’s Law, you see it everywhere. Let’s examine some concrete examples.
Example: The Three-Tier Architecture
Remember when every enterprise app had the same structure? A presentation tier, a business logic tier, and a data tier. These weren’t just logical separations—they reflected organizational reality. You had frontend developers, backend developers, and DBAs. Each team owned their tier. The architecture wasn’t chosen for technical merit alone; it was chosen because it allowed three distinct teams to work with minimal coordination.
Example: The Microservices Explosion
A startup with ten engineers builds a monolith. It works fine. They grow to 100 engineers organized into twelve teams. Suddenly the monolith is “unscalable” and they need microservices. Did the technical requirements change? Or did the organizational structure change? Usually, it’s the latter driving the former.
The chart above illustrates a pattern seen repeatedly in growing companies. As team count increases, architectural complexity tends to increase proportionally. This isn’t coincidence—it’s Conway’s Law in action. Each new team needs ownership boundaries, and those boundaries manifest as architectural boundaries.
| Org Structure | Typical Architecture | Communication Pattern |
|---|---|---|
| Single team (5-10 people) | Monolith | Direct, informal, frequent |
| Feature teams (3-5 teams) | Modular monolith or few services | Regular syncs, shared repos |
| Product-aligned teams (10+ teams) | Microservices | Async, API contracts, autonomy |
| Siloed functions (frontend/backend/data) | Three-tier architecture | Formal handoffs, tickets |
3. The Sociological Forces at Play
Conway’s Law isn’t just about communication—it’s about power, ownership, and identity. These sociological forces are often stronger than technical considerations, yet we rarely discuss them openly.
3.1 Ownership and Autonomy
Teams want autonomy. They want to ship code without waiting for approvals from other teams, without coordinating deployments, without sitting through endless alignment meetings. This desire is completely reasonable and healthy. But it has architectural implications.
If your payments team wants to deploy independently, they need a payments service. If your search team wants to own their infrastructure, they need a search service. Each desire for autonomy creates an architectural boundary. Again, this isn’t wrong—but we should acknowledge that we’re making organizational decisions, not purely technical ones.
3.2 Career Progression and Prestige
Let’s talk about something uncomfortable: building new systems is more prestigious than maintaining existing ones. A senior engineer who builds a new microservice from scratch can put that on their resume and talk about it in interviews. Someone who maintains a monolith, no matter how well, has less to show.
This creates an incentive structure that favors architectural proliferation. New services, new technologies, new patterns—these advance careers. Simplification and consolidation? Less so. The architecture grows because growing it serves individual career interests, even when technical simplicity might serve the business better.
3.3 Political Boundaries
When two teams disagree about priorities or approach, the solution is often architectural separation. Can’t agree on how user authentication should work? Make two authentication systems. Can’t decide between REST and GraphQL? Support both. We use architecture to avoid resolving organizational conflicts.
The Mythical Man-Month famously noted that “adding manpower to a late software project makes it later.” Conway’s Law extends this: adding teams to an organization makes the architecture more complex.
4. The Reverse Conway Maneuver
If Conway’s Law says organizations shape architecture, then the Reverse Conway Maneuver is the deliberate act of reshaping your organization to achieve a desired architecture. Popularized by ThoughtWorks, this approach acknowledges that fighting Conway’s Law is futile—instead, we should work with it.
Want a microservices architecture? Don’t start by splitting your monolith. Start by splitting your teams into small, autonomous units with clear ownership boundaries. The architecture will follow. Want to consolidate services? Start by consolidating teams. Want better integration between systems? Start by improving communication between the teams that own them.
The Insight: If you want to change your architecture, change your organization first. Trying to impose an architecture that conflicts with your organizational structure is like trying to swim upstream—technically possible, but exhausting and unlikely to succeed long-term.
4.1 Real-World Examples
Amazon’s famous transition to services didn’t start with a technical decision. It started with an organizational one: teams were restructured around services, with each team owning their service end-to-end. The “two-pizza team” concept (teams small enough to be fed by two pizzas) wasn’t just about team size—it was about creating organizational units that would naturally produce service-oriented architecture.
Spotify’s squad model is another example. By organizing into cross-functional squads with clear missions, they created an organizational structure that naturally led to loosely-coupled systems. The architecture emerged from the organization, not the other way around.
This chart shows how communication overhead grows with architectural distribution. A monolith maintained by coordinated teams has relatively low coordination costs. As you move to microservices, if team boundaries don’t align with service boundaries, coordination costs explode. But when teams and services align (the Reverse Conway Maneuver), overhead stays manageable.
5. The Impossibility of Neutral Architecture
Here’s the uncomfortable truth: there is no such thing as a purely technical, organizationally-neutral architecture. Every architectural decision has organizational implications, and every organizational structure has architectural implications. You can’t separate the two.
When architects say they’re making “purely technical” decisions, they’re usually either naive or dishonest. Choosing microservices versus a monolith isn’t just about scalability—it’s about team autonomy, deployment independence, and organizational boundaries. Choosing a programming language isn’t just about performance—it’s about hiring, expertise, and which teams will own which components.
5.1 The Hidden Costs
This impossibility of neutrality means every architectural choice carries hidden organizational costs. Some examples:
| Technical Decision | Organizational Implication | Hidden Cost |
|---|---|---|
| Microservices | Need clear team boundaries | Cross-team features require coordination |
| Shared libraries | Need governance and coordination | Slows down teams, creates dependencies |
| Platform team | Centralized control | Can become bottleneck, disconnected from users |
| Polyglot architecture | Specialized expertise per team | Reduced mobility, knowledge silos |
None of these decisions are wrong, but pretending they’re purely technical ignores the organizational complexity they create. A mature engineering organization acknowledges these tradeoffs explicitly.
6. Working With Conway’s Law
Since you can’t escape Conway’s Law, how do you work with it effectively?
6.1 Start With Team Structure
Before making major architectural decisions, look at your organizational structure. How many teams do you have? How do they communicate? Where are the natural boundaries? Your architecture should align with these realities, not fight them.
If you want to move to microservices but your teams are organized by function (all frontend developers in one team, all backend in another), your microservices experiment will fail. The team structure doesn’t support it.
6.2 Create Deliberate Communication Paths
Conway’s Law says systems reflect communication structures. So design your communication structures deliberately. Want two services to integrate smoothly? Make sure the teams maintaining them have regular communication. Want to keep systems independent? Minimize team interactions.
This is why co-locating teams physically (or virtually) matters. It’s why some companies have “DevOps” as a practice, not a team—they want to encourage communication patterns that lead to better operational architecture.
6.3 Acknowledge the Social Architecture
Stop pretending technical and organizational decisions are separate. When discussing architecture, explicitly discuss team structure, communication patterns, career incentives, and political realities. These aren’t distractions from the “real” technical work—they are the work.
Some teams practice architectural decision records (ADRs) that document not just what was decided, but why, including organizational factors. This creates organizational memory and helps future teams understand the full context of decisions.
6.4 Plan for Evolution
Both organizations and architectures evolve. The structure that works for a 20-person startup won’t work at 200 people. The architecture that works for 200 people won’t work at 2,000. Plan for this.
Accept that as your organization grows and changes, your architecture will need to change too. This isn’t failure—it’s adaptation. The monolith that served you well for three years might need to split. The microservices that worked for five teams might need to consolidate when you restructure.
Remember: Conway’s Law isn’t a bug to fix—it’s a constraint to work within. The best architectures don’t fight organizational reality; they embrace and channel it.
7. What We’ve Learned
Conway’s Law reveals an uncomfortable truth: we’re not as rational as we’d like to believe. Our technical decisions are deeply intertwined with organizational structure, power dynamics, and social forces. The microservices you built might have been technically sound, but they were also shaped by team boundaries, career incentives, and political realities.
This doesn’t make them wrong—it makes them human. The key is to stop pretending architecture is purely technical and start acknowledging the organizational forces at play. Use the Reverse Conway Maneuver deliberately: shape your organization to support your desired architecture. Create communication structures that lead to the system designs you want.
Most importantly, accept that there is no neutral architecture. Every technical choice has organizational implications. Every organizational structure shapes your systems. The architects who succeed aren’t the ones who ignore this reality—they’re the ones who understand it and work with it skillfully.
The next time you’re in an architecture review, pay attention to the organizational subtext. When someone proposes splitting a service, ask: “Is this about technical scalability, or team autonomy?” When someone suggests consolidating systems, ask: “Are we simplifying architecture, or restructuring teams?” The honest answers to these questions will tell you more about your system’s future than any technical diagram.
