Your Architecture Is a Mirror

In 1968, Melvin Conway observed that organizations design systems that mirror their own communication structures. It became known as Conway’s Law, and it has been cited so frequently in software architecture discussions that the implications are sometimes overlooked.

Here’s the implication worth sitting with:

If your architecture reflects your culture, then any architectural change that doesn’t fit your culture will be rejected.

Not necessarily loudly, not even deliberately, but reliably. The organization will find a way around it. Teams will revert to familiar patterns. The new system will be adopted in name and ignored in practice. You’ll wonder why it didn’t stick.

This isn’t a failure of execution. It’s a failure of fit.

Before going further, it’s worth drawing a distinction that gets collapsed too often:

Organizational values are not the same as cultural values.

Organizational values are declared. They live on the careers page, in the company handbook, in the all-hands presentation. They describe what the organization aspires to be, or what it wants to be seen as. They are often genuine. They also often don’t fully match the day-to-day reality of how people actually work.

Cultural values are observed. They emerge from how decisions get made when nobody is watching, how conflict is handled, what gets rewarded, what gets tolerated, who has informal influence and why. Culture is what happens in the room before the meeting starts, in the hallways and in the Slack channels that leadership doesn’t see.

The gap between the two is normal: Organizations are complex and the distance between aspiration and reality is normal. But that gap starts to matter significantly when you’re trying to introduce change.

If you map your solution to organizational values, you’re designing for the aspiration. If you map it to the cultural values, you’re designing for the reality. Only one of those approaches produces something that actually gets adopted. You can probably guess which one would be most successful.

Conway’s Law is usually discussed in the context of software systems, where microservices reflect siloed teams, monoliths reflect a tightly coupled organization. It applies equally however, to any structural decision in an engineering organization: how you do code review, how you manage deployments, how you govern shared resources, how you make architectural decisions. And even the smallest decisions on engineer-level will add up to a system eventually.

In each case, the structure that survives is the one that fits how the people actually prefer to work: their habits, their autonomy and reach, how they’re aligned. Introduce a structure that doesn’t fit and you’ll spend more energy maintaining it than it ever returns in value.

This means that before you design a solution, you need to understand the culture you’re designing for. Not the culture as described in the handbook, but the actual culture as it operates daily.

An example: when working on design system governance and adoption across a large engineering organization, the instinct is to start with the system itself. The design patterns, the component library, the contribution model, the adoption handbook. We started differently. We started with the people. What did the teams actually value? How did they think about ownership? How did they feel about spending their resources? Where did they feel the existing process let them down? What would make them want to contribute rather than build around the system?

By the time we had answers to those questions, the governance model emerged almost automatically. The guidelines we produced mapped directly to the values the culture had already expressed. The result wasn’t a process imposed on teams.

The result was a process that felt like it belonged to them.

That distinction is the difference between adoption and compliance.

Culture is not static. But it’s changes are slow, and force is met with equal (or greater) force in the opposite direction. No sudden movements!

To change the culture you have to break the self-reinforcement loop. One way is changing the inputs: who and what gets rewarded, what gets resourced.

Example: If your sprint reviews only celebrate shipped features (yay!), add a slot for teams that improved documentation, cleaned up a shared component, or unblocked a colleague. The behavior you recognize publicly is the behavior you get more of.

The other way is changing the beliefs directly, which is slower and requires people the culture already respects to model the new normal.

Example: The tech lead starts writing brief decision records for their own work. Not by mandating it, just by doing it publicly. Or a senior engineer references that Architecture Decision Record (ADR) in a code review instead of re-explaining the reasoning verbally. None of these are policy changes.

But over time they shift what "normal" looks like, and once that shifts, the behavior follows without anyone having to enforce it.

What definitely doesn’t work is announcing a new culture and expecting it to stick.

What doesn’t work is introducing a structural change. Whether it’s a new process, a new architectural pattern, a new governance model, without addressing the culture. The change will either die a slow death or get bent back toward the existing shape.

What does work is slower to implement and to describe: understanding the existing culture well enough to find the changes that fit within it, introducing those first, building trust and demonstrating that the new approach produces better outcomes. Using it as proof and as a stepping stone to reach the harder changes.

Culture shifts at the speed of evidence, not announcements.

In the second part, I get into the practical side: how to actually read your engineering culture before you design for it, how to map proposed changes to what you find, and how to introduce architectural or process changes in a way that fits the culture rather than fighting it.
Including what to do when the culture itself is the thing that needs to change.

The starting point is observation, not conducting surveys. Surveys tell you what people think you want to hear, or what they consciously believe. Neither of which is quite the same as how they actually behave.

What you’re looking for is the gap between the stated and the real.