How to create high-performing software teams with team topologies
From hero culture to team flow
Has the IT industry created a culture where individual achievements are celebrated? Where the so-called 10x developers are crucial to a project’s success? And is it even appropriate for a few individuals to bear the great responsibility? Team Topologies points out that teams are the core of delivering high-quality products efficiently.
Imagine a software team where much depends on one superstar developer. When they go on vacation, uncertainty arises in the team, colleagues feel pressured, and errors creep into the code. This is a clear sign of a vulnerable team structure – and precisely the problem that Team Topologies aims to solve.
In this blog post, we explore the principles of Team Topologies and look at the significance of team interactions for software architecture. Henning Böttger is a Senior Software Architect at Mjølner, and he provides specific suggestions on how to make a team effective. It is about designing our teams to promote collaboration, reduce friction, and maintain sustainable productivity. And it is necessary to manage cognitive load if you want to create high-performing teams.
You can also watch Henning’s entire lecture on the topic at the bottom of this page.
The socio-technical aspects of teams according to team topologies
To understand why some teams perform better than others, it is necessary to examine the socio-technical dynamics that affect team efficiency. This involves both human collaboration patterns and the technical structures that shape software development.
Effective team design, as mentioned, is about more than just assembling skilled individuals. The way teams interact determines their ability to deliver value efficiently. Team Topologies introduces a structured approach to organizing teams based on their function and communication patterns.
Instead of relying on a hero culture, where individual members bear a disproportionate burden, organizations should focus on building autonomous teams with clear responsibilities and fewer dependencies. This approach leads to more predictable outcomes and a sustainable development pace. As Henning points out, focusing on individuals rather than the team can create a negative spiral:
“We can develop a hero culture where certain individuals always step in to save the day. This creates a self-reinforcing effect where the heroes become smarter and more important, while the rest of the team does not develop in the same way.”
Conway’s law: The hidden Blueprint for software design
One of the most fundamental concepts in team organization is Conway’s Law, based on Melvin E. Conway’s groundbreaking 1967 article: “How Do Committees Invent?“ The law states that the way teams communicate and interact influences the architecture of the systems they create. When organizations are divided into silos, their software will reflect that division, often leading to inefficiency and fragmented systems. Henning points out the importance of being aware of this correlation:
“If the organization’s structure and the architecture are at odds, the organization always wins. This means that even the best architectural ambitions can be undermined by poorly designed teams.”
Conversely, organizations that deliberately design their team structures to support the desired architectural outcomes can create scalable and maintainable software. Instead of trying to fix software problems after they arise, companies should focus on improving team communication and alignment first, as this will naturally lead to better systems.
Dunbar’s number: Why small teams work best
A team’s efficiency is also influenced by Dunbar’s number, which suggests that humans can only maintain strong, trust-based relationships with a limited number of people. In the 1990s, British anthropologist and evolutionary psychologist Robin Dunbar discovered a correlation between brain size and group size in primates. He hypothesized that humans have a cognitive limit to the number of social relationships we can manage effectively.
For software teams, this means that smaller, closely-knit groups are more effective at communicating and solving complex problems. Dunbar’s number for larger networks is estimated to be around 150, while for close and trust-based groups, it is between 5-15. Henning describes it like this:
Source: Wikimedia Commons
“We know that high-performance teams need trust. Therefore, we should keep teams small and closely-knit so they can function without unnecessary dependencies.”
When teams become too large, coordination becomes more difficult, collaboration weakens, and the decision-making process slows down. This is why many high-performing organizations limit team sizes and ensure that each team remains small enough to function effectively without unnecessary bureaucracy or friction.
For example, Amazon has implemented the famous “two-pizza rule,” where each development team should be small enough to be fed by two family-sized pizzas – typically 6-10 people. Small, autonomous teams make it easier to adapt to changes and reduce dependencies, ensuring that the software architecture remains flexible and modular.
Managing cognitive load for maximum efficiency
In addition to team size and communication patterns, another critical factor in productivity is cognitive load – the total mental effort required to perform a task. When developers are overwhelmed by complex systems, inefficient processes, or excessive responsibilities, productivity decreases. Henning reflects on how it can feel as a developer to hit a mental wall:
“I often sit and think: Why is this so hard? I know the technology, but there is so much friction in the test environment and processes that I become mentally drained. This is what happens when cognitive load becomes too high.”
To reduce cognitive load, one should limit the team’s area of responsibility (bounded contexts). This involves setting clear boundaries so that a single team is not involved in too many domains or technologies – this can be achieved through Domain-Driven Design, where a team can focus on one value stream.
Structuring and Designing teams for High performance
In addition to reducing cognitive load, it is crucial that individual teams are designed according to their specific purpose. With a clear understanding of socio-technical dynamics, organizations can structure their teams more effectively. Team Topologies describes four central team types:
- Streamlined teams – Responsible for delivering end-to-end business value and owning specific features or domains.
- Enabling teams – Help streamlined teams acquire new skills, such as DevOps practices or security expertise.
- Platform teams – Maintain shared infrastructure and reduce the operational burden for development teams.
- Complicated subsystem teams – Handle specialized, complex components that require deep technical expertise.
A well-organized team structure is not only about defining team types but also about how the individual teams collaborate. Team Topologies identifies three primary interaction modes:
- Collaboration – Teams work closely together when solving new or complex problems.
- Facilitation – One team helps another develop new competencies and then steps back.
- Access-as-a-Service – Teams interact with minimal direct communication via well-defined APIs or automated processes.
Although clear communication and good collaboration are parameters that can be perceived as “soft” and difficult to measure, they can have a decisive impact on the business and the bottom line. As Henning puts it:
“We can have the best processes on paper, but if teams do not communicate effectively or have the right structure, everything falls apart.”
Take the step from theory to practice with team topologies
Team Topologies shows us that success in software development is not just about talent, but also about structure. By designing teams with clear roles, reducing cognitive load, and understanding the interaction between people and technology, organizations can create more effective and sustainable development teams.
Whether you work in a large company or a startup, small changes in team organization can have a big impact. You can start by mapping your dependencies, identifying bottlenecks, and considering how team design can support your architecture rather than hinder it. Perhaps Team Topologies can help you create better collaboration and more robust systems.
“This is not about a revolution, but about small, meaningful adjustments that can make a huge difference.”