Last week I wrote about scaling frameworks and the desire to manage the complex dependencies between different parts of IT or development organisations using them.
If organisations do not seem to deliver the intended results there may be another factor at play:
More than 50 years ago computer scientist Melvin Conway observed that: “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.”
Computer scientists keep joking that when you work with four teams to develop a compiler, you will end up with a 4-pass compiler, while tasking two teams with the same will result in a 2-pass compiler. For the uninitiated: the later would usually be considered to be more effective. You get the idea.
‘Conway’s law’ as this observation became known (in scientific circles also dubbed the ‘mirroring hypothesis’) has fundamental implications for the design of organisations. If your structure is not aligned with what you are trying to build, you are bound for problems.
Ideally you want an organisation setup where teams can act largely autonomously in delivering business value, requiring minimal coordination with other teams.
Two models for achieving this ideal are commonly applied:
- creating a platform architecture that allows teams to act largely independently. Netflix and Amazon (among others) have opted for this approach, giving the famous ‘two-pizza teams’ almost full control over their domains.
- modeling the teams after domains that follow the boundaries of business reality, a practice known as Domain Driven Design (DDD).
Domain Driven Design aims to separate system components based on intention, not technology. The use of common natural language to describe the domains avoids technology considerations in the process as much as possible.
Shaping an organisation to largely mirror the resulting domain structure, minimises coordination overhead and as a consequence reduces the demands on scaling frameworks.
Some introductory reads on the concept:
Applying Conway’s Law to Improve Your Software Development
Fausto de la Torre on why Conway’s Law should be front of mind when it comes to structuring teams.
Conway’s Law, DDD, and Microservices
Steve Ardalis on how the design of a system will (or should) influence the organization and vice versa.
‘Form follows function’ has proven to work in our organisation design or realignment projects. In particular when jointly developed with the teams concerned.
Have a great start into the new week,