A Corollary to Conway's Law - Build for The Team You Have

Melvin Conway has a law that I’ve heard thrown about throughout my career building applications and backend systems. Verbatim it states:

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.

Or, put simpler - your system/product/service/software reflects the organization of teams interacting with and building it. I’ve seen this play out over and over in organizations I’m intimately familiar with and ones I’ve been a curious outsider peering into.

The law has been reworded and remixed once embraced by the software community. There’s even a fun corollary conjectured that long-running systems not only represents the current team’s organizational structure, but also the organizational structures of prior development teams.

I’d like to submit my own corollary; one that, while I’m not confident on its originality, I’ve not seen stated elsewhere. Like the base law, I can say confidently I’ve seen its effects cause issues.

If a system is designed in a manner that is the antithesis to the structure of its supporting teams, the system will fail.

Or, simplified - don’t introduce unnecessary friction just because you tried to be clever in your design. As a software architect you must pay attention to your team structure and processes or what you build will be the bane of too many coworkers' existence.