The architecture is the org chart
Conway's Law isn't a warning — it's a design tool. If you want a system with clean boundaries, start by drawing clean boundaries between the people.
Every system I have ever inherited told me exactly how its builders were organized. Not through documentation — through its seams. The awkward integration between two services almost always maps to two teams that never talked. The elegant, coherent module maps to a single group with a shared understanding.
We treat Conway's Law as a caution: 'be careful, your system will mirror your communication structure.' I have come to treat it as a lever. If I want a particular architecture, the fastest path is to shape the teams to match it first.
Boundaries are cheap on a whiteboard
The hard part of architecture is never the diagram. It is the negotiation about who owns what, who is paged at 3am, and whose roadmap absorbs the cost of a shared dependency. Those are org questions wearing an engineering costume.
A boundary that no team is accountable for is not a boundary. It is a future incident.
How I use it in practice
- Design the team topology and the service topology in the same meeting.
- Give every interface an owning team before writing a line of contract.
- When two services keep leaking into each other, ask whether the two teams should merge.
- Reserve platform teams for capabilities, not for glue nobody wanted.
None of this is new. But naming it out loud changes the conversation from "what should we build" to "who should we become to build it." That is a far more honest place to start.