This is part of a sequence of posts on engineering principles.
What is Conway's Law?
Conway's law was popularized in 1967 by Melvin Conway, a prominent American computer scientist. He proposed that:
[O]rganizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.
Since then, there have been various refinements and reformulations of the principle (some of which are quite humorous - I enjoy a car industry joke that goes like this: You can see the organization chart of a car company in the dashboard, and also see whether the steering wheel team hates the gear stick team). Generally speaking the concept is simple in practice: communication among people (both on and between teams) is fairly difficult. So, having product design match team communication lines tends to minimize the number of people in an organization that need to communicate directly with each other.
How does this work in practice?
Generally speaking, developers spend far more time worrying over the organization of our code and the strategy of our design than the organization of our people, and the alignment between our team structure and our product. I have spent quite a few years working on HubSpot's infrastructure product, and our teams are deployed along somewhat organic boundaries (e.g. we have a deploy team, and a monitoring team, and a sql team), and the result is an internal infrastructure product that tends to have one page per team - each team organizes what they can do internally, with fairly robust boundaries. If you're a developer who wants to perform a task, you will find yourself answering the question "which team probably owns this?" so you can navigate to their space.
So?
I would argue that our job as developers is to minimize the cognitive load of our customers. Infrastructure engineers attempt to provide simple solutions for product engineers, and product engineers attempt to provide simple solutions for customers of the company. Each of our actions can have an outsize affect - a confusing decision can cost hundreds of engineers many hours, or millions of customers far more. So, we have to bear in mind that our inclination will be to minimize the difficulty of the work we do, which will lead us into the trap of Conway's law. My favorite way to counter this is by starting the ideation for solution design from the customer/use case. If you imagine what the customer knows, and how they will think of the problem, you can decide how the solution ought to look, and use that to determine which teams should work on it (and how).
