Conways Law - Your Org Chart Is in Your Architecture
Why the systems we build inevitably mirror the organizations that build them.
Every Diagram Tells Two Stories
I’ve reviewed hundreds of architecture diagrams over the course of my career. Some covered a single whiteboard. Others stretched across multiple pages with so many arrows they looked more like subway maps than software systems.
Early in my career, I thought architecture diagrams were about technology.
- What cloud platform are they using?
- Why did they choose Kubernetes?
- Should this service be event-driven?
- Why is that database shared?
Those are still important questions, but experience has taught me something else.
Architecture diagrams tell two stories.
The obvious story is about technology.
The hidden story is about people.
Every system reveals how an organization communicates, where decisions are made, who owns what, and where collaboration breaks down. Once you start looking for it, you can’t unsee it.
I’ve reached the point where I often ask about the teams before I ask about the architecture.
- How many engineering teams are there?
- Who owns deployment?
- Who approves infrastructure changes?
- How many groups have to coordinate before a feature reaches production?
Those answers frequently predict the architecture before anyone opens Visio or Lucidchart.
That observation has a name.
Conway Saw This Coming
In 1967, computer scientist Mel Conway made a remarkably simple observation:
Organizations design systems that mirror their communication structures.
We now know this observation as Conway’s Law, and in my experience it’s one of the most consistently accurate principles in software architecture.
The important part isn’t that organizations influence architecture.
It’s that they can’t help but influence architecture.
- Communication becomes interfaces.
- Departments become service boundaries.
- Approval chains become deployment pipelines.
- Organizational friction becomes technical complexity.
Software is often just an organizational chart rendered as infrastructure.
Understanding this changes the questions an architect asks. Instead of only asking whether the technology is correct, we begin asking whether the organization can successfully own, evolve, and support what we’re designing.
The encouraging part is that while organizations shape architecture, architecture can also shape organizations. Deliberately defining service boundaries, ownership, and interfaces often encourages teams to communicate more effectively. That gives architects an opportunity to influence not only technical systems, but the organizations that build them.
Once you begin looking at architecture through this lens, certain patterns become almost impossible to ignore.
Seeing the Org Chart
After enough consulting engagements, certain patterns become impossible to ignore.
Every Team Gets a Service
Sometimes an environment contains dozens of microservices.
At first glance, it looks like a carefully planned domain-driven architecture.
Then you learn there are exactly the same number of engineering teams.
Coincidence?
Usually not.
Services often form around ownership boundaries because teams naturally optimize for autonomy. That’s not necessarily bad—but it’s important to recognize when organizational structure is driving technical design.
I remember sitting with a help desk analyst while they worked through an outage. Before they could even assign the ticket, they first had to determine which product it belonged to. That meant working through pages of decision trees before finding the correct engineering team. The system eventually worked, but every incident spent precious time navigating the organization before anyone could solve the technical problem.
The Shared Database
Other organizations have the opposite problem.
Multiple applications read from and write to the same database.
Every change requires coordination.
Every deployment feels risky.
At first glance, it appears to be a technical decision.
Sometimes it is.
Other times it’s because a single database administration team owns every database in the company, making centralized ownership the path of least resistance.
The architecture reflects the organization more than the business domain.
I worked with another client that offered several products, yet every one of them depended on the same DBA team. As long as development followed established schemas and stored procedures, progress was smooth. The moment a product needed customization or optimization, however, it joined the same backlog as every other application.
The technical limitation wasn’t the database.
It was organizational ownership.
The Integration Team
I’ve also encountered organizations with entire departments dedicated to integration.
Their mission isn’t to build business functionality.
Their mission is to connect systems that other teams cannot—or do not—coordinate directly.
The integration platform becomes a technical solution to an organizational communication problem.
I once consulted for a company with eight independent development teams. Each was a well-oiled machine consisting of four developers, a business analyst, and a tester. Every two weeks they reliably delivered everything they had committed to.
There was only one problem.
The teams rarely communicated with one another.
Management responded by introducing release managers, program leads, and eventually the Scaled Agile Framework (SAFe). Releases became manageable, but “Go/No-Go” meetings still routinely uncovered integration issues that no individual team had anticipated.
The architecture wasn’t failing because the engineers were ineffective.
It was faithfully reflecting how the organization communicated.
Cloud Doesn’t Break Conway’s Law
One misconception I’ve encountered repeatedly is the belief that moving to the cloud automatically modernizes architecture.
It certainly modernizes infrastructure.
Whether it modernizes architecture depends entirely on the organization.
I’ve seen monoliths become distributed monoliths.
I’ve seen virtual machines become containers without changing deployment practices.
I’ve seen organizations adopt Kubernetes while still requiring four approval meetings before every production release.
The technology changed.
The communication patterns did not.
Cloud platforms remove technical constraints.
They cannot remove organizational ones.
One of my recent clients was standardizing cloud ingress for business partners across multiple cloud providers. AWS was straightforward because the engineering team owned both the platform and the process.
Azure told a different story.
Provisioning a subscription required business plans, architectural reviews, and multiple approvals before a single resource could be deployed.
Nothing about Azure required that process.
The organization did.
That model had been established years earlier by a consultant who designed a governance framework appropriate for the organization’s needs at the time. Over the years it became institutionalized. The Azure platform evolved, but the operating model remained largely unchanged.
Teams still mirrored a traditional data center organization—networking, configuration management, security, and infrastructure all operated independently—while the business was trying to deliver cloud environments in under ten days.
Technical Debt or Organizational Debt?
When architects encounter complexity, the instinct is often to solve it with better technology.
- A new platform.
- A better framework.
- Another automation tool.
Sometimes that’s exactly the right answer.
Sometimes it isn’t.
Many architectural “smells” have organizational causes:
- Services with unclear ownership
- Duplicate platforms
- Inconsistent standards
- Excessive approval gates
- Multiple deployment pipelines for identical workloads
- Teams solving the same problem independently
None of these originate in Terraform, Kubernetes, Azure, or AWS.
They begin with people.
Technology merely preserves them.
What Architects Actually Design
One lesson took me years to appreciate.
Architects don’t just design systems.
They design communication.
Every service boundary defines who must collaborate.
Every API defines a relationship between teams.
Every ownership decision shapes future conversations.
The best architectures I’ve worked with weren’t simply technically elegant.
They made it easier for people to work together.
Conversely, the worst architectures weren’t always built by poor engineers.
They were built by organizations that unintentionally created friction through their structure.
As architects, we spend enormous effort choosing technologies.
Perhaps we should spend just as much effort understanding the organization that will build and operate them.
Final Thoughts
Today, when someone hands me an architecture diagram, I still study the technology.
But I also look for something else.
- Where are the boundaries?
- Who owns each service?
- Which interfaces exist because of business requirements, and which exist because two departments don’t communicate?
Those questions often explain more than the diagram itself.
Technology evolves.
Cloud platforms evolve.
Frameworks come and go.
People, however, remain at the center of every system we build.
Every architecture review begins with boxes and arrows.
The best ones end with conversations about people.
Because in the end, software isn’t just built from code.
It’s built from communication.