Designing Engineering Organizations - Jacob Kaplan-Moss
I have often read about Conway’s Law. But never really understood it at practical level. This post by Jacob explains it well. It also provides a good framework on how to structure teams.
The guiding principle here is that Conway’s Law is inescapable – you ship your org chart. And, wherever possible, you should optimize for delivery. In other words: design your organization to match what you want to ship.
Generally, product-aligned teams deliver better products more rapidly. Again, Conway’s Law is inescapable; if delivering a new feature requires several teams to coordinate, you’ll struggle compared to an org where a single team can execute on a new feature.
It is very common structure the teams by skillsets. That is the first intuition. But the whole post advices on having teams which are integrated. Teams which are responsible for shipping a particular feature or product. The team should have a frontend designer as well as a backend one.
Organizations are trying to optimize for delivery, and having one team – including its manager – wholely responsible for delivery is highly effective. Skills-aligned teams can struggle with actually shipping: when they miss deadlines it can be easier to point fingers at some other team than accept responsibility.
If you’re trying to optimize for delivery, then stable, multi-disciplinary, and product-aligned should the principles that guide how you form teams. There are reasons (some of them good) to deviate from these principles, but the tradeoff will always be that it’ll be more difficult to ship.