Conway's law and team shape

Conway's law says that organizations design systems that copy their own communication structure. Melvin Conway observed this in 1968. Four teams building a compiler produce a four-pass compiler. For microservices, this is the main reason they help. They let separate teams ship on their own schedules, so the organization's shape ends up in the architecture.

The big idea

Picture 300 engineers in one codebase. Every deploy bundles changes from dozens of teams. One team's broken test blocks everyone, and nobody fully understands the release. Split the system into services that map to teams, and that changes. Each team deploys on its own schedule, runs its own on-call rotation, and changes its internals without a shared release. Amazon's "two-pizza teams", small teams that own services end to end, are the well-known example.

Conway's law describes a tendency, not a physical law. Teams can design their structure on purpose instead of letting it happen by accident.

Walking through it

Compare two set-ups for the same product:

The corollary matters for small companies. If one team of eight engineers builds the product, there is one communication structure. Splitting into twelve services adds the operational cost of microservices and none of the organizational benefit. The same team still makes every change.

Platform teams fit the same picture. The book Team Topologies (Skelton and Pais, 2019) describes stream-aligned teams that own business capabilities, and platform teams that provide shared infrastructure. That is where platform engineering comes from.

Common mistakes

• Splitting services without splitting ownership. If two teams share one service, you pay the coordination cost without the autonomy.
• Splitting a small team. The operational cost arrives on day one. The organizational gain doesn't.
• Expecting microservices to fix a communication problem. If every interface change still needs manual agreement, separate services just move the argument into the APIs.

Check yourself

1. Why does a team of eight gain little from twelve services?

   The same team still makes every change, so the services remove no coordination, and the operational cost rises.

2. What is the inverse Conway maneuver?

   Design the team structure to match the architecture you want, so the system's boundaries follow team boundaries you chose on purpose.

Key takeaways

• Systems tend to copy the communication structure of the teams that build them.
• Microservices help mainly by letting teams ship independently.
• Team structure is a design decision, and you can make it on purpose.
• A small team gets little from splitting, but it still pays the operational cost.

Further learning

Next: bounded contexts, which covers where the boundaries should go.