I shipped skillcraft.ai !!!
Skillcraft helps you find the best learning resources tailored to your goals. Get a personalized roadmap with the best courses, books, and tutorials. Try it out, for free!
Up to date
Published
5 min read

Trevor I. Lasn

Building tools for developers. Currently building skillcraft.ai and blamesteve.lol

Conway's Law: The Hidden Force Shaping Your Software Architecture

If you've ever wondered why your carefully planned software architecture ends up looking suspiciously like your org chart, you're not alone. Welcome to the world of Conway's Law.

Have you ever wondered why your carefully designed software architecture keeps drifting away from your initial vision? Or why your codebase seems to mirror your team structure more than the actual problem you’re trying to solve?

If you’re nodding your head, you’re not alone. These puzzling situations are often the result of a subtle but powerful force in software development: Conway’s Law.

What’s Really Going On?

Think about your last big project. Did you notice any of these signs?

  • Features that should be unified are spread across multiple components.
  • Duplicate code or functionality in different parts of the system.
  • Integration points that are more complex than they need to be.
  • Architectural decisions that seem to reflect team boundaries rather than technical needs.

If these sound familiar, Conway’s Law might be at play in your organization.

So What Exactly is Conway’s Law?

Conway’s Law, named after programmer Melvin Conway in 1967, states:

“Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.”

In simpler terms: Your software architecture will inevitably reflect how your teams communicate and are organized.

Organization Structure System Architecture
---------------------- -------------------
+-------------+ +-------------+
| Team A | | Component A |
+-------------+ +-------------+
| |
| |
+-------------+ +-------------+
| Team B | | Component B |
+-------------+ +-------------+
| |
| |
+-------------+ +-------------+
| Team C | | Component C |
+-------------+ +-------------+

Notice how the system architecture mirrors the organization structure. Each team ends up creating a corresponding component, even if a different architecture might be more efficient.

The Hidden Dynamic: Path of Least Resistance

Here’s the kicker that often goes unnoticed: Teams will typically choose to solve problems themselves rather than reach out to other teams. They’ll often accept a suboptimal architecture if it means avoiding the hassle of cross-team coordination.

This preference for internal solutions can lead to:

  • Duplicated functionality
  • Convoluted workarounds
  • Inconsistent approaches to similar problems across the system
Ideal Flow Actual Flow
---------- -----------
+-------+ +-------+ +-------+
|Team A |<-->|Team B | |Team A |
+-------+ +-------+ +-------+
^ ^ |
| | |
v v v
+-------+ +-------+ +-------+
|Team C |<-->|Team D | |Team C |
+-------+ +-------+ +-------+
|
|
v
+-------+
|Team B |
+-------+
|
|
v
+-------+
|Team D |
+-------+

In the ideal flow, teams collaborate directly. In the actual flow, Team A might implement a suboptimal solution to avoid coordinating with Team B, passing the problem down the line.

Why Should You Care?

Understanding Conway’s Law isn’t just an academic exercise. It’s a practical tool that can help you:

  • Anticipate architectural challenges based on team structure.
  • Make informed decisions about organizing your development teams.
  • Avoid common pitfalls in system design that stem from organizational issues.

Working With (or Around) Conway’s Law

Knowing about Conway’s Law is half the battle. Here’s how you can use this knowledge:

  1. Intentional Team Design: Structure your teams based on the architecture you want, not the other way around.
  2. Fight for Clear Boundaries: Ensure each team has a well-defined domain or feature set. Clear boundaries prevent architectural shortcuts that can become painful later.
  3. Cross-Functional Teams: Build teams that can deliver end-to-end features. This reduces the need for complex inter-team dependencies.
  4. Regular Architecture Reviews: Step back and assess: Is your system structure serving your needs, or just reflecting your org chart?
  5. Encourage Cross-Team Communication: The more your teams talk to each other, the more integrated your systems are likely to be.
Before After
------ -----
+----------+ +-----------------+
|Frontend | |Feature Team 1 |
|Team | |(UI + Backend) |
+----------+ +-----------------+
| |
| |
+----------+ +-----------------+
|Backend | |Feature Team 2 |
|Team | |(UI + Backend) |
+----------+ +-----------------+
| |
| |
+----------+ +-----------------+
|Database | |Platform Team |
|Team | |(Shared Services)|
+----------+ +-----------------+

By restructuring into cross-functional feature teams, you can encourage a more integrated architecture that aligns with product features rather than technical layers.

# Before: Fuzzy boundaries leading to duplication
class FrontendTeam:
def build_ui(self):
pass
def validate_user_input(self): # Duplicate logic
pass
class BackendTeam:
def create_api(self):
pass
def validate_user_input(self): # Duplicate logic
pass
# After: Clear boundaries and responsibilities
class UserInterfaceTeam:
def build_ui(self):
pass
def collect_user_input(self):
pass
class BusinessLogicTeam:
def validate_input(self):
pass
def process_data(self):
pass
class DataAccessTeam:
def store_data(self):
pass
def retrieve_data(self):
pass

Conway’s Law isn’t a rule set in stone, but ignoring it is like swimming against the current. By understanding how your organizational structure influences your system architecture, you can make more informed decisions about both.

Remember, great software isn’t just about code—it’s about the people and structures that create it. Sometimes, the key to solving a persistent architectural issue might not be in your codebase, but in your org chart.


Found this article helpful? You might enjoy my free newsletter. I share dev tips and insights to help you grow your coding skills and advance your tech career.


Check out these related articles that might be useful for you. They cover similar topics and provide additional insights.

Reflections
5 min read

A Company Is Not a Family. It's a Sports Team

'We're not just a company, we're a family!' It's a nice sentiment, sure. But it's also a load of crap.

Oct 5, 2024
Read article
Reflections
7 min read

Can Scrum Be Salvaged?

Scrum is failing engineering teams and what it's actually costing us

Nov 14, 2024
Read article
Reflections
4 min read

Users Can Be Fired

Letting go of difficult or harmful users can be the key to maintaining the health and growth of your product

Sep 19, 2024
Read article
Reflections
4 min read

Small Habits, Big Impact

We're often focused on big innovations and breakthrough moments. But what if the real key to long-term success lies in the small, everyday actions we often overlook?

Oct 12, 2024
Read article
Reflections
4 min read

A Great Product Doesn't Need Marketing

Great products speak for themselves, without the need for massive marketing campaigns

Sep 18, 2024
Read article
Reflections
3 min read

Take Your Writing Seriously

It’s not just about getting the message across; it’s about doing so in a way that’s easy for others to follow. Good writing shows respect for your team and your work.

Sep 19, 2024
Read article
Reflections
6 min read

Software Engineer Titles Have (Almost) Lost All Their Meaning

Examining the Devaluation of Software Engineer Titles and Its Impact on Tech Industry Integrity

Oct 20, 2024
Read article
Reflections
3 min read

Internal Mobility

Just like a utility player on a sports team discovering their ideal position, internal mobility allows you to explore different areas of engineering and find your true passion.

Sep 23, 2024
Read article
Reflections
5 min read

Company Culture Happens Outside Management

Why real company culture grows from the ground up, not top down.

Sep 14, 2024
Read article

This article was originally published on https://www.trevorlasn.com/blog/conways-law. It was written by a human and polished using grammar tools for clarity.