Conway’s Law states, “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.” Many of us find this to be true from personal experience, and so do various scientific publications.
If we support this law, it’s logical also to address organizational communication structures when we want to make changes to a system. Indeed, this approach has gained interest, particularly since Jonny LeRoy and Matt Simons coined the approach of (re-)architecting systems through the deliberate modelling of communication paths in the "Inverse Conway Maneuver."
So why have most organizations today not yet adopted this strategy? With the adoption of Agile in the early 2000s, there are organizational restrictions and resistance that pose barriers to implementing changes of this magnitude. To overcome these barriers, it helps to have a clear set of methodologies that help identify, describe, and organize these communication patterns and how they should change over time.
Organizations must design teams intentionally by asking these questions: Given our skills, constraints, cultural and engineering maturity, desired software architecture, and business goals, which team topology will help us deliver results faster and safer?
Mel Conway, Toward Simplifying Application Development
Modelling cross-functional teams with the Team Topologies approach
Team Topologies, an approach to modern software delivery, proposes a simple set of team types and communication modes that enables a very intuitive yet powerful way of modelling cross-functional teams and their interactions around product-centric value streams optimized for flow.
The four fundamental topologies
- Stream-aligned: aligned to a flow of work from a segment of the business domain
- Enabling team: helps a Stream-aligned team overcome obstacles and detects missing capabilities
- Complicated Subsystem team: where significant mathematics/calculation/technical expertise is needed
- Platform team: a grouping of other team types that provide a compelling internal product to accelerate delivery by Stream-aligned teams
The three team interaction modes
- Collaboration: working together for a defined period of time to discover new things (APIs, practices, technologies, etc.)
- X-as-a-Service: one team provides and one team consumes something “as a Service”
- Facilitation: one team helps and mentors another team
Source: Team Topologies
While the team topologies build on lean Agile and DevOps principles, the community has iteratively improved over the last two decades. The variation of team interaction modes is discussed less frequently in the context of a team's purpose, yet these modes are important signals to set explicit expectations both externally and internally.
Interaction modes in the context of organizational transformation
Interaction modes are also particularly interesting in the context of organizational transformation because these modes can and should change over time, resulting in autonomous, decoupled, stream-aligned teams with a clear purpose.
You might start an organizational transformation by bringing together a highly skilled enabling team to coach (Facilitation) a stream-aligned team in a new methodology or technology. After some time, facilitation is reduced and eventually ceased.
At Rangle, we frequently use an “Architectural Runway” by which a small Enabling Team (e.g. a solution architect or software developer) uses the Facilitation interaction mode with another Rangle or client team for a few sprints to get their initial architecture and integrations set up so the team can reach cruising speed much quicker than when they would have to stem this by themselves.
Another example is a Platform team that builds and later maintains a Design System. Initially, the team would use the Collaboration interaction mode with one or multiple Stream-aligned teams to find the right abstractions and patterns (e.g. the token structure or what atoms and molecules to build).
After several sprints, when the Design System’s shape is established and the first well-documented components are released, the team's Interaction mode shifts to X-as-a-Service. In this case, teams can then self-serve their consumption of the Design System and thereby reducing the communication overhead for the Platform team so it can serve more teams.
"Team collaboration is important for gray areas of development, where discovery and expertise is need to make progress. But in areas where execution prevails—not discovery—communication becomes an unnecessary overhead."
Matthew Skelton and Manuel Pais, Team Topologies
Setting explicit role and communication expectations also helps teams' productivity by defining their team “API” – reducing their cognitive load and reducing communication overhead as teams should be designed to be self-sufficient, mostly leveraging self-service (X-as-a-Service) internal productized solutions for commonly shared utilities, such as provisioning compute resources, logging, localization, or Design Systems.
The potential of leveraging Conway's Law for organizational transformations
Leveraging Conway's Law to architect software via team types and interaction patterns has great potential for organizational transformations, optimizing throughput as well as teams’ satisfaction and retention. Seeding changes via Team Topologies is, of course, only a first step and as with any architecture. It must be measured, observed, and adjusted iteratively over time to adapt to new environmental changes and organizational goals.
If you want to learn more or need help meeting your organizational transformation goals, reach out to us for a conversation and assessment of your unique digital context. We’re happy to support you in an advisory or delivery capacity.