Tech companies have to work in a constant state of action to stay competitive and quickly meet the market demands. They must rapidly build and update high-complex, interconnected software systems, necessitating robust team collaboration among individuals with diverse skills. In other words, for a tech company, the easier it is to manage its software systems, the higher its productivity and earnings will be. However, what are the most influential factors to improve the company's productivity?
Conway's Law
In 1968, the computer scientist Mel Conway defined Conway's law: "Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure." [1]. It suggests significant benefits from designing software architecture and team interactions together, as they are akin forces. Nevertheless, the communication paths in the organization will end up dictating the software architecture. Indeed, The modern version of Conway's Law by Ruth Malan states: "If the architecture of the system and the architecture of the organization are at odds, the architecture of the organization wins.".
Since Conway law is a recognized phenomenon, a company can respond in three different ways:
- Ignoring it: the architecture of an organization wins over the software architecture is a very likely event: "If you have four groups working on a compiler, you'll get a 4-pass compiler"[2].
- Accepting it: recognizing Conway's law importance means understanding the importance of interconnections and communications among teams. Improving these relations implies producing high-quality software.
- Using the Reverse Conway Manauer: design firstly the software architecture, secondly adapt the team's organization for the software [3, 4]. This approach is particularly successful in limited cases like in microservices system framework.
Team first-thinking
Teams are the most effective means of software delivery. Indeed, Dricksen and Salas found that teams working as a cohesive unit perform far better than collections of individuals [5]. For this reason, an organization must follow the Team First-Thinking that highlights the importance of teams over individuals. Then, the team must be considered the smallest delivery entity within the organization, with its goals, mission, and reasonable autonomy. Teams can be fundamental to increase the clarity of purpose and facilitate the determination of software boundaries using their cognitive load.
Team Topologies
After understanding the importance of communications and teams in an organization, the book presents a digital operating model called Team Topologies [6]. The authors use this term to identify four types of teams and three interaction modes among these teams.
The four topology teams are:
- Stream-aligned: a team aligned to a single, valuable workflow. The team is empowered to build and deliver customer or user value as quickly, safely, and independently as possible. In a modern software organization, we expect most teams to be stream-aligned. They can be a micro-enterprise within a large firm. The mission of the stream-aligned is to ensure the smooth flow of work for a business domain area.
- Enabling Teams: a team composed of specialists in a given technical (or product) domain. Since stream-aligned are under constant pressure to deliver and respond the enabling teams must help bridge the capability gap. So, the goal of enabling teams is to increase the autonomy of stream-aligned teams by growing their capabilities with a focus on their first problem. They also promote learning across stream-aligned teams.
- Complicated-Subsystem Teams: a team responsible for building and maintaining a part of the system that depends heavily on specialist knowledge. The main goal is to reduce the cognitive load of stream-aligned teams working on systems that include or use the complicated subsystem. Note that the complicated-subsystem is created only when a subsystem needs especially specialized knowledge. The decision is driven by the team's cognitive load, not by a perceived opportunity to share the component.
- Platform Teams: a team that provides internal services to reduce the cognitive load that could be required from the stream-aligned teams to develop these underlying services. In particular, they support stream-aligned teams in delivery.
Meanwhile, the interaction modes are:
- Collaboration: working closely together with another team. In particular, during the discovery of new technology or approaches.
- X-as-a-Service: consuming or providing something with minimal collaboration(such as API or tool).
- Facilitating: helping(or being helped by) another team to clear impediments(i.e. learning or adopting new approach).
The following table provides how different teams can expect to interact with other teams
| Collaboration | X-as-a-Service | Facilitating | |
|---|---|---|---|
| Stream-aligned | Typical | Typical | Occasional |
| Enabling | Occasional | None | Typical |
| Complicated-subsystem | Occasional | Typical | None |
| Platform | Occasional | Typical | None |
Conclusion
Team Topologies is a very interesting reading where everyone can improve their knowledge about business organization, combining three simple elements:
- Beware the existence of Conway's law
- Beware the team first-thinking
- Apply the team topologies model to define boundaries between teams and their interactions.
Following these guidelines, companies can rapidly deliver efficient software, reducing loss and maximizing earnings.
In conclusion, I appreciate the authors support their thesis with an extensive bibliography where each statement is substantiated by appropriate reference. Furthermore, numerous real-world use cases are included, presenting examples from well-known companies like Amazon, Google, IBM, Adidas, and Spotify.
The writing style is accessible but sometimes tends to be overly repetitive, for my liking, but the beautiful diagrams in the book aid in quickly understanding the concepts.
I highly recommend this book to tech professionals unfamiliar with business models, encouraging them to read this book.
References
[1]: M. Conway. "How Do Committees Invent?", Datamation, 1968.
[2]: E. Raymond. The New Hacker's Dictionary, 1996.
[3]: J. LeRoy, M. Simons. "Dealing with creaky legacy platforms", 2010.
[4]: N. Forsgren, J. Humble, G. Kim. "Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations", 2018.
[5]: J. Driskell, E. Salas. Collective Behavior and Team Performance, Collective Behavior and Team Performance, 1992.
[6]: M. Pais and M. Skelton. Team Topologies, 2019.
[7]: M. Flower. Conway's Law and Team Topologies articles in Martin Flower's Blog.
Further related readings
- Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations, 2018.
- Data Mesh: Delivering Data-Driven Value at Scale by Zhamak Dehghani, 2022.
- Data Management at Scale: Modern Data Architecture with Data Mesh and Data Fabric by Piethein Strengholt, 2023.