Conway’s Law: Why Your Organization’s Communication Structure Shapes the Systems You Build

In 1968, computer scientist Melvin E. Conway introduced an observation that would become one of the most influential ideas in software and enterprise architecture: the systems an organization builds tend to reflect the way that organization communicates.

The principle became known as Conway’s Law.

At first, it may sound like an abstract theory about organizational behavior.

In reality, it explains something architects, engineers, managers, and technology leaders encounter constantly:

Your organizational structure can quietly become your system architecture.

If your departments operate as isolated silos, there is a good chance your software, APIs, databases, and data platforms will eventually become siloed too.

If your teams collaborate effectively across boundaries, the systems they create are much more likely to integrate effectively as well.

Architecture is influenced not only by technology. It is also influenced by people, teams, ownership, and communication.

What Is Conway’s Law?

Melvin Conway introduced the principle in his 1968 paper, “How Do Committees Invent?”

His central idea was that organizations that design systems tend to produce systems whose structures resemble their own communication structures.

Imagine a company with four departments:

• Sales
• Marketing
• Finance
• Operations

If these departments rarely communicate and operate independently, each department may gradually build or adopt its own systems.

Sales may have its own customer system.

Marketing may have its own marketing platform.

Finance may maintain separate financial data.

Operations may build its own operational tools.

Over time, the company can end up with four disconnected technology environments.

The architecture begins to resemble the organization itself.

That is Conway’s Law in practice.

Your Organization Chart May Secretly Be an Architecture Diagram

Consider a company where departments communicate mainly through managers.

Developers in sales rarely speak with developers in finance.

Marketing engineers rarely collaborate with operations.

Data analysts in different departments maintain different definitions of customers, revenue, transactions, and products.

Eventually, the technology starts reflecting those same boundaries.

The company may end up with:

• A sales customer database
• A marketing customer database
• A finance customer database
• A support customer database

Then one day management asks a simple question:

How many active customers do we have?

Suddenly, four departments provide four different answers.

At first glance, this looks like a database problem.

But the root cause may actually be an organizational communication problem.

This is one of the most important lessons of Conway’s Law:

Sometimes technical debt is organizational debt expressed through software.

Data Silos Often Begin as Organizational Silos

Companies frequently complain about data silos.

They then attempt to solve them with technology.

They introduce:

• Data lakes
• Data warehouses
• Lakehouses
• ETL pipelines
• APIs
• Integration platforms
• Data catalogs

These technologies can certainly help.

But imagine three departments that disagree about what a customer means.

Sales defines a customer as someone who has signed a contract.

Marketing defines a customer as anyone with an account.

Finance defines a customer as someone who has completed a payment.

Installing a new data lake will not automatically resolve that disagreement.

Technology can combine tables.

It cannot automatically create agreement between departments.

Before creating a unified customer platform, the organization may first need a shared definition of a customer.

That requires communication and governance before technology.

Why Conway’s Law Matters for Data Architecture

Conway’s Law is particularly important for data engineers.

Suppose an enterprise has separate systems for:

• Sales data
• Marketing data
• Finance data
• Operational data
• Customer service data

If every department owns and interprets its data independently, the company may develop multiple isolated data platforms.

Each system may work perfectly on its own.

But the organization may struggle to answer cross-functional questions such as:

Which marketing campaigns generate customers with the highest lifetime value?

Answering this may require combining:

• Marketing data
• Sales data
• Payment data
• Customer data

If the teams responsible for those systems do not communicate effectively, integrating the data becomes much harder.

The problem cannot always be solved simply by purchasing another technology platform.

Sometimes the organization itself must change.

Conway’s Law and Microservices

Conway’s Law became especially important with the rise of microservices.

Suppose one large development team owns an entire application.

The team may naturally create a tightly integrated monolithic system because one group controls everything.

Now imagine separate teams responsible for distinct business domains:

• Customer team
• Order team
• Payment team
• Inventory team

Each team owns its own service and is responsible for developing, deploying, and operating it.

This organizational structure can support a microservices architecture much more naturally.

This leads to an important idea often called the Inverse Conway Maneuver.

Instead of allowing the organization to determine the architecture accidentally, leaders deliberately structure teams to support the architecture they want.

In simple terms:

If you want independent services, you may need independent teams capable of owning those services.

The Inverse Conway Maneuver

Imagine a company wants separate services for:

• Orders
• Payments
• Inventory

However, the company is organized into:

• Frontend team
• Backend team
• Database team
• Infrastructure team
• QA team

Every feature requires coordination across five different teams.

An order-related change may require approval and work from frontend, backend, database, infrastructure, and QA teams.

Even though the company wants independent services, its organizational structure makes independent delivery difficult.

A different approach would be to create cross-functional teams.

For example, an Order Team could include people capable of handling:

• Frontend development
• Backend development
• Database work
• Testing
• Deployment

A Payment Team could have similar ownership for the payment domain.

An Inventory Team could own its area independently.

Now the team structure begins to support the desired software architecture.

Architecture Can Fail Because of Organizational Structure

An architect may create a beautiful design showing:

• Shared services
• Event-driven communication
• Unified data
• Well-defined APIs
• Integrated business processes

Technically, the design may be excellent.

But perhaps:

• Sales refuses to share data
• Finance requires approval for every schema change
• Operations uses different terminology
• Teams have separate management chains
• There are no shared engineering standards
• Developers cannot easily communicate across departments

The architecture diagram may say “integrated enterprise architecture,” while the organization continues to operate as separate silos.

That architecture will struggle.

The communication paths required to operate the system simply do not exist.

Communication Paths Are Architecture Dependencies

Suppose Service A must frequently communicate with Service B.

That creates a technical dependency.

But behind those services are Team A and Team B.

If those teams cannot communicate effectively, the technical dependency becomes difficult to manage.

This means architects should ask two questions.

The first is a technical question:

Which systems need to communicate?

The second is an organizational question:

Which people and teams need to communicate to build and operate those systems?

Ignoring the second question can undermine the first.

APIs Are Also Organizational Contracts

An API may look like a purely technical interface.

But behind every API is an agreement between people and teams.

They must agree on questions such as:

• What does a customer mean?
• Which team owns customer data?
• Which fields are authoritative?
• Who can make breaking changes?
• Who maintains the API?
• What availability is expected?
• What happens when the service fails?
• How are versions managed?

An API is therefore not only a technical contract.

It is also an organizational contract.

This is another reason software architecture cannot be separated completely from organizational design.

Conway’s Law in Large Enterprises

The effect becomes even more visible as organizations grow.

Imagine a multinational company with separate business units in:

• The United Kingdom
• The United States
• Asia

Each region gradually develops its own:

• Databases
• APIs
• Authentication
• Analytics
• Infrastructure
• Business terminology

Years later, senior management decides:

We need one global customer platform.

Technically, this requires integration.

Organizationally, however, the company may still operate as three independent regional organizations.

The challenge is therefore not purely technical.

It is also organizational.

Conway’s Law Explains Some Legacy Systems

Engineers often inherit old systems and ask:

Why would anyone design the system this way?

There may have been perfectly reasonable organizational reasons at the time.

Perhaps ten years earlier the company had separate:

• Billing teams
• Customer management teams
• Warehouse teams
• Reporting teams

The software architecture may still preserve those boundaries even though the organization has changed.

Legacy architecture can therefore act like an organizational fossil.

It records how the company used to communicate.

Looking at an old system can sometimes reveal the structure of the organization that created it.

Remote Work Makes Conway’s Law Even More Relevant

Communication structures are not determined only by departments.

They are also influenced by:

• Geographic location
• Time zones
• Language
• Management structure
• Slack or Teams channels
• Meetings
• Reporting relationships
• Documentation practices
• Access permissions

Imagine developers distributed across London, Dhaka, New York, and Singapore.

If some groups communicate constantly while others are rarely included in architectural discussions, those communication patterns may eventually appear in the software.

Distributed organizations therefore need intentional communication design just as much as they need technical design.

Conway’s Law and DevOps

Traditional organizations often separated developers and operations.

Developers built the software.

Operations ran the software.

This separation frequently created friction.

Developers might say:

It works on my machine.

Operations might then struggle with deployment and production failures.

DevOps attempts to reduce this organizational boundary.

Development, operations, and quality assurance work more closely together and share responsibility for production systems.

This is why DevOps is not merely about tools such as:

• Docker
• Kubernetes
• Terraform
• Jenkins
• GitHub Actions

DevOps is also about communication, ownership, and team structure.

Conway’s Law and Cloud Architecture

Moving an application to AWS, Azure, or Google Cloud does not automatically modernize an organization.

A company can migrate its existing silos into the cloud and still have exactly the same problems.

For example, sales, marketing, finance, and operations may each create separate cloud environments with different:

• Standards
• Identity systems
• Data structures
• Security policies
• Deployment practices
• Integration mechanisms

The company may have successfully migrated to the cloud while preserving all of its organizational fragmentation.

Cloud transformation therefore often requires organizational transformation as well.

What Architects Should Learn From Conway’s Law

Before designing a new architecture, architects should understand the organization that will build and operate it.

Ask:

Who talks to whom?

Understand the real communication paths, not only the organization chart.

Where are the organizational silos?

Look for teams that rarely collaborate.

Who owns each business capability?

Ownership boundaries often become system boundaries.

Where are decisions made?

Highly centralized organizations create different systems from highly autonomous organizations.

Which teams depend heavily on each other?

Too many cross-team dependencies can indicate poor architectural boundaries.

Does the desired architecture match the team structure?

If it does not, implementation may become difficult.

Should the organization change?

Sometimes restructuring ownership or teams is more effective than forcing a technology architecture that conflicts with the organization.

A Practical Conway’s Law Architecture Review

Before approving a major architecture, ask:

• Who owns this system?
• Who develops it?
• Who deploys it?
• Who operates it?
• Who approves changes?
• Who responds when it fails?
• Which other teams does this team depend on?
• How frequently must those teams communicate?
• Are those communication paths easy or difficult?
• Does the technical architecture match the organizational reality?

Then compare the technical architecture with the communication architecture.

If they are dramatically different, investigate why.

That mismatch may become a serious delivery risk.

A Powerful Question for Architects

Conway’s Law leads to one of the most useful questions an architect can ask:

Is our organizational structure preventing us from building a better system?

If the answer is yes, architecture changes alone may not be enough.

The organization may need to reconsider:

• Team ownership
• Reporting structures
• Communication channels
• Responsibilities
• Decision authority
• Domain boundaries
• Collaboration practices

Sometimes the best architecture decision is actually an organizational decision.

The Bigger Lesson

Conway’s Law teaches us that systems are built by people.

Behind every application, service, database, API, and data pipeline are:

• People
• Teams
• Communication patterns
• Ownership structures
• Decision-making processes

Those organizational structures strongly influence the technology that eventually emerges.

This means good architects need to understand more than:

• Databases
• APIs
• Microservices
• Cloud infrastructure
• Messaging systems
• Kubernetes
• Data pipelines

They also need to understand:

• Organizational design
• Team boundaries
• Communication
• Ownership
• Collaboration
• Business domains

Because we do not design systems in isolation.

Organizations design systems, and organizations leave their fingerprints on everything they build.

Final Thought

Conway’s Law was formulated more than half a century ago, but it may be even more relevant today.

Modern organizations are building increasingly complex combinations of:

• Microservices
• Cloud platforms
• APIs
• Event-driven systems
• Data platforms
• AI systems
• Distributed teams

The temptation is to treat architecture as a purely technical problem.

Conway’s Law reminds us that it never really is.

When you encounter a fragmented system, do not look only at the code.

Look at the teams.

When you encounter duplicated data, do not inspect only the databases.

Look at ownership.

When services constantly depend on each other, do not look only at the APIs.

Look at how the teams responsible for those services communicate.

Before designing your next enterprise architecture, ask:

Does the organization communicate in a way that can actually support the architecture we are trying to build?

Because eventually, whether intentionally or unintentionally, the architecture will begin to resemble the organization that created it.