You're reading for free via Ryan Dawson's Friend Link. Become a member to access the best of Medium.
Member-only story
Your Team Structures Ain’t Working. Let’s Apply Team Topologies
Structuring teams is always tricky. Let’s do it right
We want to understand why team structures matter and how to use them most effectively within the bigger picture of software delivery. The book Team Topologies: Organizing Business and Technology Teams for Fast Flow by Matthew Skelton and Manuel Pais explains exactly this. Let’s go over its key insights and how we can apply them.
Team structures can be a divisive issue. There have been some big controversies over team types. We’ll look at these first and then we’ll see how Team Topologies can move us beyond arguing about the best team types. Instead, it gives us tools to evaluate and adapt team structures to our situation.
Background: Controversies Over Teams
Let’s understand a couple of the biggest controversies around team structures. We can then return to these later, once we know more about the Team Topologies approach.
Controversy 1: Component teams vs. Feature teams
The classic examples of component teams are a ‘frontend team’ or ‘backend team’ or ‘database team’. These are teams identified by a technology area. Feature teams develop whole areas of functionality within a system, such as the part responsible for bookings or for new customer registration.
We can see feature teams as taking a vertical slice of skills. This means that feature teams often need frontend, backend, and any other skills. A component team is seen as slicing horizontally, so contain skills just for one specialisation, e.g., just frontend.
Usually, component teams get criticised as not aligned for direct customer feedback or aligned to customer value. Not being aligned for feedback is not great for agile. But can we simply do away with all component teams? We’ll return to this controversy later.
Controversy 2: A dedicated DevOps team?
Given the feature vs. component debate, it’s not surprising that the idea of a dedicated DevOps team gets criticised — it’s clearly not a feature team. It risks being a silo in which all DevOps knowledge is kept and not shared with other teams. But does that mean we should never have a DevOps team?
Analysing the controversies
These two controversies sound pretty one-sided. Many might conclude that feature teams are simply the way to go. But there’s a lot more nuance around this topic. Let’s start with DevOps.
How Does DevOps Fit Into Teams?
The work that led to Team Topologies started with the DevOps Topologies website. There the DevOps team as a silo anti-pattern is shown as follows:
DevOps Topologies suggests that the pattern should only be used as a transition when there are existing silos between Dev and Ops (with Ops being responsible for infrastructure). A DevOps team sitting between Dev and Ops might then last 12–18 months. This is a positive variation on the anti-pattern that flips it into a pattern as shown:
Another positive variation is a DevOps advocacy team. This would have an on-going remit of facilitating collaboration between Dev and Ops. This is a positive pattern because it continues to empower and lead to better practices.
A more sophisticated variation is the Site Reliability Engineering (SRE) model pioneered by Google:
In the SRE model, it is the SRE team that supports the software in production. But unlike Dev vs. Ops anti-patterns, Dev cannot chuck software over the wall. The SRE team has standards that the software needs to meet and can reject software that it isn’t happy with. There are also variations of SRE where the SRE team acts like performance and reliability evangelists.
This gives us a flavour of the Team Topologies approach. It’s not a question of intrinsically good or bad structures. It’s about the patterns of behaviour and collaboration encouraged by the structures.
Team Topologies Applied To Dev Teams: Challenges of Scale
We’ve now seen from looking at some DevOps patterns that not every team has to be a feature team. That frees us to think further about how to structure Dev teams for scale.
It is well understood that microservices can provide structure and boundaries for teams. As software gets bigger then we have to divide it up.
“The most fundamental problem in software development is complexity. There is only one basic way of dealing with complexity: divide and conquer.” — Bjarne Stroustrup
We have to divide software up as programmers so that we can focus on one part at a time. Team Topologies scales this idea up to teams and talks about the ‘cognitive load’ of a team. Giving a team a natural area of responsibility allows the team to focus and deepen the knowledge and skills needed to advance that specific area.
We don’t want a team’s remit to become so big that the team is always playing catchup and unable to work creatively. Team Topologies suggests identifying this by asking the team a simple question — “Do you feel like you’re effective and able to respond in a timely fashion to the work you are asked to do?” They even provide a template survey.
The remit of teams should be limited, and so should the size of individual teams. It’s worth appreciating why this is. Limiting of remits is about cognitive load. But the reasons for limiting the size of teams are less obvious.
As teams get bigger it becomes unwieldy for everyone to communicate with everyone. This aspect is quite tangible. Anyone who has tried to do a standup meeting with a team that is too big will have experienced this — it will take too long and attentions wander. Size also leads to more risk of miscommunication with X reporting what Y said to Z.
The more important reason for limiting team size though is trust relationships. Teams need to have a relationship of trust in order to challenge each other and debate ideas openly. Otherwise, people hold back for fear that suggestions might be taken personally. It takes time to build trust, which is hard to achieve with large groups. Think about how many people it takes before you start to forget names, what everyone is interested in, their personal aims, strengths, weaknesses, and senses of humour.
The upshot is that we can only maintain the strongest relationships with a small number of people. From there, relationships get weaker. This has been studied by Robin Dunbar, and his work suggests a team size of 5–15 for close trust (similar to Amazon’s famous ‘two-pizza rule’) with radiating levels from there:
This doesn’t mean that teams all need to be completely independent of one another. There can be interlocking levels with teams within groups/departments/tribes. The point is that for an individual team to be most effective it should have a focused remit that doesn’t require more than 15 people. It’s about how we divide up work.
So there are people-centric reasons for dividing up software into small enough pieces — microservices. We might also have other reasons for wanting microservices, such as scalability, resilience, or being able to release parts independently.
If we want microservices, then it makes sense to assign teams to particular microservices — either individual services or related groups. Otherwise what can happen is that supposedly independent services looked after by the same team start to blur into one another. Their APIs get vague, or they start sharing data or config by the back door. (This is a manifestation of Conway’s Law, that organisational structure will drive the structure of software produced.)
So, we want teams with clear and logical remits. The question then is: how to achieve this? How do we divide up the software to suit an optimal flow of work for teams?
Team Boundaries and Splitting Monoliths: Fracture Planes
Team Topologies suggests a variety of angles for looking at how to divide up a system. It suggests looking for natural lines of division — ‘fracture planes’ — and choosing the ones that feel most appropriate. The angles it suggests to look at are:
- Business Domain Bounded Context. This means identifying business domain areas. Domain-driven design techniques can help with this.
- Regulatory compliance. Sometimes regulatory needs affect parts of a system and mean that they sit logically apart (e.g., parts dealing with payments or personal data).
- Change cadence. Parts of the system might get released more or less often than others. This can be an indicator of a fracture plane.
- Team location. If a team can all talk to each other in person, then this can make a difference.
- Risk. Parts of a system might be much more or less risk-tolerant (e.g., depending on how many users they have or financial value of transactions).
- Performance levels. Sometimes parts of a system have much more demanding scaling or throughput requirements.
- Technology. Differences in tech can be important for cognitive load. You’ll want to be wary of requiring a single team to work with too many kinds of tech.
- User personas. Consider, for example, admin users vs. new users. Or users of paid add-on features on top of an otherwise free-to-use product.
The key point is that the team structure both affects the software being delivered and needs to reflect the software we want to be delivered. We want teams to be empowered and that means structuring teams around software — not reporting lines or an age-old org chart.
So this gives us some pointers on how we can divide up the system into areas. But what kinds of teams should be looking after these areas?
What Types of Teams?
Team Topologies offers a set of patterns for team types and how teams can interact. These are templates for the types of teams that might be assigned to parts of a system. The guiding principle is to have teams delivering business value and to use other structures to support those teams. Interdependencies should be minimised, but it is recognised that deep interaction can be valuable when in an experimental phase.
Patterns for Team Types and Interaction
The book proposes four fundamental team types and three collaboration patterns. These can be used as templates for how to understand and design teams.
Let’s understand each of these elements and explore how they can be applied.
Team Types
Stream-aligned teams
A stream-aligned team is aligned to a single stream of work. This could be a feature, a product or service, a user persona, or any other stream of work delivering direct business value.
Stream-aligned teams should be the primary team type in the organisation. The other team types are meant to provide services, tools, and support to maximise the flow of stream-aligned teams.
Platform teams
The mission of platform teams is to reduce the cognitive load of stream-aligned teams by providing lower-level detailed knowledge, packaged as services. Think, for example, of services such as provisioning, monitoring, or deployment. The platform team packages these services up to make them easy to consume via self-service APIs.
With platforms, it’s key that the consuming team’s needs are met. There’s a risk of the platform growing and coming to dictate to the consuming team what they can and can’t do. The authors talk about aiming for a ‘thinnest viable platform’ to serve the purpose of enablement.
Complicated-subsystem teams
A complicated-subsystem team works on a part of the system that requires a lot of specialist knowledge. Having such teams reduces the cognitive load of stream-aligned teams. The need for complicated-subsystem teams is a recognition that some parts of systems are complex enough that you need a team of specialists to do it justice. Examples could be subsystems that are heavily mathematical or involve complex algorithms.
Enabling teams
Stream-aligned teams are always trying to do new things and keep moving with the business needs while keeping up with industry trends. Enabling teams are composed of specialists in a particular domain (e.g., a technology area) and provide capabilities that supplement the stream-aligned teams.
Enabling teams are well-positioned to do research, try out possibilities, and advise on tooling or practices. The idea is that the enabling team empowers the stream-aligned teams with the aim that eventually the help will no longer be needed (at least not the same help).
Interaction Modes
Collaboration
Collaboration is good for rapid discovery. It involves a lot of interaction between the teams concerned. This allows for the bouncing of ideas and innovation. It tends to mean blurred boundaries between the interacting teams, but this can be a good thing if it helps the teams to experiment and hit on an optimal approach. This short-term blurring of boundaries leads to clarity later.
X-as-a-service
This is suited to where one team is providing a library, component, or API that another team consumes. The service provided should simply work without a lot of input needed from the team. If a lot of input is needed to define what the service should do, then a collaboration mode might be temporarily used.
Facilitating
This is the main operating mode of an enabling team. We can think of this as ‘coaching’ or providing similar skills-based or advice-based services.
Controversies Revisited
In the light of what we’ve learned, the component teams vs. feature teams debate looks simplistic. Of course, simply forming teams based on frontend or backend specialisations is to be avoided where possible. But it’s OK if teams are occasionally composed of specialists where necessary (e.g., complicated-subsystem teams). It’s also OK that teams might be serving other teams rather than serving customers directly (e.g., platform teams).
We’ve now got more refined concepts to apply than ‘feature’ and ‘component’ teams. We can now talk instead compare the teams that we see in the real-world to the patterns of stream-aligned, enabling, complicated-subsystem, and platform teams.
We’ve also learned that there’s a range of patterns around DevOps and teams. DevOps skills might be embedded within a team, or there might be an enabling DevOps team or the SRE model might be used.
The key is that we evaluate whether a team structure is working well. In particular, we can look at:
- Cognitive load of the team members.
- Whether the fracture plane sits right.
- Are the boundaries clear to the team and to other teams?
- Is there friction between teams?
- Are we seeing lots of delays through handoffs between teams?
- Communication overheads and team size.
- Team members and skills and whether the team is empowered to achieve its goals.
We don’t need to argue about which team types are best. We can evaluate how well our structures are working for our teams and compare them against well-known patterns.
Applying Team Topologies
The techniques we have talked about are not meant to be applied rigidly. We don’t need to rip up existing teams because we don’t immediately see how they fit a type.
“Team Topologies is meant to provide clear patterns that are straightforward for many different teams and organisations to follow and interpret, not to dictate to outstanding players how to perform” — Team Topologies
Flexibility is also key to the approach in that team structures are meant to evolve over time.
“Organizations not only need to strive for autonomous teams, they also need to continuously think about and evolve themselves in order to deliver value quickly to customers” — Team Topologies
The book talks about a “discover to establish” progression. We should expect to see teams need to collaborate closely for an initial period in order to better define boundaries (APIs, handoffs, etc.). This collaboration will then reduce over time and morph into a well-defined boundary fitting the X-as-a-Service interaction mode.
Software also changes as businesses change. Areas that at one point were going through a lot of evolution might later go into maintenance mode. Business circumstances can also lead to wanting to evolve areas that had been in maintenance mode, and this business change will happen against the backdrop of changes in the technology landscape as new tools keep coming out.
Rather than thinking of team structures as fixed, we can think of the direction of the organization and how the team structures fit into that. If an organization is trying to do something new, it helps to recognise that. This allows us to be more conscious about requiring a period of innovation and collaboration. We want to optimise for autonomy and fast flow but we should be mindful of when that comes at a cost to innovation.
Team Topologies gives us such an impressive perspective it is worth reminding ourselves that team structures are not the whole picture of teamwork. Friction between teams might not be a structural problem — it might be a silo problem. Dysfunction within a team can originate from interactions with other teams or it can originate within the team.
Skelton and Pais focus on the team structure aspect of teamwork and do so very well. The book offers a perspective and a set of tools for designing, analysing, and adapting team structures. It’s a good read and is rich in nuance and examples that I’ve not been able to cover here. It was published at the end of 2019 and its influence is growing. Expect to hear a lot more about the book and its approach in the future.
