5 Keys to Successfully Implement Team Topologies in Your Organization

Effective software teams are essential for any organization to deliver value continuously and sustainably. But this effectiveness is, oftentimes, hard to attain. 

In their book “Team Topologies”, Matthew Skelton and Manuel Pais present a “practical, step-by-step adaptive model for organization design and team interaction, where team structures and communication pathways are able to evolve together with technological and organizational maturity.”

The model is based on four fundamental team types and three team interaction patterns, that we will analyze below. The result of successfully implementing Team Topologies is a step in the direction of a clearer and more sustainable software structure.

Team Topologies proposes an organizational design encompassing four teams. This separation is guided by the principle of having teams that deliver business value, and other structures to support those teams. 

Dependencies between teams do exist, especially in an experimental phase, but should be minimized. Also, keep in mind that these team types can take up different forms depending on the size and maturity of the company. 

Four Types of Teams

The team types defined by Team Topologies are: stream-aligned, enabling, complicated subsystem, and platform.

Stream-aligned Team

According to Team Topologies, a stream-aligned team is “aligned to a flow of work from (usually) a segment of the business domain.” Because these teams focus on a single stream of work, they can deliver value as quickly, safely, and independently as possible. By nature, they are very close to the customer and usually adopt agile methodologies. 

Responsibilities of stream-aligned teams include knowing the customer and responding to their needs, developing a steady flow of new features, applying Design Thinking, applying improvement practices, and supporting the solution in production.

Enabling Team

Enabling teams “help a Stream-aligned team to overcome obstacles. They also detect missing capabilities.”

They focus on research and experimentation which, in turn, enables them to act as informed advisors in regards to tooling, frameworks, and ecosystem choices to other teams.

Enabling teams have as their responsibilities innovating, collaborating proactively, communicating regularly, and promoting a continuous learning culture.

Complicated Subsystem Team

A complicated-subsystem team is “where significant mathematics/calculation/technical expertise is needed.” This team is responsible for building and maintaining a part of the system that requires specific skills and knowledge. By focusing on this, it alleviates the workload of stream-aligned teams who work on systems that depend on that complicated subsystem.

Complicated subsystem teams’ responsibilities comprise building, maintaining, and supporting the complicated subsystem, maintaining their level of expertise, planning and prioritizing effectively, developing appropriate interfaces, and taking account for built-in quality.

Platform Team

“A grouping of other team types that provide a compelling internal product to accelerate delivery by Stream-aligned teams,” such is Team Topologies’ definition of Platform teams.

Their main goal is to enable Stream-aligned teams to deliver work with considerable autonomy. On the other hand, they contribute to a better end-user experience, making it cohesive across different segments or products.

Platform teams usually have as their responsibilities collaborating with Stream-aligned teams, building the platform incrementally, focusing on usability, and working on support and maintenance.

Three Types of Team Interactions

Besides defining the four types of Team Topologies, Skelton and Pais also define how the interaction between teams should take place. They identified three types of team interaction modes:

• Collaboration
• X-as-a-Service
• Facilitating

Collaboration

Team Topologies sees collaboration as “working together for a defined period of time to discover new things (APIs, practices, technologies, etc.).” Collaboration is about teams uniting efforts and closely working on the same or related tasks. 

This is especially fruitful for rapid discovery since it allows a great deal of interaction between teams, which generates more ideas and facilitates innovation. Since it often leads to a blur on the boundaries between teams, it tends to pay off in the end, providing more clarity for every team involved.

X-as-a-Service

“One team provides and one team consumes something as a Service,” clarifies Team Topologies. Unlike Collaboration, this type of interaction requires little cooperation between teams. The service should be provided without a lot of input from the providing team. If this is not the case, the teams should consider a Collaboration mode instead.

Facilitating

Facilitating happens when “one team helps and mentors another team.” It’s about teams dealing with obstacles and helping others to overcome them. It mostly applies to Enabling teams, and it is like providing coaching or advice-based services.

Integrating Team Topologies into your organization’s DevOps structure can help you achieve a number of goals in regards to agility, speed, stability, or quality of the product delivered.

In today’s high-speed world of software delivery, having a static team structure compromises the success of your company and the satisfaction of your customers. Traditional organizational designs have functional silos that hinder a fast flow of change, and modern software architecture needs to take into consideration not only the software design but also the shape of the organization.

Team structure can become especially problematic when we are talking about large teams which, by nature, are much more complex and hard to manage.

“The most fundamental problem in software development is complexity. There is only one basic way of dealing with complexity: divide and conquer.” — Bjarne Stroustrup

Team Topologies can help address these scaling challenges, following the same ideology that we have seen until now, based on the premise of team separation. In Agile at Scale, the four types of teams would still apply:

• Stream-aligned teams: at scale, they should function just like we have seen above.
• Enabling teams: they can work as well in scale as not in scale.
• Complicated subsystem teams: large systems often include extensive subsystems. This way, the separation can still be applied, keeping in mind the goal of reducing the cognitive workload of teams.
• Platform teams: they can still provide services that the stream-aligned teams extend and build on.

If you want to transition to Team Topologies and are unsure of where to start, you can follow the path described below, created by Matthew Skelton and Manuel Pais.

1. Identify the teams you currently have and fit them into Team Topologies 

The starting point towards implementing Team Topologies is the same as in any other change you aim at applying in your organization: assessing your current status. Only then can you have a good overview of how your teams are organized. After, you start studying how you can restructure them to fit the organizational structure described by Team Topologies.

As mentioned above, there are four types of teams: stream-aligned, enabling, complicated subsystem, and platform. This step requires you to map your current teams to these four types and reorganize the work and interactions between them.

To assist you with dividing up your system, Team Topologies recommends some natural lines of division, or “fracture planes.” You don’t need to use them all but rather select the ones you feel are most appropriate. The fracture planes are:

• Business domain bounded context
• Regulatory compliance
• Change cadence
• Team location
• Risk performance isolation
• Technology
• User personas

2. Restrict cognitive workload for each team

Team Topologies’ structure allows to reduce the cognitive workload for each team, as this will make them all more effective and lead to a better result and quality of delivery. 

In order to implement this, foster a culture of trust between teams, just so they can rely on each other to deliver what they’re supposed to, and render all the other teams’ work more effective. Assign a specific area to each team and provide an underlying platform for the team to build upon. Lastly, consider breaking apart monoliths, which will facilitate the division of cognitive focus.

3. Use the reverse Conway Maneuver

Conway’s Law states that “organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations”. A way to circumvent this is to use the reverse Conway Maneuver, that is, evolving your team and organizational structure to promote your desired architecture.

4. Identify team interaction modes you currently have and fit them into Team Topologies

As mentioned in point 1, you have rearranged your teams. Now it’s time to think about their interaction patterns and also fit them into the ones described by Team Topologies authors. As mentioned above, these modes are Collaboration, X-as-a-Service, and Facilitating.

5. Evolve team structures overtime

You shouldn’t expect to transform your organization with Team Topologies and never have a look at it again. This is an ongoing process that requires constant monitoring and readjusting. Work to continuously improve your structures, especially when you adopt new technology that might impact the workflows you already have in place.

Team Topologies is not a magical solution to solve every organization’s problems. It does come with a set of challenges, namely: how to share expertise between stream-aligned teams, how to structure the platform team avoiding it turning into another silo, and how to ensure security, to name a few.

However, all these challenges can be overcome. Remember to thoroughly study the subject before starting an organizational change of this magnitude, and to always keep an open and flowing communication within your teams. 

Implementing Team Topologies is possible and can bring immense benefits to your organization, your staff, and your customers. And remember, if you’re overwhelmed and need a hand, we are here to help.

Søren Pedersen

Co-founder of Buildingbettersoftware and Agile Leadership Coach