Would you be able to define your team’s topology and the type of interactions your team has with others?
Recently I’ve read the book Team Topologies (more info about the book and authors in the link) and it defines four fundamental team topologies depending on the goal and purpose of the team. Even though all of them are applied to technical teams, depending on the product or service they provide and to whom they provide, the team will have a shape or another. Here in this article you can find some ideas I gathered from the book.
Four fundamental Team Topologies:
- Stream-aligned teams
- Enabling teams
- Complicated-subsystem teams
- Platform teams
Based on the purpose every team has in the organization and how they communicate and interact with other teams (more on this in Conway’s law), they’ll be classified under one topology or another. To facilitate the understanding of every type, here a quick summary of the team characteristics, capabilities and expected behaviors. Read book’s chapter 5 to get more information and examples.
These are teams aligned to a single, valuable stream of work, e.g: a product, a service, a set of features, a specific user case or persona, etc. Stream-aligned teams are empowered to deliver value as much as possible and as soon as possible. Other teams are created to reduce the burden and complexity these teams encounter to do their job. Stream-aligned teams are close to the customer and user while monitoring their products running in production.
Based on streams within the Company, their nature might be different: customer/user types, business areas, geography, products, user-personas, compliance areas, etc.
Some of their capabilities are application security, commercial and operational viability analysis, design, architecture, infrastructure, development, monitoring, testing, UX, etc.
These teams try to reach a quick response to problems by constantly inspecting and adapting. Regardless the solution they provide, they should maintain their code, making it easy to change with time, paying attention to technical debt.
These teams have a strongly collaborative nature. They represent the servant leadership on a team level, they offer help to stream-aligned teams. Their members are specialists that provide support to the stream-aligned teams to learn how to apply specific aspects to their work, usually around a specific technical, product or service management area.
Enabling teams can be mapped to any of the capabilities of the stream-aligned teams, but these are the most common ones: build engineering, continuous delivery, deployments, automations, etc.
These teams are pioneers of new tools and approaches. Occasionally, they can act as a proxy with external and internal actors if the communication with stream-aligned teams is too complicated.
These are responsible for building and maintaining a part of the system that depends heavily on specialist knowledge. Most of the members are specialists in that area in order to understand and make changes to the subsystem.
The objective of this team is to reduce the cognitive load of stream-aligned teams. They have a strong technical expertise and provide help to other teams. When inspecting the subsystem to take care of it, they collaborate closely with stream-aligned teams.
It is also expected that the delivery speed and quality are higher than when the stream-aligned team was in charge of dealing with the complex subsystem.
The objective of this teams is to enable stream-aligned teams to deliver work with substantial autonomy. However, the stream-aligned teams are still responsible for maintaining, building, running and fixing in production. They don’t support a unique stream-aligned team, they offer a set of APIs, tools, services, knowledge and support which are offered as a compelling internal product for a large number of stream-aligned teams.
The products or services they provide should be reliable, for both internal and external consumers. They treat the platform they build as a product system, applying software development techniques such as define hours of operations, notify downtimes and major issues, define the response time, prioritize new features as requests from stakeholders, define cadence of delivery, etc. This platform provided to stream-aligned teams increases their service levels and reduces their cognitive load.
Platform teams should focus on DevEx (development experience). A good indicator is the necessary time to onboard a new developer into the platform. Users and developers should be able to provide feedback to these teams on a regular basis.
If you’re interested on DevEx, here a talk about how Google uses DevEx principles to facilitate flow.
Based on how teams interact with each other, we can define three interaction modes. Here they are:
Collaboration: when teams have a high level of interaction and mutual respect for each other, they will collaborate and work closely until they finish an expected outcome from that collaboration. Some common relationships are stream-aligned teams with complicated-subsystem teams or platform teams, and complicated-subsystem teams with platform teams.
A team should not be working in collaboration mode with more than one team at the time. That collaboration mode will probably reach the expected outcome after a couple of months or quarters and after that, teams will probably move into another interaction mode if that’s still necessary.
Some good things about collaboration mode are rapid innovation and discovery and fewer hand-offs. However, some bad things are shared and wide responsibility for each team (sometimes boundaries are not clear), more context is needed between teams, possible decrease of output during collaboration and not appropriate for long periods of time.
X-as-a-Service: this interaction mode is used frequently by platform teams providing a Platform-as-a-Service for stream-aligned teams and complicated-subsystem teams. However, complicated-subsystem teams can also provide it for stream-aligned teams and other complicated-subsystem teams.
When interaction is perfectly define at the level of what is expected to provide by another team to a consumer team and interactions are needed on demand, this interaction mode will help to standardize X-as-a-Service keeping in mind the DevEx, since the consumer will be another Dev Team.
Once the X-as-a-Service is being provided, the provider could expect to offer the same service to a larger number of teams, adapting the service or just increasing the list of consumers. But this interaction mode also requires from the team providing the service a compromise on getting to know the necessity from the teams consuming it, as well as good service-management practices (versioning, documentation, availability of service, etc.).
Some good things about this interaction mode are the clarity of ownership with clear responsibilities (who does what) and reduced context between teams. And at the same time, some bad things about this interaction mode are slower innovation of the boundary or API and danger of reduced flow if the boundary or API is not effective.
Facilitation: this interaction mode defines the capability to give and receive help. It happens when all the different team topologies help a stream-aligned team and also specially with an enabling team helps other team, no matter what topology. Because this requires a lot of dedication, a team should expect to use the facilitation interaction mode with a small number of other teams simultaneously, whether consuming or providing the facilitation.
Some good thing about this interaction mode are unblocking of stream-aligned teams to increase their flow and detection of gaps and misaligned capabilities or features in components and platforms. On the other hand, some bad things about facilitation are the necessity of experienced staff to not just work on building and running things and the interaction may be unfamiliar or even strange to one or both teams involve in the facilitation, making it less effective.
As a summary, in the book we can read about the information gathered in this table which shows the normal interaction modes by team topology:
Team Topologies and their Interaction Modes.
Would you be now able to allocate your team and define what interactions has with others? Based on that, there will be some aspects to pay attention and to work on. In this article we’ve covered some expected behaviors.