Team Topologies — A New Way of Thinking About Teams
Organize teams around four fundamental types: stream-aligned, enabling, complicated subsystem, and platform
Foreword
My recent experience with cross-organizational squads in the company, their benefits, challenges and downsides, drove me to dive into the research about team topologies and their manifestation as stated in Conway’s law:
“Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.”
Almost immediately, I found this great book by Matthew Skelton and Manuel Pais: Team Topologies: Organizing Business and Technology Teams for Fast Flow.
In this article, I’d like to summarize some of the key concepts from this book and distill practical advice that can help us to better structure software development teams.
How Teams Deliver Software
As the complexity of the systems increases, it puts more burden on organizations that build and evolve those systems. One of the primary challenges is to build teams that are capable of consistently and effectively delivering value. Taking Conway’s law into account, organizations have to build and maintain cohesive team structures with clear boundaries and loose coupling (known as the reverse Conway maneuver).
The Team Topologies book identifies four team patterns, describing their outcomes, form, and the problems they address, so they can serve us as a pragmatic guide, whether we’re forming new teams or helping existing teams become more effective at responsive value delivery.
We will revise those patterns later in this post.
Communication Structures
Building and running complex software systems is always a team activity, requiring the combined efforts of people with different skills across different platforms. In addition, modern organizations are embracing DevOps practices to rapidly deliver and operate software systems, while adjusting to business requirements or regulatory constraints.
But despite these demands, many of them keep having a single and static view of their teams, which we often refer to as “org charts.” Those charts usually depict the organizational entities, how they relate to each other, and their communication channels, usually in a very hierarchical manner.
In reality, we don’t limit our communication to those who follow the org. charts’ communication lines. We reach out to people we depend on to get work done. We create relationships and build trust, to get work done in a decentralized manner to shorten the lead time.
“A team is not a group of people that work together. A team is a group of people that trust each other.”
— Simon Sinek
That’s why the actual communication flow looks quite different from the org chart.
And if this is the case, teams structures in organizations should facilitate and make this communication to be a part of their DNA. The first step towards this goal is to be aware of the “say-do gap” and try to narrow it as much as possible.
If we want to have independent and self-organizing teams that can collaborate effectively, we need to make sure that our organizational culture, its core values, communication flow, feedback loops, and rewarding mechanisms are in sync with this intent.
Inverse Conway maneuver
In 2015, James Lewis, Technical Director at Thoughtworks, and others came up with the idea of applying an “inverse Conway maneuver” (or reverse Conway maneuver):
“An organization should focus on organizing team structures to match
the architecture they want the system to exhibit rather than expecting teams
to follow a mandated architecture design.”
The key takeaway here is that thinking of software architecture as a standalone concept that can be designed in isolation and then implemented by any group of teams is fundamentally wrong.
We can notice this gap between intended architecture and team structures in almost all types of architectures, even in very modern ones, such as microservices.
Team Cognitive Load
Similarly to individual cognitive load (a limit to absorb and process information), team cognitive load could be treated as a sum of its team
members’ cognitive capacities.
Cognitive load should be taken into account if you want your teams to achieve highly qualitative results and not overload them with an unreasonable amount of tasks and responsibilities.
This is very well-formulated by Daniel Pink’s three elements of intrinsic motivation: autonomy (undermined by bombarding teams with many requests and confusing priorities), mastery (by tackling too many things we eventually compromise on mediocre results), and purpose (unclear direction and responsibilities).
Taking team cognitive load into account is necessary while deciding on team size, assigning responsibilities, and establishing interfaces with
other teams.
Organization Design Requires Technical Expertise
Assuming that Conway’s law is real, we can conclude that the person who makes decisions about the shape and placement of engineering teams is inevitably influencing the software systems architecture.
The corollary of this is that organization and software designs need to be undertaken by the same informed group of people.
One type of such people could be software architects.
Allan Kelly’s view of a software architect’s role underlines this idea:
“More than ever I believe that someone who claims to be an architect needs both technical and social skills, they need to understand people and work within the social framework. They also need a remit that is broader than pure technology — they need to have a say in organizational structures and personnel issues, i.e. they need to be a manager too.”
Essentially, it means that we need to involve technical people in organization design decisions because they understand key software design concepts that could be applied further to the team’s design.
What About Communication?
Is all communication and collaboration good?
When you design a system, you carefully plan who “speaks” with whom and how. The same applies to communication between teams. Therefore it is equally important to define “team interfaces” and set expectations around them.
Many of us assume that more communication is always better, but that’s not always the case. You should have it where you expect to have it, otherwise, it may imply that teams communicate to compensate for the lacking interfaces or well-defined processes.
Another interesting concept to consider while talking about communication is the “Postel’s Law” A.K.A “The Robustness Principle.”
You can read a very interesting article about the universality of this law by Michael Feathers here.
“Team APIs”
Team APIs are well-defined team interactions that are necessary to produce a coherent network of well-communicating teams.
The team API may include:
- Code produced by the team
- Code versioning strategy
- Documentation
- Preferred ways of working
- Communication channels
- Roadmaps and priorities
- Any other information that could be relevant while interacting with the team
Team Topologies
“Team Topologies” book proposes four fundamental team types:
- Stream-aligned
- Platform
- Enabling
- Complicated-subsystem
We will take a closer look at each of them.
Stream-Aligned Teams
A “stream” is the continuous work that is done to fulfill domain or organizational capability. Such flow requires clear focus and responsibility so that it’s aligned to a single vision of what it’s being built.
Ideally, such a team is empowered to build and deliver customer or user value as quickly and efficiently as possible.
The stream-aligned teams are the fundamental organizational teams, and the purpose of the other team type is to reduce the cognitive load from the stream-aligned teams and support their flow for the utmost performance.
Since stream-aligned teams are usually responsible for the end-to-end product or service delivery, they are naturally closer to the end customers and are taking active ownership of the software operational aspects, such as monitoring, issues investigation and fixes, or any other work that should enter the flow of work.
In order to be independent and deliver software end-to-end, stream-aligned teams should incorporate a set of capabilities that may include:
- Product management
- System design and architecture
- Software development
- DevOps
- Testing and automation
- User experience (UI/UX)
Expected behaviors
So, how do we know what an effective stream-aligned team looks like?
“Team Topologies” authors suggest the following characteristics:
- A stream-aligned team aims to produce a steady flow of feature delivery.
- A stream-aligned team is quick to course-correct based on feedback from the latest changes.
- A stream-aligned team uses an experimental approach to product evolution, expecting to constantly learn and adapt.
- A stream-aligned team has minimal (ideally zero) hand-offs of work to other teams.
- A stream-aligned team must have time and space to address “tech debt” to ensure that changing the code remains robust and maintainable.
- Members of a stream-aligned team feel they have achieved or are on the path to achieving “autonomy, mastery, and purpose” — the three key elements of motivation by Daniel Pink.
Enabling Teams
Since stream-aligned teams are taking end-to-end ownership to deliver working software, they don’t have enough capacity to improve their capabilities by learning and practicing new tools and skills.
That’s where enabling teams come into the picture.
An enabling team consists of technical experts and specialists in specific technical or product domains. Such teams have allocated capacity to research new technologies, try out new tools, and make suggestions on relevant practices, frameworks, and any alternatives around the relevant application stack.
That allows the stream-aligned team to acquire and evolve capabilities without having to stop the flow in order to invest an effort into these activities.
Expected behaviors
As we’ve seen above, the mission of enabling teams is to help stream-aligned teams acquire missing capabilities, usually around a specific technical or product management area.
- An enabling team proactively seeks to understand the needs of stream-aligned teams.
- Similar to architecture or innovation teams, an enabling team stays up to date with new approaches, tooling, and practices in their area of expertise, well before an actual need is expected from stream-aligned teams.
- An enabling team promotes learning not only inside the enabling team but across stream-aligned teams, acting as a curator that facilitates appropriate knowledge sharing inside the organization.
Complicated-Subsystem Teams
A complicated-subsystem team is responsible for building and maintaining a part of the system that depends heavily on specialist knowledge, to the extent that most team members must be specialists in that area of knowledge in order to understand and make changes to the subsystem.
The goal of this team is to reduce the cognitive load of stream-aligned teams working on systems that include or use the complicated subsystem. The team handles the subsystem complexity via specific capabilities and expertise that are typically hard to find or grow.
Examples of complicated subsystems might include face-recognition algorithms, machine learning approaches, real-time devices drivers, digital signal processing, or any other expertise-based capability that would be hard to embed directly within the stream-aligned teams.
Expected behaviors
- A complicated-subsystem team is mindful of the current stage of development of the subsystem and acts accordingly, while collaborating with stream-aligned teams to make sure successful subsystem integration.
- With a complicated-subsystem team, delivery speed and quality for the subsystem should be high to justify the separation.
- The complicated-subsystem team correctly prioritizes and delivers upcoming work respecting the needs of the stream-aligned teams that use the complicated subsystem.
Platform Teams
The purpose of a platform team is to enable stream-aligned teams to deliver work autonomously. While the stream-aligned team has full ownership of building, running, and fixing their application in production, the platform team provides internal services to reduce the load that would be required from stream-aligned teams to develop these underlying services.
This definition of “platform” is aligned with Evan Bottcher’s definition of a digital platform:
“A digital platform is a foundation of self-service APIs, tools, services, knowledge and support which are arranged as a compelling internal product. Autonomous delivery teams can make use of the platform to deliver product features at a higher pace, with reduced coordination.”
Peter Neumark, platform engineer at Prezi, stresses the need for alignment of purpose between the platform team and the stream-aligned teams they support: “A platform team’s value can be measured by the value of the services they provide to product teams.”
Expected behaviors
- A platform team uses strong collaboration with stream-aligned teams to understand their needs.
- A platform team relies on fast prototyping techniques and involves stream-aligned team members for fast feedback on what works and what does not.
- A platform team has a strong focus on usability and reliability for their services and regularly assesses if the services are still fit for purpose and usable.
A good platform should provide standards, templates, APIs, and well-proven best practices for dev teams to use to deliver their software rapidly and effectively.
Summary
One of the biggest challenges of many organizations is to establish teams that are capable of sustainable software delivery. Often it stems from unclear responsibilities and boundaries.
To avoid this problem, Team Topologies” suggests organizing teams around four fundamental types: stream-aligned, enabling, complicated subsystem, and platform. This may help to create teams and their interactions that promote flow at both personal and organizational levels.
This is just a small excerpt of what this great book has to offer, which in my opinion is well-paced, interesting, and provides really profound insights about organizational dynamics and software development in general.
