Conway's Law - Why Your Software Looks Like Your Company

There is an old adage in software development, formulated by Melvin Conway in 1967, which is more relevant today than ever:

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

Sounds abstract? It isn't. It simply means: Your software is a reflection of your team structure.

• Do you have three separate departments that barely talk to each other? Then you will have three software modules that don't work well together.
• Are your teams sitting in silos? Your data will be too.
• Does a single developer do everything? The system will be a big, interwoven lump.

This is called Conway's Law. And it has massive implications for the cost, speed, and quality of your IT projects – whether you're a tech startup or a mid-sized manufacturing company.

Why is this a problem?

The automatic mapping of organizational structure into software architecture wouldn't be a problem if our organizational structures were perfect. But mostly, they aren't.

This leads to missed opportunities and unnecessary costs:

1. Duplicate Work: If teams don't communicate, they solve the same problems twice. Team A builds user management, Team B builds user management. That costs double the time and money.
2. Lack of Integration: Systems that are supposed to work together (e.g., Sales and Production) don't, because the departments are separated. Data has to be transferred manually – errors are pre-programmed.
3. High Maintenance Costs: If everyone "does their own thing," a jungle of technologies and tools emerges that no one can master in the end.

Not Just a Problem for Big Corporations

It is often dismissed: "We are not a big corporation, this doesn't concern us." A dangerous misconception. Conway's Law applies everywhere people work together (or don't).

Scenario 1: The "Small" SME

Even in small companies with 3-4 external partners, Conway's Law strikes.

Imagine:

• An agency builds the marketing website.
• A service provider manages the webshop.
• A freelancer once built an internal tool.

Because these service providers never spoke to each other (and it wasn't in the contract), the system landscape looks like this:

The Consequence: You have customer data in three places. Changes have to be entered three times. No one has an overview of how much revenue a customer actually generates. This is inefficient and error-prone.

Scenario 2: "Interface Jungle" in Large Systems

A classic in larger environments: Multiple teams need the same data from a central external system (e.g., an SAP ERP for inventory data or a CRM for customer data).

Because the teams for "Checkout," "Customer Service," and "Marketing" work in isolated silos, each team builds its own connection.

The Problem:

1. Triple Maintenance: If the ERP changes its interface, three teams have to interrupt their work simultaneously to fix their integrations.
2. Inconsistency: The Checkout Service might cache data for 10 minutes, the Marketing Tool for 24 hours. Customers see different information.
3. Load Issues: The external system is unnecessarily burdened by multiple interfaces.
4. Maintenance Costs: Changes to the system must consider every interface technology – driving complexity and costs up.

A central "Gateway" component (built by a platform team or coordinated jointly) would have solved these problems – but the org structure prevented it.

How to Do It Better Today: "Team Autonomy" vs. "Chaos"

Previously, attempts were made to control everything centrally ("One thinks, everyone works"). That was too slow. Today, we want autonomous teams that can decide and deliver quickly.

But autonomy must not mean chaos.

The Concept of "Guardrails" (Macro-Architecture)

Successful modern companies use a hybrid approach. They define guardrails that apply to everyone (macro-architecture) and give teams free rein within these guardrails (micro-architecture).

Example: The Chaotic Startup

A startup grows quickly. Each team solves the topic of "Monitoring & Logging" differently.

Result (Negative):

• Team A writes unstructured text logs to files.
• Team B uses an expensive SaaS tool just for itself.
• Team C trusts "it will run fine" and has no logs at all.

When a system-wide error occurs, root cause analysis is impossible because traces exist in three different formats (or not at all).

The Solution: Setting Guardrails

Management (or the architect) mandates: "We use structured logs and a unified monitoring infrastructure as the standard for our monitoring. Everything else (e.g., programming language or database) you decide yourselves."

The Advantage: Teams are fast because they don't constantly have to make fundamental decisions. And when there's a fire, Team A can help out Team B.

The "Gamechanger": Generative AI

Here it gets exciting, especially for the future: Artificial Intelligence (like GitHub Copilot, Claude Code, etc.) is currently changing how we deal with this topic.

Critics used to say: "If every team cooks its own soup, we program a lot of things twice. That's a waste!"

Today, AI says: "No problem, I'll write the boilerplate code for you in 30 seconds."

This means:

• The "cost" of team autonomy drops.
• Teams can focus even more on solving business problems instead of building technical infrastructure.
• But: Communication becomes even more important. If everyone produces code super-fast with AI, a big chaos is created just as fast if you don't talk to each other or ignore guardrails.

Conclusion & Checklist for Decision Makers

Conway's Law is not a theoretical toy for computer scientists. It is a real cost factor. If your organization doesn't communicate, your software will be expensive and error-prone.

What you can do:

1. Look at your Org: Before planning new software, check your teams. Do the people whose systems will later exchange data talk to each other?
2. Define "Guardrails": Establish what must be the same company-wide (e.g., "How do we log in?", "Which database do we use?").
3. Allow Freedom in Detail: Give teams freedom in implementation as long as they adhere to guardrails.
4. Invest in Breadth: The most important task of senior techies today is no longer to write the most complex code, but to ensure that all teams know about and benefit from each other.

Good architecture is ultimately just good communication.

Need Support?

Do you feel like your IT landscape is more of a historically grown chaos than a planned success? We help you analyze structures and implement pragmatic guardrails – for more speed and less frustration. Just get in touch via our contact page.