Put bluntly, does Conway's Law give me anything actionable to consider when I'm building an engineering org?
- can we use this to empower a team to really focus on a key component, removing other concerns from them?
- how do we ensure consistent quality across the user experience, if different teams own different parts?
But I don’t yet have a clear thesis, or even a collection of key tradeoffs to consider when thinking about how the org design will impact the product.
Because your architecture will match your communications structure, it means that if you want your system to work a certain way, you’ll want to make your org chart match it. If the system architecture is the thing you want, and the org chart is what you can control, it follows that you should mold your organization to match your desired architecture.
Conway’s law is a law, not an anti-pattern. Resisting it is a bad idea, instead learn and understand it, and plan around it.