Team Topologies by Matthew Skelton: how the Conway’s law and the Cognitive Load Theory support optimal design of organization

Team Topologies, in a nutshell, is an approach elaborated on the Conway’s law and the Cognitive Load Theory to support an optimal design of organizations for both business and technologies. Surely, Team Topologies enables fast flow and flexibility in product discovery and delivery.

Team Topologies pillars: the Conway’s law and the Cognitive load Theory

As a matter of fact, Team Topologies leverage both the Conway’s law and the Cognitive load Theory. Let’s introduce them.

Conway’s law

The Conway’s law states that the system, in other words, the software architecture, results from the organization of the teams. On the contrary, the “inverse Conway maneuver” or “reverse Conway maneuver” starts with the organization of the teams to match the software architecture expected from the system. Clearly, this is more efficient than just relying upon teams to follow a mandated architecture design.

Cognitive load Theory

John Sweller, an educational psychologist from Australia, introduced the Cognitive Load Theory in 1988.

As a result, teams, like human beings, have a limited cognitive capacity that you need to optimize. Therefore, teams’ cognitive load should focus on their core perimeters and you should remove all other responsibilities and perimeters.

Not doing so, and the team will struggle to face all its responsibilities:

• paying the price of context switching.
• not building mastery.
• at last, not taking full ownership of its perimeter.

The 3 types of Cognitive Load

Check my post for more on the Cognitive Load Theory.

To sum up, the Cognitive Load Theory highlights that there are 2 kinds of knowledge and information:

• Those that are core to the topic like the coding language or how to properly code.
• And those that are needed but non-core, like how to compile the code or how to refresh a test environment.

As a result, you want to save the individuals’ and teams’ working memory for core elements (intrinsic cognitive load) and to learn or solve problem (germane cognitive load) and reduce everything that is not core (extraneous cognitive load). Clearly, innovation, but also in extreme case quality, are at stake.

Applying the Conway’s Law in Team Topologies for Organization Design

Small team

Small teams have small perimeters of responsibility, therefore, a lower cognitive load. But there is more. Indeed, the system is also impacted following the “inverse Conway maneuver”: the architecture of the system, the software are easier to understand. Clearly, this limits the size of modules and makes it easier to manage changes as they impact a single module.

Independent team

Many organizations assume that more communication between teams is always better. But, the Conway’s law implies that a many-to-many communication will prevent modularity and create monolithic and highly coupled systems. Surely, anti-agile systems where fast and flexible flow is not possible.

Therefore, restrict unnecessary communication between teams. So, define “team interfaces” to set expectations regarding communication and collaboration between teams and enforce them. Really, if two teams need to communicate, but should not based on the software architecture design, there is a problem somewhere.

Shared tools

If you want teams to collaborate, then have them share the same instance of tools. On the contrary, to enforce a clear boundary between teams, have them use separate instances of tools.

For example, different ticketing or incident-management tools will prevent collaboration between software development team and related IT operation team.

Skills for Organization Design

As Organization Design has a strong impact on the architecture of the software that the underlying organization delivers, it is mandatory to have a technical expertise to properly design an organization.

Applying the Cognitive Load Theory in Team Topologies for Organization Design

The Dunbar’s numbers

Robin Dunbar is a British anthropologist who studied the link between primate brain size and average social group size. As a result, he proposed in the 1990s, numbers for size of social groups and for each the level of intimacy possible. For human beings, based on our brain size, he proposed the following sizes of social groups:

• 5 people, people we love, is the average number of people a human being can hold with close personal relationships and working memory.
• 15 people, good friends, is the average number of people a human being can experience deep trust with.
• 50 people, friends, is the average number of people a human being can have mutual trust with.
• 150 people, meaningful contacts, is the average number of people a human being can have a real social relationship with.
• There are 2 more numbers, 500 for the number of acquaintances and 1500 for the number of people a human being can recognize.

Indeed, sizes of Agile Teams (7+/-2) and Tribes (around 150) directly come from Dunar’s works and other social studies.

Small team

As a consequence, the Cognitive Load Theory and the Dunbar’s numbers support, like the Conway’s law, to design small teams in the organization. We have seen with the Conway’s law that small teams have a positive impact on the software architecture making it simpler and more flexible with modular architecture. Clearly here, the other impact of small teams is to reduce the Cognitive Load for the teams.

The size of the perimeter a team is in charge of, directly impacts the Cognitive Load but there is more: the complexity of the perimeter and the required non-core knowledge.

Manageable domain complexity to minimize Intrinsic Cognitive Load

The first aspect that drives the complexity of a perimeter is the complexity of the underlying domain(s). The more domains in a perimeter or the more complex these domains, the more complex the perimeter as a result. So make sure to limit the number of domains and their complexity.

The authors of the Team Topologies propose this approach. Identify context domains that the team has to deal with and categorize them by level of complexity:

• Low, most of the work is straightforward.
• Medium, the team has to analyze changes then iterate a few times.
• High, the team needs a lot of experimentation and discovery.

The guidelines they propose:

• An Agile Team can manage 2 to 3 low complexity domains.
• A single team managing a complex domain should be dedicated to it. Truly, this team should not manage an additional domain even a low complexity one.

Set clear boundaries to minimize Extraneous Cognitive Load

You need to ensure that the team has to manage only required knowledge to deliver its work. To do so, restrict team’s responsibilities to core knowledge and simplify the need to understand and manage non-core knowledge. In other words, simplify processes, automate everything with friendly Developer Experience and build as a service all supporting services like the software factory, the deployment or refresh of environments.

Surely, Craftmanship and DevOps are a must do. Developers should use intrinsic cognitive load only to master the coding language, the coding technics and the functional knowledge of their perimeters. As a result, this will maximize the working memory for the germane cognitive load, in other words, the capacity to learn and solve problems.

The 4 stages Tuckman model: how teams perform

Bruce Wayne Tuckman, an American Psychological Researcher, proposed in 1965 a model about how a team forms. Surely, it highlights that team performance is not from granted and requires time. The 4 stages the teams go through are:

• Forming: members of the new team gather for the first time.
• Storming: the diversity of team members (personal and professional backgrounds and ways of working, psychological profiles, cultures) leads to conflicts.
• Norming: the team sets more or less explicitly standard ways of working together.
• Performing: at last, the team reaches a state in which it works with efficiency.

This explains that Agile Teams are stable teams, to put it differently, long term teams (12-18 months). Typically, a team needs between 2 weeks to 3 months or more to become a consistent group.

Stable team

Trust

But building trust requires even longer. In high-trust organizations, people may move from one team to another once a year without major detrimental effects on team performance. Then, in organizations with low level of trust, people should remain in the same team for 18 to 24 months. In addition, teams in these organizations need coaching to build, improve and sustain team consistency.

Ownership of code

Team’s ownership of code is mandatory to provide continuity of care the software needs in order to remain operable and to fit its mission. Surely, team ownership enables a team to think in multiple time horizons from discovery stage to production.

If everybody is owner, nobody is owner and the sustainability of the software is at stake. Therefore, make sure that a team or a small group of teams owns the code and has a long term responsibility on it for both build and run. To enforce speed of changes, they may grant access to other teams, but they remain responsible for instance with code review and managing bugs in production.

Diversity

Stable team does not mean that all the team members are the same. On the contrary, as diversity is the key to innovation and creativity.

DevEx: Developer Experience

DevEx is an important way to decrease Extraneous Cognitive Load. Surely, it supports external teams to use the software of another team. Also, this facilitates team interactions, then flexibility of the Organization.

To illustrate, consistent APIs with good UX and good documentation increase the quality of Developer Experience (DevEx) and decrease Extraneous Cognitive Load for other teams. A typical example are platforms that are explicitly designed to reduce cognitive load for teams building software on top of it or using them to build their software.

Google and Amazon solved their problems of monolitic code with modular architecture and systematic APIs for each module.

Space

Space covers at the same time the physical display of the office for collaboration and the co-location of teams working together for the same product and/or the same value chain.

Office design for effective software delivery should enable the different types of work:

• focused individual work.
• collaborative intra-team work.
• collaborative inter-team work at product and/or value chain level.

And this goes beyond the traditional split between IT and business: they should be on the same area, in the same floor. Truly, this supports to break down barriers between departments and align them on their shared goals and customers. Furthermore, common tools can support this alignment and collaboration.

Remote working is a challenge as you need ideas to emulate this feeling of common belonging, for instance with common communication groups or naming conventions.

Check the resulting Cognitive Load

As a sanity check, you can assess the teams with simple questions to confirm that they feel conformable about managing their perimeter. Surely, this is a quick and qualitative measure but still it is a valuable safety net for your Organization Design.

Identify Fracture Plane to set boundaries in Team Topologies

A fracture plane is a natural seam in the software system. Therefore, it is a logical way to split software to create the boundaries the teams needs.

DDD Domain-Driven Design

The most common fracture plane, then alignment of software, is by Business Domain. It is always better to promote business drivers to structure the IT organization but you may reach some limits (uncommon technologies driving to skill constraint).

Surely, DDD can help here.

Other functional fracture planes

• User Personas.
• Regulatory Compliance: in highly regulated industries, like finance or healthcare, regulatory requirements want organizations to comply with specific auditing, documenting, testing and deploying software to meet these regulations.

Some technical fractures

• Technology, especially for older or less automatable technology requiring manual processes, specific and hard to hire skills.
• Performance or Risk, with subsystems having different levels of constraint.
• Change rhythm.

Be aware that splitting software tends to reduce the consistency between the different parts of the software. Definitively, this can lead to duplications. In addition, the user experience (UX) may also lose consistency. Thus, you should have a special concern about architecture and UX consistency.

The Four Team Topologies

Stream-Aligned Teams

A stream-aligned team stands for Squad / Feature Team or Product Team as we describe them in the Agile at Scale model of this blog. Surely, this is in the logic of alignment of teams on the value flow with minimum dependencies. To clarify, a stream-aligned team is a team aligned on a value chain such as a product or service, a user journey or a user persona. As a matter of fact, the team is empowered to design, build and deliver value quickly, safely, and independently from other teams as far as possible.

The stream-aligned team is the main type of team in an organization. Actually, the purpose of the other types of team is to support stream-aligned teams and to reduce non-core tasks relatively to their perimeters.

Stream-aligned teams enforce the principles “you build it, you run it” and cover all the core tasks relatively to their scope:

• Product management and ownership
• Functional and Technical Design
• Application security
• User experience (UX)
• Development and coding including testing and QA
• Production support
• Metrics and monitoring

In some cases because of the stream-aligned team size or the critical size of production and testing teams, production and testing are outside the team. But you should enforce alignment and close collaboration between stakeholders.

Note that infrastructure is traditionally managed as a service.

Complicated-Subsystem Teams

A complicated-subsystem team is responsible for building and maintaining a system so complex, specific or legacy that team members must be specialists in that area of knowledge. Clearly, the goal of complicated-subsystem teams is to reduce the cognitive load of stream-aligned teams that include or use the complicated subsystems.

Enabling Teams

An enabling team is also composed of specialists in a given technical or product area. To clarify, the role of enabling teams is to research, try options and elaborate informed suggestions on relevant practices, frameworks and tooling to support the stream-aligned teams either on their functional and technical context. As a result, enabling teams make it possible for stream-aligned teams to acquire and evolve skills without having to invest the full effort.

Note that, an enablement team should plan for its own ending from the beginning to prevent other teams from becoming dependent.

Enabling Team versus Communities of Practice (CoP)

The members of an enabling team work full-time on enabling activities. On the contrary a Communities of Practice (CoP) is something like a guild as described in the Agile at Scale model of this blog. To clarify, it is a part time activity, on voluntary basis and across teams to share best practices and returns on experience.

Platform Teams

The platform team provides software as internal services to reduce the cognitive load of the stream-aligned teams. In other words, a platform team off-loads the lower level detailed knowledge, for instance provisioning, and deploying environment, and provides easy-to-consume services to stream-aligned teams.

Those services are required but non-core to the stream-aligned team activity.

Definitively, a good UX/DevEx is mandatory to make the platform friendly to use. Furthermore, APIs should be consistent with the Organization standards and properly documented: comprehensive, practical to client teams and up to date.

Team interactions in Team Topologies

Collaboration: close work between 2 teams

The collaboration interaction is relevant for exploration and innovation because it avoids costly and slowing hand-offs between teams. Then, it is is a good choice when exploring new technologies or techniques.

There are 2 levels of collaboration:

• In the lowest level of collaboration interaction, the 2 teams keep their responsibility and expertise related to their original perimeter and they work together on a specific subset of tasks and deliverables.
• Then, in the highest level of collaboration interaction, even if teams have at start different responsibilities and expertise, they work as a pool on all tasks and deliverables. As a result, they share a common responsibility and expertise tends to converge.

DevOps as a specific case of collaboration

DevOps is the movement that emerged in 2009 to smooth the interaction between Developers and IT Operations. When Dev and Ops are not part of the same team, Dev team and Ops team need to closely collaborate with DevOps approach to prevent issues with handover of software from development to production. DevOps calls this handover the “wall of confusion.”

All the more so that Dev teams are Agile. Indeed, Agile frequent deployments increased the pressure on IT Operation teams that become a bottleneck and this even puts stability of production at stake.

X-as-a-Service: service provided with minimal collaboration

The X-as-a-Service team interaction is relevant where a team provides a service to another team like an API or a platform to be used with minimal effort and knowledge. Surely, even if the team proposes this service internally to other teams, product management should be at state of art with the service team truly listening to needs of the teams that consume its service. At last, this team should also master and enforce the principles of service-management when designing and building its software.

Facilitating: support team to clear roadblocks

The facilitating or coaching interaction is about reducing gaps in skills of the target team.

Changing team organization and collaboration with Team Topologies

Designing and implementing a new organization is a major work. But it does not stop when the organization is implemented. Indeed, you need to keep an eye on the work of teams and how the organization matches. Indeed, work may evolve and require a change in organization or collaboration. For example, a software may grow too big for a single team.

In addition, you may want to deliberately change the organization or the interaction between 2 teams depending on the lifecycle of the software:

• During the initial phase of a software when you want to create a platform, you may want to choose close collaboration as an enabler for rapid learning and adoption of new practices, tooling or frameworks.
• Another example, for the retiring phase of a software, could be a system becoming legacy, and you may have to switch related team(s) from stream-aligned team(s) to a complicated-subsystem team.

What’s next? Learn more about Agile at Scale

Check my other posts about Agile at Scale:

• Review my posts on Agile at Scale foundations:
  • What are
    • Agile Squad?
    • Chapter and Guild?
    • Tribe?
    • Product Management Team?
  • What are the team topologies?
  • How to synchronize Agile Squads in Agile at Scale when there are dependencies?
  • Check another of my posts introducing Agile at Scale that leverages the book “Doing Agile Right”.
  • Review my post on the Agile best practices from the GAO the Government Accountability Office from the USA.
• Read my posts on advanced topics around Agile at Scale:
  • What are Leagues in Agile at Scale?
  • How to design Agile Squads so they are aligned on the Value Chains.
  • Why going for horizontal management? What does it mean and what is the value?
  • How roles are reallocated with Agile at Scale?
• Check my posts on project management in Agile at Scale
  • What is the impact of Agile on Project Management?
  • How does Project Portfolio Management change with Agile at Scale?
  • Then, how does Cost of Delay Divided by Duration (CD3) contribute to Agile at Scale?
  • How does Beyond Budgeting support Agile at Scale?
  • Can an Agile Project be fixed price?
  • How to manage Release Management in Agile?
• Review my posts on how to forge a good strategy:
  • What are competition and competitive advantage?
  • What is a good strategy?

Do you want to learn more about Team Topologies? Here are some valuable references

References from Matthew Skelton and Manuel Pais the authors of Team Topologies:

• The book Team Topologies.
• The website of the authors.
• Some articles about Team Topologies:
  • Get Started With Team Topologies In 8 Steps
  • Minimize Team Cognitive Load To Increase Flow

Other related references:

• Wikipedia on Conway’s law.
• Wikipedia on Dunbar’s numbers.
• A post from BBC about Dunbar’s numbers.
• Wikipedia on Tuckman’s the stages of group development.
• Wikipedia on Domain-driven development.
• A post from Medium on Domain-driven development.