2 min read (236 words)
A wrong but useful model I like is the Conway’s Law, stating: "Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure." (cf source).
I often found it relevant. We reproduce the communication patterns into what we build as a team. When looking at some products or software architecture, I like to imagine the setup of the team(s) who built it.
Ex: a very strong decoupling between two features with a light integration in between in terms of UX/UI and navigation, there is a good chance that two different teams built them.
Ex: a very strong separation between frontend & backend code that looks like two different applications in the code base, communicating through web API. I’d bet the team is organized with the backend team on one side, and the frontend team on the other.
As a team, we look for autonomy and ownership of the things we’re working on.
We tend to reproduce the communication constraints or the contracts we may have with other teams or other teammates.
When I craft a new organization or form a new team, I like to use Conway’s to try to predict or to guess the outcomes. It’s also known as Inverse Conway Maneuver.
It’s a way to promote the desired architecture or expected result by shaping the organization upfront.