Start organizing your teams the right way with our summary of Team Topologies by Manuel Pais and Matthew Skelton.
Admit it or not, technologies have penetrated every walk of our life. There is something mysterious about it: an educated person living in the 19th century was able to explain, for example, how a gas lamp produced light, how a telescope was constructed, while today the majority have no idea how exactly things like Google Maps and taxi services apps work – even though it’s not something unusual. However, one thing remains unchanged – all software systems providing this new level of life are built and run by people. And to work effectively, people need to be properly organized.
In their book “Team Topologies: Organizing Business and Technology Teams for Fast Flow”, Matthew Skelton and Manuel Pais provide a special approach that helps optimize team structure, helping make the delivery and operations of software systems much more effective. The main idea behind this approach is that a “team” is more than a group of people – it’s a whole living organism that must evolve and be supported in the process of its evolution. The authors highlight that teams must be autonomous, but not isolated: team members need to interact within their groups, but clearly know when and how.
“Team Topologies” consists of three parts. Part I is dedicated to the interrelation between team organization and system designs the teams build. In Part II, the authors provide a detailed analysis of team topologies, so you can understand which one is most suitable for your particular organization. Finally, Part III is focused on how to apply the team topologies approach to respond to customers' demands.
Below you can read a short summary of “Team Topologies” by chapter:
The pace of change in the modern world is accelerating every day. Today's IT organizations must adapt to changes, delivering software quickly. However, many of them still organize their teams in an unproductive way, seeing their teams as org charts. Org charts are based on a hierarchical line of reporting – according to them, communication between departments and teams goes “up and down”. This does not reflect the actual patterns: usually people communicate with each other laterally or horizontally.
So is there an alternative to org charts?
Niels Pflaeging, the author of “Organize for Complexity”, identifies three organizational structures:
Phlaeging says that successful work can be achieved through a combination of informal and value creation structures – which means, through interaction of individuals and teams. And this is exactly what Team Topologies approach is about: it recognizes teams as building blocks, bringing new way of understanding the concept of teams:
We must shift our thinking from treating teams as collections of interchangeable individuals that will succeed as long as they follow the “right” process and use the “right” tools, to treating people and technology as a single human/computer carbon/silicon sociotechnical ecosystem.
The Team Topology approach to building software systems is humanistic: seeing people as core elements, it takes into account that every person has a limited cognitive capacity. That is, the amount of information a person can hold and process in their head is limited. Unfortunately, this fact often gets ignored: the team is expected to meet the requirements and do the assigned tasks regardless of their cognitive capacity. This may lead to “delivery bottleneck”, as the team members start to get quality issues and miss deadlines. To avoid this, the Team Topology approach suggests thinking about cognitive loads before assigning responsibilities and deciding on team size.
All in all, Team Topologies focus on sociotechnical dynamics, emphasizing the role of interaction between teams and technology.
In 1968, Mel Conway, the computer systems researcher, published an article “How Do Committees Invent”, where we can come across what is now known as “Conway’s law”:
Organizations which design systems . . . are constrained to produce designs which are copies of the communication structures of these organizations.
To put it differently, the law states that there is a direct correlation between communication paths among teams and software architecture these teams build. Logically, the absence of certain communication paths makes it impossible to develop design alternatives. This hypothesis was confirmed by various researches (for example, studies of open-source and closed-sourced software products by Harward Business School).
This is why, to successfully build software architecture, it is necessary to understand what kind of communication is preferable among the teams, and reshape the organizational structure, if needed. Evolving teams by means of reconfiguring their communication is called “the inverse Conway maneuver”, and its main goal is to optimize the flow of work.
Let’s see how this works. For example, there are four teams working on different parts of a system. The person who makes database changes is a database administrator. According to Conway’s law, the software architecture that results would have four elements and a shared database. As the authors say, if this is what we want, then it’s all okay. But if not – then we’ve got a problem. In this case, we can apply the “inverse Conway maneuver”, organizing the teams in a way that would match the desired architecture.
In the context of Conway’s law, it’s important to restrict unnecessary communication between teams. More communication doesn’t always promote good results; even more; it can be an indicator of some issues. For example, if the software architecture doesn’t predict communication between two teams but these teams are still communicating, then it means that something is going wrong – maybe some element is missing, or the Application Programming Interface is not perfect. To restrict such communication, it’s enough to physically separate two teams, moving them to different parts of the office, or different floors.
With open-plan offices and, particularly, with ubiquitous, instant communication via chat tools, anyone can communicate with anyone else. In this situation, one can accidentally fall into a pattern of communication and interaction where everyone needs to communicate with everyone else... From the viewpoint of Conway’s law, this will drive unintended consequences for the software systems, especially a lack of modularity between subsystems.
As we mentioned before, a team is a cohesive unit rather than a group of individuals. The authors say that the speed, diversity, and change required by software systems may put a heavy burden on a single individual; this is why it’s more sustainable to rely on a team.
In the Team Topologies Approach, a team is a stable group of people working on the same goal. Teams are “the smallest entity of delivery”, and it’s teams that must be assigned responsibilities, not individuals.
The number of team members matters: the effective team size is supposed to include from 7 to 9 people. A curious way of keeping teams small enough is used by Amazon – their software teams include no more people than can be fed by two pizzas.
An important reason why a team must be small is trust: it’s extremely important to the effectiveness of a team, and, according to the anthropologist Robin Dunbar, fifteen is the limit of the number of people a person can trust (Dunbar’s number). Naturally, if a team grows too large, its effectiveness may decrease.
To develop trust, teams need time. To become a more or less cohesive unit, it takes up to three months. Will it be wise to reassign people after finishing a project on which they worked half a year? Probably not. Emotional adaptation to work habits and viewpoints of new colleagues will have a serious impact on performance. Only if the level of trust in an organization is high, then it’s possible to change teams once a year without any negative effects.
When it comes to rewarding, it’s very important to reward teams and not individuals: for example, if a person did an outstanding job, but the company gives them limited bonuses (or no bonuses at all), because it’s currently going through a financial crisis, this can be very demotivating.
The authors also emphasize the importance of maximizing the cognitive capacity of the team, providing the following techniques that may prove useful:
The team-first approach provides opportunities for many kinds of people to thrive in an organization. Instead of needing a thick skin or resilience in order to survive in an organization that atomizes individuals, people in a team-first organization have the space and support to develop their skills and practices within the context of a team.
Wanting to become a healthy team? Learn what it means, plus tactical advice from a bunch of experts in our recent ebook:
To work effectively, teams need to be consciously constructed, not forming accidentally by themselves. These consciously designed structures are team topologies. If such topologies fit a specific context at a given point of time, they are called static. Adopting team topologies that would match your current context, it’s important to draw a line between team anti-patterns and successful team patterns.
Team Anti-Patterns. These include:
Successful Team Patterns
As we can see, the feature-team and product-team patterns can be successful only if supported by the environment. At the same time, the authors point out that there is no right topology, but rather a couple of topologies that can be detrimental for a certain organization. However, even if you choose the wrong topology, it doesn’t necessarily mean that the outcome you will receive will be bad.
Organizations must design teams intentionally by asking these questions: Given our skills, constraints, cultural and engineering maturity, desired software architecture, and business goals, which team topology will help us deliver results faster and safer? Where should the boundaries be in the software system in order to preserve system viability and encourage rapid flow?
The variety of team types in organizations can be very confusing, so the authors reduce these to four main types, saying that this helps reduce ambiguity. A large organization is likely to have at least one team that represents each type. These are as follows:
Stream-aligned teams. The authors define stream as “the continuous flow of work aligned to a business domain or organizational capability.” A stream-aligned team works on a single product or service, a single set of features etc. This team is a primary type in any organization. They are closer to the customer and can collect feedback, reacting to problems almost in real time. Most modern teams are expected to be stream-aligned, having a clear flow of work to prioritize. The streams can be specific-customer, product, business-area, geography etc streams.
Some of the capabilities within a stream-aligned team are: development and coding; testing and quality assurance; design and architecture; application security etc
Expected behaviors of a stream-aligned team:
Enabling teams. These teams consist of specialists in a given technical domain. Their purpose is to understand the problems of steam-aligned teams and provide assistance. Instead of dictating which choices are better to follow, enabling teams help other teams understand the constraints. Basically, they aim at growing stream-aligned teams capabilities rather than providing solutions.
Expected behaviors of an enabling team:
Complicated subsystem teams. These are teams that reduce the cognitive load of stream-aligned teams that work on complicated subsystems (mathematical model, face-recognition engine, a transaction reporting system etc). These teams exist because embedding a specialist into a stream-aligned system would not be feasible, and they are created only when a subsystem requires a very specialized knowledge.
Expected behaviors:
Platform teams. The purpose of these teams is to make it possible for stream-aligned teams to deliver work autonomously. A platform is defined as “a foundation of self-service APIs, tools, services, knowledge and support which are arranged as a compelling internal product.” It provides internal services which a stream-aligned team needs to deliver higher level services.
Expected behaviors:
Many organizations struggling with rapid, sustainable software delivery have a wide range of different types of teams, each with different (usually poorly defined) responsibilities. To avoid this problem, restrict teams to just four fundamental types… This focuses the organization on team interaction patterns that are known to promote flow at both personal and organizational levels.
To enable teams to evolve their part of the system, we need to define suitable boundaries. The software boundaries must match the teams’ cognitive load. Stream-aligned teams should be responsible for a single domain; however, this is not easy if domains are hidden in monolithic systems.
The word “monolith” comes from Greek and means “a single stone”. Like a stone can be split in clear segments, monolithic software can be split into two or more parts. The seam in the software system that allows this is called a fracture plane. These fracture planes are software responsibility boundaries. Some of the fracture plane examples are:
As the authors say, the “litmus test” for a fracture plane applicability is this question: does the resulting architecture support more autonomous teams with reduced cognitive load?
By carefully exploring and validating the boundaries of responsibility between teams… we align the software architecture to the problem domain, increasing the flow of changes and providing the organization with the capability to evolve the sociotechnical system more rapidly and effectively.
Ineffectiveness in many organizations is caused by poorly defined interactions. According to the authors, the relationships between the teams boil down to two things: if you can achieve a goal collaborating with another team, or if it can provide you a service. This way, they determine three ways in which teams can interact:
Collaboration (close work) This mode is suitable when exploring new techniques and discovering new information. To use collaboration mode, there should not be friction between the teams. Also, a team cannot use it with more than one another team at a time. Its advantages are rapid innovation and discovery, while disadvantage – too many details that lead to a higher cognitive load. Typical uses: stream-aligned teams with complicated subsystems and platform teams.
X-as-a-service (minimal collaboration with the aim of consuming or providing something). It is used when a component of a system can be provided as a service by a different team. The context is clear: one team consumes, the other team provides. This mode puts a lot of responsibility on the team providing the service: it must know what exactly is needed, and be responsible for what they provide (a testing tool, platform etc). Typical uses: stream-aligned and complicated subsystem teams consuming Platform-as-a-service from a platform team.
Facilitating (helping to get rid of obstacles). Its goal is to help other teams learn more quickly, understand technologies better, and remove problems. A team with a facilitating remit is concerned with the quality of interactions of other teams; it does not take part in building software. Typical uses: an enabling team helping the three other types of teams.
What must be avoided is the need for all teams to communicate with all other teams in order to achieve their ends; just as a jazz band coordinates the music it plays, we should expect to carefully curate the communication that takes place within an organization.
Rapid changes in market conditions, customer demands, and technology capabilities require organizations to be flexible. This means organizations are expected to adapt and evolve their structure, optimizing for flow. Responding to new challenges, an organization should be able to apply necessary team topologies and the right interaction mode: for example, if a team needs to explore part of the technology stack handled by another team, they can use collaboration mode for a specific period of time.
Some organizations use a particular mode on a permanent basis. The thing is, once the context changes, they need to be ready to change too. So what are the triggers that can be a sign that an organization needs to evolve?
Another thing the authors mention in this chapter is organizational sensing. This is a capability to sense the situation – and to make sense out of it. As they say, many organizations are “senseless” but this ability is crucial for organizational survival. Some of the things that an organization needs to “sense” are:
The combination of well-defined teams and well-defined interaction modes provides a powerful and flexible organizational capability for structural adaptation to changing external and internal conditions, enabling the organization to “sense” its environment, modify its activities, and focus to fit.
“Team Topologies” by Skelton and Pais present a way to address issues caused by an ineffective model of software development - like disengaged teams, poor flow of changes, inability to respond to rapid changes, etc. The team-first approach, based on four fundamental types and three interaction modes, can help organizations overcome challenges. It can be useful for CEOs, heads of department, software and systems architects and other people trying to evolve their organizations.
📚 Read other book summaries on management from Runn:
