Org Charts & Architectures
In 1968, Dr. Melvin Conway, told a story in one of his papers, How Do Committees Invent?, about a contract research organization that had eight people on the team. They were asked to produce two compilers, one for COBOL and one for ALGOL. Five people were assigned to the COBOL job and three to the ALGOL job. It shouldn’t be a surprise that the COBOL compiler ran in five phases and the ALGOL compiler ran in three. From this paper came what we now know as Conway’s Law but only because another famous computer scientist, Fred Brooks, coined the term in his book, The Mythical Man Month. Conway’s Law is an adage that organizations design systems that mirror their communication structures.
I’m a fan of this adage and it has received a significant amount of support from research. That organization structure and design/architecture are intrinsically linked, has a few interesting ramifications:
This implies that if you want to change the architecture, you should first change the organization.
Product developed by loosely-coupled organizations is significantly more modular than the product from the tightly-coupled organizations.
The depth of an organization negatively affects design flexibility. The deeper the hierarchy of an organization, the more constrained the resulting architecture.
Team size constrains the architecture. If we want small, less complex, modular systems, we should keep the size of our teams small.
Many, many people have riffed on this concept from Conway putting their particular spin on it. The author of Release It! Michael Nygard stated that, “Team assignments are the first draft of the architecture.” I don’t know how accurate it is but I’ve enjoyed Manu Cornet’s visualization of organizational charts, which plays with this idea that our systems architectures are similar to our organizational structures.
A 2019 book, Team Topologies by Matthew Skelton and Manuel Pais, puts forward a concept that there exists four types of teams: stream-aligned, enabling, complicated-subsystem, and platform - each with a specific role to play in the organization. The roles of each are:
Stream-aligned - focuses on a specific business capability, ideally cross-functional;
Platform - provides common services to other teams;
Complicated-subsystem - high specialization, and specific knowledge
Enabling - a team of experts, mentoring and helping other teams to evolve and improve.
In recent organizational design thinking, the inverse or reverse Conway maneuver has been established. This is the idea of designing our teams to match our desired architecture, instead of letting our organizational structures define our architectures. By leveraging these four team types and the reverse Conway concept, Skelton and Pais believe that we can assist teams in managing cognitive load. They state, “Managing cognitive load through teams with clear responsibilities and boundaries is a distinguished focus of team design...to achieve duly scoped, bounded responsibilities, natural - and relatively independent - system (sub)structure is sought to align teams to...takes Conway’s law into account and leverages it to help maintain cohesive structures with clear boundaries and loose coupling.”
There is no perfect architecture, process, or organization structure as everything has pros and cons. I’m a fan of choosing the right one for the stage of maturity of the company. A startup with five engineers can leverage the benefits of a monolithic architecture, flat organizational structure, and little to no processes. An organization with thousands of engineers needs something different. Skelton and Pais state in their Team Topologies book, “...when designing modern organizations for building and running software systems, the most important thing is not the shape of the organization itself but the decision rules and heuristics used to adapt and change the organization as new challenges arise…”