Conway’s Law in real systems
Share
Why your architecture mirrors your organization
There is a moment, in every complex system, when something feels off.
Nothing is obviously broken.
The code compiles, the services respond, deployments still happen.
And yet, every change feels heavier than it should.
Every new feature requires more coordination than expected.
Every discussion turns into a negotiation.
At first, it looks like a technical problem.
It rarely is.
Melvin Conway described it decades ago in a single, deceptively simple idea:
Systems mirror the communication structure of the organizations that build them.
It is often quoted, rarely understood.
Because it is not just an observation.
It is a constraint.
In theory, architecture is designed.
We draw boundaries, define services, assign responsibilities.
We imagine clean separations and well-defined interfaces.
In practice, architecture emerges.
It grows from conversations, compromises, misunderstandings.
From who talks to whom, from who is allowed to decide, from how often people align.
A team that communicates constantly will produce tightly coupled components.
A team that is isolated will produce independent systems, whether that independence was intended or not.
Over time, these patterns solidify.
What started as communication becomes structure.
What was structure becomes code.
And eventually, the system behaves exactly like the organization behind it.
This is why so many systems feel incoherent.
Not because the engineers lack skill,
but because the organization itself is fragmented.
Responsibilities overlap.
Ownership is unclear.
Decisions are distributed without alignment.
The architecture reflects this perfectly.
Services depend on each other in unpredictable ways.
Boundaries exist on diagrams, but not in reality.
Changes require coordination across multiple teams, each with partial understanding of the system.
The system is not broken.
It is simply telling the truth about the organization.
Microservices make this even more visible.
They promise independence, but only deliver it when the organization can support it.
Without clear ownership, services become shared.
Without aligned teams, interfaces become unstable.
Without trust, every change becomes a negotiation.
Instead of independent systems, you get a distributed monolith —
not because the technology failed, but because the organization did.
There is a quiet paradox in all of this.
We often try to fix architecture with better architecture.
We introduce new patterns, new tools, new abstractions.
We redraw diagrams, hoping that clarity on paper will translate into clarity in reality.
But systems do not follow diagrams.
They follow people.
If teams are not aligned, the architecture will drift.
If communication is inefficient, dependencies will multiply.
If ownership is unclear, boundaries will dissolve.
No amount of technical refinement can compensate for that.
Real change starts elsewhere.
It starts by asking different questions.
Who owns this system, really?
Where does a decision begin and end?
Which teams need to move independently, and which ones should not?
When those answers become clear, architecture becomes almost obvious.
Boundaries stop being theoretical.
They become enforceable, because they reflect how people actually work.
And when that happens, something shifts.
Changes become simpler.
Coordination decreases.
The system feels lighter, not because it is smaller, but because it is coherent.
Conway’s Law is not something to fight.
It is something to use.
It tells you that architecture is not just a technical artifact.
It is an organizational mirror.
And if you want to change the system, you have to be willing to look at what it reflects.
In the end, systems do not become complex on their own.
They become complex because the organizations behind them are.
Clarity in architecture begins with clarity in structure, in ownership, in communication.
Everything else follows.
Or doesn’t.