Conway's Law

A product built by three teams that don't talk to each other will have three UI styles, three data models, three login flows, three ways of handling errors, and three slightly-different definitions of 'user'.

You can try to fix this with a design system, a style guide, or a 'consistency review' in the calendar. Those help at the edges. But the only durable fix is to change the team structure — because the team structure is creating inconsistency faster than any design system can clean it up.

There's a flipped version of this worth knowing, often called the inverse Conway move: if you want a specific product architecture, build the team structure that would naturally produce it. PMs who understand this pick their battles at the org-chart level, not the code-review level.

A mobile trading app has four main tabs, each built by a different squad:

• Tab 1 uses Figma component library v4 with rounded cards
• Tab 2 uses v3 with square cards (they shipped before v4 landed and never migrated)
• Tab 3 has its own custom error toast because the squad's designer disagreed with the system's pattern
• Tab 4 uses the system toast, but calls the endpoint synchronously so errors block the whole screen

Users think the app is 'inconsistent' or 'buggy'. It isn't — it's exactly four squads' worth of engineering, faithfully rendered as UI.

Hiring a consistency czar won't fix it. Merging two of the squads, or creating a platform team whose explicit remit is the seams between them, will.