Conway's Law

For over 50 years, Conway’s Law has quietly dictated the shape of software systems. It's not a law of physics, nor is it a coding principle. It's a statement about organizations, and how their communication structures get baked directly into the architecture of the software they produce. As engineering leaders, understanding Conway’s Law isn’t an academic exercise – it’s crucial for building effective teams and scalable systems. Ignore it, and you’ll spend years fighting architectural battles that are fundamentally rooted in organizational dysfunction.

The Law Itself: A Simple Statement, Profound Implications

Melvin Conway articulated his Law in 1968 in his paper, “How Do We Organize Effective Organizations”. It states: “Any organization that designs a system, will produce a system that mirrors the organization’s communication structure.”

Think about that for a moment. It doesn’t say good or bad architecture. It simply states that the way your teams communicate – how information flows, who talks to whom – will manifest in the code you create.

Here's a classic example: imagine a company organized into separate database, UI, and business logic teams, with limited direct communication. Chances are, the resulting software will feature tightly coupled modules, with a clear separation of concerns mirroring the team structure, and complex interfaces used for communication between those modules. A request to change a field in the database, for instance, might require a ticket, a meeting with the UI team to update the display, and then re-testing. This coordination adds significant overhead and slows down development.

Why Does This Happen? Communication Costs & Local Optima

The root cause isn’t malice or incompetence. It's basic human behavior and the need to minimize communication overhead. Teams optimize for local efficiency. They focus on building their piece of the puzzle with minimal friction, and naturally gravitate towards solutions that require the least amount of coordination with other teams. This is especially true given the time constraints and cognitive load faced by most engineering teams.

Consider a situation where the database team is responsible for a particular data model, and the UI team needs access to it. The UI team could build a generic adapter layer for any data source. But that adds complexity and risk. It’s much easier to build an adapter specifically tailored to the existing database schema, even if it creates a dependency. That dependency is the manifestation of Conway’s Law.

This isn’t necessarily wrong. It’s just… inevitable. And when scaled across a large organization, these small, localized optimizations accumulate into a complex, brittle, and difficult-to-change system.

Recognizing the Symptoms: How to Spot Conway's Law in Action

So, how do you know if Conway’s Law is negatively impacting your system? Look for these telltale signs:

• Siloed Architecture: Clear architectural boundaries that perfectly align with team boundaries. Modules are often independently deployable but tightly coupled at the interface level.
• Difficult Cross-Cutting Changes: Simple changes that require coordination across multiple teams, or result in cascading changes.
• Duplicated Logic: The same business rules implemented in multiple places due to lack of shared libraries or services.
• Complex Integration Tests: Extensive integration tests are required to ensure that different modules work together correctly.
• Slow Deployment Cycles: Deploying even small changes requires significant coordination and effort.

Breaking the Cycle: Designing for Communication

While you can’t eliminate Conway’s Law, you can mitigate its negative effects by consciously designing your organization and architecture to prioritize communication. Here’s how:

• Embrace Two-Pizza Teams: Jeff Bezos' famous principle of teams small enough to be fed with two pizzas is surprisingly effective. Smaller teams foster more direct communication and reduce the need for formal coordination (as mentioned in his 2002 letter to shareholders).
• Organize Around Capabilities, Not Components: Instead of structuring teams around technical components (e.g., “Database Team”), organize around business capabilities (e.g., “User Authentication,” “Order Management”). This encourages cross-functional collaboration and reduces dependencies.
• Prioritize APIs & Services: Treat everything as a service. Well-defined APIs provide a stable contract between teams and allow them to evolve independently. This is where the principle of “you build it, you run it” can be extremely powerful.
• Invest in Shared Libraries & Components: Identify common functionality and encapsulate it into reusable libraries or components. This reduces duplication and ensures consistency across the system.
• Promote “Full-Stack” Teams: While specialization is important, encourage team members to develop a broad range of skills. This allows them to address problems end-to-end and reduces the need for handoffs.

Beyond the Code: A Reminder about People

Conway's Law isn’t just about architecture. It's a reminder that software development is a deeply human activity. Completely eliminating organizational friction isn’t realistic, but understanding Conway’s Law allows you to mitigate its most damaging effects. As engineering leaders, our job isn't just to write code. It's to create an environment where teams can communicate effectively, collaborate seamlessly, and build great software. Recognizing and addressing the implications of Conway's Law is a crucial step in that direction.

Key Takeaways:

• Assess your organization: Look for the symptoms of Conway’s Law – siloed architecture, difficult changes, duplicated logic, and slow cycles.
• Prioritize cross-functional communication: Organize teams around capabilities, embrace small “two-pizza” teams, and encourage full-stack skillsets.
• Invest in APIs and shared components: Treat everything as a service and build reusable components to reduce duplication and dependencies.

By prioritizing communication and aligning your organization with your architecture, you can unlock the full potential of your teams and build truly scalable, resilient software.