Conway’s Law in the Wild: Why Your Microservices Look Suspiciously Like Your Org Chart

Here’s a strange but reliable pattern: if you look at the architecture diagram of almost any mid-size tech company, you can guess how their org chart is drawn. Not because someone planned it that way. It just… happens.

This pattern has a name: Conway’s Law. It was named after Melvin Conway, a programmer who noticed it back in 1967. The plain-language version is this:

The way your teams are organized will end up shaping the way your software is organized — whether you intend it to or not.

If that sounds abstract, let’s make it concrete with a story.

The TicketWave Example

Imagine a company called TicketWave that sells event tickets online. In year one, they have a single small engineering team of eight people. Everyone works on one shared codebase — one big application that handles browsing events, picking seats, and paying for tickets. Because it’s one team sitting in one Slack channel, talking constantly, the code stays reasonably well organized. Changes to “how payment works” and changes to “how seat selection works” get discussed together, because the same people are in the room.

By year two, TicketWave has grown. Now there are 40 engineers, and one team of 40 is unworkable — nobody can keep track of what everyone else is doing. So the company splits into two teams: a Checkout Team (handles payments, carts, and orders) and an Inventory Team (handles which seats exist and which ones are still available).

Six months later, without anyone officially deciding this in a design meeting, the codebase has split into two services: a Checkout Service and an Inventory Service, talking to each other over an API. Nobody wrote a document that said “we shall now build two services.” It just happened, team by team, pull request by pull request. Each team owned its own code, deployed on its own schedule, and stopped needing to coordinate every change with the other team.

That’s Conway’s Law playing out in real time. The software boundary (two services) grew to match the team boundary (two teams), because that’s the boundary where communication got harder and hand-offs got more formal.

Why does this actually happen?

It’s not magic, and it’s not really about anyone being lazy. It comes down to communication cost. When two people sit on the same team, in the same standup, they can shout a question across the room and get an answer in ten seconds. When two people are on different teams, getting an answer usually means: opening a ticket, waiting for a meeting, or pinging someone who might be busy for two days.

Software naturally organizes itself to minimize that friction. Code that needs constant back-and-forth discussion tends to stay inside one team’s boundary, because that’s cheap. Code that only needs an occasional, well-defined exchange (like “give me the ticket price” or “tell me if this seat is available”) gets pushed out to an API between teams, because that’s a communication channel that can survive being slow and formal.

In other words: your system’s seams show up exactly where your organization’s communication gets expensive.

Why this matters for architects and engineers

Here’s the part that’s easy to miss if you’ve never seen it named: this isn’t just a curiosity. It means your org chart is quietly acting as an architecture decision, whether or not anyone treats it that way.

If you reorganize your teams — say, you merge the Checkout Team and Inventory Team into one “Orders Team” because of a restructuring that has nothing to do with technology — don’t be surprised if six months later, the codebase starts drifting back toward one shared service. Not because engineers are undoing good architecture on purpose, but because the team boundary that used to justify two services is gone, and new code will naturally follow the new, cheaper communication path.

The reverse is also true, and this is the more useful direction: if you want a particular architecture, you can often get there faster by changing the team structure first, rather than trying to enforce the architecture through documentation and code review alone. This idea has its own name — the Inverse Conway Maneuver — and it just means: design your teams around the system boundaries you want, and let the software follow.

For example, if TicketWave wanted a clean, independent “Notifications Service” (the part that emails and texts customers about their tickets), the fastest way to make that boundary real and durable is to actually give one team clear, sole ownership of it — not just write “Notifications Service” in an architecture diagram and hope every team respects the boundary.

Team boundaries tend to become service boundaries — the API between two services is often just a formalized version of the hand-off between two teams.

A few practical takeaways

• When you see a messy service boundary, check the org chart first. A “God service” that five different teams all touch is often a sign that those five teams are being forced to share one piece of software that no longer matches how they’re organized. The fix might be organizational, not just technical.
• Before a reorg, ask what it will do to your architecture. Merging or splitting teams isn’t architecture-neutral. It’s worth a five-minute conversation with an architect before it happens, not six months of confused pull requests after.
• If you want a boundary to hold, give it an owner. A boundary that “everyone” is responsible for is a boundary that nobody actually maintains. Conway’s Law suggests that durable software boundaries need a durable team behind them.
• Don’t fight the grain forever. If your org keeps naturally pulling two “separate” services back together despite your best efforts, it might be telling you something true: maybe they were never really separate concerns to begin with.

Wrapping up

Conway’s Law isn’t a rule you need to enforce — it’s a rule that’s already quietly enforcing itself, in every codebase, all the time. The useful move isn’t to fight it, but to notice it. Once you can see that your architecture is a mirror of your team structure, you get a second lever to pull: instead of only redesigning the software, you can sometimes redesign the team, and let the software catch up on its own.

Next time you’re in a meeting arguing about where a service boundary should go, it might be worth asking a different question first: where does our team boundary already go? You may find the two questions have the same answer.