Team Topologies is a relatively new concept, but it quickly caught the attention of managers responsible for software development and DevOps.
Concerned with how DevOps teams are organized in technology companies, Matthew Skelton and Manuel Pais wrote the book “Team Topologies”, considered the cornerstone of a new, evolutionary way to deliver faster and more efficiently.
The work was well received, and the solutions the authors propose have been successfully implemented at companies of all sizes. That's why in this post we'll dive into the Team Topologies concept to help managers at Brazilian companies who want to make their DevOps teams more effective.
You can also check out our video series on Team Topologies on Elven's YouTube channel:
What is Team Topologies?
Team Topologies is the term authors Matthew Skelton and Manuel Pais used to describe how “team topologies” should be organized to improve communication and, as a result, achieve more agility and better outcomes in software development and delivery.
What the authors observed in their experience is that a disorganized structure in the teams responsible for each area of solution development has become a very common problem.
In general, what you see in software development and DevOps teams is a split between highly skilled people drowning in complex problems and less experienced people handling simpler, more routine problems.
Many companies, for example, ask someone responsible for a platform's enabling capabilities to drop what they're working on to fix an urgent problem in another area.
So the authors realized that stable team structures are better able to deliver software with the expected success, and that work could perform better if organized around a logic that favors autonomy, automation and self-service. This makes it possible to better balance people's initiative without giving up governance of the work.
To support development and DevOps teams, then, you would need to split teams according to their responsibilities and intended focus. In addition, within a team that owns a broader product, smaller teams should be formed to tackle specific problems.
These teams focused on “specific problems” can work on areas such as:
- Security
- E-commerce sales channel
- Incident management;
- Mobile experience
- Cross-device integration
- Feature updates
Why adopt Team Topologies as an approach?
By making the changes needed to organize the team more efficiently, companies gain a number of advantages.
For example, one of the main problems for technology companies that build software and digital platforms is meeting the deadlines for deliveries and updates requested by customers.
So the principle of splitting teams according to their capacity to handle more or less complex tasks, combined with greater team autonomy, creates the ideal environment for productivity, in a context where responsiveness needs to be as high as possible.
First, there is the perception that the teams that evolve fastest are the ones with the most autonomy, because they can experiment, test and validate their hypotheses with data much faster than when they need approval for every step of the process.
That way, by organizing teams as Team Topologies suggests, people gain the freedom to follow customer interactions and understand what customers expect, and then make the suggested adaptations faster and more effectively.
What should the basic Team Topologies organization look like?
To achieve modern, optimized delivery that runs on a faster flow of work, Matthew Skelton and Manuel Pais propose four fundamental team types, which we explain below!
Stream-aligned Team
The Stream-aligned Team should be a cross-functional team focused on a business value stream — a customer journey or internal operation to be optimized. This team owns a core domain and the end-to-end execution of the services a piece of software provides.
With a Stream-aligned Team, instead of work being handed off between development, testing, transition and release teams, a single team is responsible for the entire flow.
Basically, the goal is to have a team fully dedicated to understanding customers' problems and shipping improvements quickly. That way, it can gather feedback fast and keep improving the product from the customer's perspective.
Enabling Team
The Enabling Team is, ideally, a temporary team that helps another team acquire knowledge and gain the maturity and skills needed to handle specific scenarios.
It's common for large companies to hire or form an enabling team in very different scenarios, such as running audits, pursuing ISO 27000 certification or adopting a new technology.
Complicated Subsystem Team
The Complicated Subsystem Team is an optional team that brings together the best specialists to handle the most complicated tasks.
The goal of having a team of specialists for the hardest tasks is to make sure the delivery is as good as possible and to keep the Stream-aligned Team from stalling while the problem is being dealt with.
Platform Team
Finally, the Platform Team is the group responsible for keeping all the engineering that supports the other teams running smoothly. This team ensures the Stream-aligned Team has the resources and autonomy it needs to deliver its work.
In other words, the Platform Team builds and maintains the capabilities that let the other teams work smoothly and with minimal overhead. Its focus is optimizing the processes and systems used internally.
To wrap up, the Stream-aligned Team is the essential team for getting work done, because it focuses on the business value stream and customer success.
However, the other teams that make up Team Topologies are what make the Stream-aligned Team's work focused, productive and effective.
Implementing the Team Topologies structure is a key step toward making DevOps team delivery more efficient. But to understand how the changes are affecting the work, you need to track progress with DevOps-specific metrics.
So go ahead and check out our content on DORA metrics for DevOps!
Where observability fits in
Team Topologies organizes who does what. Observability ensures all those teams see the same operation: without a shared map of metrics, logs and traces, each squad interprets the incident from the slice it can see — and the platform team becomes a diagnostic bottleneck instead of an enabler.
Want to give all your teams the same view of the operation? Talk to the Elven team.
