Conway's Law in Practice

In 1967, a programmer named Melvin Conway submitted a paper to the Harvard Business Review.

They rejected it. The reason: he hadn't proved his thesis.

To be fair, Conway had buried his thesis in paragraph 43 of a 45-paragraph paper. But the idea he'd hidden there would reshape how we think about organizations and the systems they build.

The thesis: "Any organization that designs a system will produce a design whose structure is a copy of the organization's communication structure."

Fred Brooks read the paper, cited it in The Mythical Man-Month, and called it "Conway's Law." The name stuck.

Conway's Law sounds abstract until you watch it operate.

A company has three development teams: frontend, backend, database. They build a product. The product has three layers: a frontend, a backend, a database. Each layer communicates through formal interfaces because each team communicates through formal interfaces.

Nobody designed it this way. The architecture emerged from the org chart.

Now imagine the same company reorganizes into product teams. Each team owns a complete feature: search, checkout, recommendations. What happens? The architecture fragments into services. Each service mirrors a team. Boundaries between services follow boundaries between teams.

Conway's Law isn't a suggestion. It's physics.

You cannot build microservices with a monolithic org structure. You cannot build a clean monolith with distributed teams. The boundaries will leak through.

Your org chart is your architecture. Whether you want it to be or not.

In 2002, Amazon was struggling to scale.

Jeff Bezos issued a mandate to every development team:

1. All teams will expose their data and functionality through service interfaces.
2. No other form of communication allowed. No direct linking. No shared databases. No back doors.
3. All interfaces must be designed to be externalizable.

The final line: "Anyone who doesn't do this will be fired."

Bezos wasn't making a technical decision. He was making an organizational one. If teams could only communicate through APIs, they would build systems that communicated through APIs.

The mandate forced Amazon's architecture to become modular. Teams deployed independently. Services scaled independently. Eventually, Amazon realized they could sell these services to others.

AWS didn't emerge from a technology breakthrough. It emerged from an organizational constraint that shaped what was possible to build.

If Conway's Law is physics, you can use it strategically.

This is the Inverse Conway Maneuver: design your organization to get the architecture you want.

Want microservices? Create small, autonomous teams with clear boundaries.

Want a unified platform? Create cross-functional teams that share context.

Want to break a monolith? Break the team first. The code will fragment along team boundaries whether you plan it or not.

The companies that scale successfully aren't fighting Conway's Law. They're wielding it.

But there's a trap.

In 2012, Spotify published a blog post describing their organizational model: squads, tribes, chapters, guilds. The vocabulary was compelling. The diagrams were elegant. Companies everywhere copied it.

Most of them failed.

Here's what those companies didn't know: Spotify wasn't actually using the Spotify model. One of the co-authors later admitted, "Even at the time we wrote it, we weren't doing it. It was part ambition, part approximation."

Companies copied the vocabulary without the context. They created squads without the culture. They drew the org chart without understanding what made it work.

The problems were predictable. Too much autonomy without enough coordination. No common process for cross-team collaboration. The model assumed maturity that teams didn't have.

Copying an org chart doesn't give you the architecture. The architecture emerges from how people actually communicate, not from what you call them.

This is cargo-culting Conway's Law. You build the runway. You build the control tower. No planes land.

The lesson is uncomfortable.

You can't copy your way to the architecture you want. You can only build the communication patterns that produce it.

Amazon's API mandate worked because Bezos enforced it ruthlessly. The constraint was real, not aspirational.

Spotify's model failed elsewhere because the culture couldn't be exported. The diagrams traveled. The trust didn't.

Conway's Law works in both directions. Look at how an organization communicates, and you'll see what architecture it will produce. Change the communication, and you'll change the architecture.

Structure shapes what's possible. But structure only works when it's real.

The diagnostic is simple.

Look at your architecture. Look at your org chart. Do they match?

If yes: Conway's Law is working. The question is whether it's producing what you want.

If no: Someone is fighting physics. They're probably losing.

Your org chart is your architecture.

Design accordingly.

This post explores Structural Constraint, one of four dynamics from The Momentum Engine. Conway's Law isn't a suggestion. It's physics. The question is whether you're using it or fighting it.