Team Topologies is probably one of the most pragmatic and practical Organisation Design books I have read in recent years. Considering that this is a book written with technology management in mind (I guess a CTO would be the reader the authors had in mind), this book crystallises the failure of Organisation Design as a discipline that HR should master. The authors ask themselves “How much awareness does the HR department have about software systems?” Then argue that “we need to involve technical people in organisation design because they understand key software design concepts“. I will, however, deal with this aspect in a separate article.

The two authors are Matthew Skelton and Manuel Pais, both Software Consultant with a lot of experience in DevOps methodology. The core idea of the book is that organisations delivering software should build their organisation according to the value they want to provide to their customers. Based on the recent development in Agile and above all DevOps methodologies, this book argues that it is necessary to align the organisation to the best practices of software coding, to prevent the results of the so-called  Conway’s Law, which essentially states that software will match the way the organisation is organised.

The Importance of Teams

Team Topologies underlines the importance of Teams for the development of software. However, from the beginning, it argues against specialised teams and instead brings up arguments to create groups that can deliver “end to end” their solution. The authors insist that the team needs to reach a size where Trust can consolidate and High-performance blooms, thus never exceeding 9-12 components.

As much they become the core element to deliver performance, in an environment (that of technology) where individual contribution, although relevant, is often not sufficient in the wake of the complexity of current technology. Cognitive Load is one of the factors that the two authors examine, not only at an individual level but also as a limiting factor for the team’s performance. Teams need to be designed and sized on handling an object that will not create “cognitive overload”.

Type of Teams.

They identify Four Types of Team that should be used to assemble the organisation and three modes of interaction across teams. Their view may seem a bit mechanistic at first, but they provide many justifications for each assertion, both deriving from experience and available academic research.

The four types of teams they identify are:

Stream Aligned Teams

“A “stream” is the continuous flow of work aligned to a business domain or organisational capability. Continuous flow requires clarity of purpose and responsibility so that multiple teams can coexist, each with their own flow of work.” The idea is that this team would align on an end-to-end value flow that matches an organisational or technical capability. The team would be empowered with end-to-end responsibility to deliver customer value quickly. This implicitly means that components need to possess all required competencies, creating an integrated, flexible team.

These teams can take the form of micro-enterprises, effectively “owning” the results of their work—a key element in some of the organisation models that are becoming market-oriented.

The concept of stream aligned teams overcomes the typical criteria of Product or Feature which characterised earlier iterations of agile methodologies. The reason is simple: both Product and Features are technical constructs: to have a genuinely customer-oriented value creation, you need to align teams with the way customers perceive value.

Enabling Teams

“An enabling team is composed of specialists in a given technical (or product) domain, and they help bridge this capability gap.” Essentially these teams are created to ensure that the organisation makes space for competency development. As Stream-Aligned Teams are going to be under a delivery pressure, these teams instead can build the capabilities needed to advance innovation.

These teams “cross-cut to the stream-aligned teams and have the required bandwidth to research, try out options, and make informed suggestions on adequate tooling, practices, frameworks, and any of the ecosystem choices around the application stack.” They are highly collaborative and have a consulting nature of guidance, not execution in their domains. Their focus should be knowledge transfer, and this is also what characterises them as opposed to COmmunities of Practices, which are more focused on social learning.

Complicated Sub-System Teams

“A complicated-subsystem team is responsible for building and maintaining a part of the system that depends heavily on specialist knowledge, to the extent that most team members must be specialists in that area of knowledge in order to understand and make changes to the sub-system.” There are some parts of technology that are simply too complicated to be managed as part of a value stream, and therefore need dedicated resources. Examples of these could be a mathematical model, a real-time trade reconciliation algorithm, a transaction reporting system and so on.

Platform Teams.

“The purpose of a platform team is to enable stream-aligned teams to deliver work with substantial autonomy.” This relates to the concept of “platform”, which is the foundation of self-service functionalities through APIs, Tools, Knowledge and Support, that allows other teams to speed up their work and be autonomous. Platforms can take many shape and forms, depending on the architecture chosen by the organisation, but what are essential ios that “A platform team’s value can be measured by the value of the services they provide to product teams.”

Aligning Teams

The above Team Types become the building blocks to assemble the right organisation capable of delivering proper software through the rapid and safe flow. These structures overcome traditional organisational silos created in the past, whereby teams were organised by speciality. Creating mixed teams enables agility: however, to achieve this, we need to interpret roles flexibly and look at team competencies rather than individual jobs. The risk of seeing a team composed of one expert in each field is a risk that creates bottlenecks on the road to true agility.

Creating proper boundaries between teams is the content of chapter six, which identifies critical issues in the process and proposes several ways to ensure teams are appropriately allocated. A first element needs to come from ensuring that tightly coupled architectures are avoided. Loose Coupling is an enabler of the autonomy of groups, an aspect we have seen recently also in Netflix’s experience.

This comes along the destruction of monoliths. Interestingly the authors identify seven types of monoliths that need to be rethought of… and not all of them are technological:

1. Application Monoliths, which are single, large applications with many dependencies and responsibilities, exposing many services to different user journeys. (Why do I keep thinking of SAP?🙃)
2. Joined-at-the-Database Monoliths, in these cases these separate applications, but all linked to the same database schema, making it difficult to change and deploy separately.
3. Monolithic Builds. This is when large applications require a gigantic continuous integration build to get a new version up. (Sorry… again thinking of an SAP upgrade… 🤓)
4. Monolithic Releases, this happens when you need to “bundle” releases together of different components.
5. Monolithic Model this is akin to a Single View of the World that attempts to build a single format representation across many different contexts. Coherence is sufficient to seek, especially in smaller organisations, but this can become an impediment in other cases.
6. Monolithic Thinking. This often leads to too much Standardisation with a “one size fits all” mentality.
7. Monolithic Workplace. Yes, interestingly also enough having one single office layout (often simple open-plan office) essentially underlines a “one way” of doing things.

Interesting to notice that dismantling monoliths seem more of a culture transformation than a pure technology challenge.

Creating Team Boundaries

The authors introduce the idea of creating team boundaries by identifying “Fracture Planes”. “A fracture plane is a natural seam in the software system that allows the system to be split easily into two or more parts.” The book identifies eight possible fracture planes.

1. Business Domain Bounded Context, which essentially means assigning a team to an internally consistent business domain area.
2. Regulatory Compliance
3. Change Cadence, essentially aligning to different frequencies of change the systems might have.
4. Team Location (the authors argue that for building a successful team this should either be co-located in the same physical space, or there should be a proper remote-first approach)
5. Risk
6. Performance Isolation
7. Technology
8. User Personae

All of these should, however, be validated through a logical test: “Does the resulting architecture support more autonomous teams (less dependent teams) with reduced cognitive load (less disparate responsibilities)?“

Defining Team Interactions

One of the interesting concepts that this book brings out is that team interaction should also be architected. The idea is that if two teams collaborate too much, there is something wrong in the architecture. Either they have been created on an “artificial boundary”, or there are dependencies between the teams that can configure a risk. This does not mean that individuals should not talk among each other; the focus here is on team communication and collaboration.

Skelton and Pais identify three types of interaction modes:

1. Collaboration: working closely together with another team
2. X-as-a-Service: consuming or providing something with minimal collaboration
3. Facilitating: helping (or being helped by) another team to clear impediments

For each of these modes, the authors identify Advantages and Disadvantages, pointing out that a significant element of building Team Topologies is planning the correct Interaction Mode across the team. It is essential especially to underline that “collaboration” should not be the first choice (as some people automatically connect to the word “collaboration” a positive feeling). At the same time, Facilitation is not a hierarchical gesture. All teams are equal in terms of team-first thinking.

Build Sensing

Seems interesting to find “sensing” in a highly technical book, but chapter 8 talks strictly at how to evolve team structures with organisational sensing. The authors give an unambiguous indication of what should be the scope of organisation design in a modern software organisation.

the most important thing is not the shape of the organization itself but the decision rules and heuristics used to adapt and change the organization as new challenges arise; that is, we need to design the design rules, not just the organization.

Matthew Skelton and Manuel Pais, Team Topologies

The rules that they suggest are around establishing what the right level of collaboration in each team interaction is, how to accelerate learning and adoption of new practices, and the fact that several factors should be considered to review the Team Topology created and favour a new one.

Conclusion

Team Topologies is a truly excellent read. The core ideas of the book are truly transformational in the way you address organisation design in a technology organisation.

However, after reading, I think that the ripple effects of this book are much broader, as a lot of the issues the book identifies are beyond software creation alone. First and foremost, because the software is becoming ubiquitous in all of our firms, we can’t think of organising consumer-facing services through DevOps principles and keep back-office systems in traditional, siloed, waterfall modes. The issue is that digitalisation is changing expectations of consumers and customers also towards more conventional products and services, which call for a much more integrated view on how we should structure our organisation.

As mentioned, I will probably take the leads out of this book to write a few more considerations separately. Let me tell that as I read through it, I saw some key ingredients in the way organisation model and operating model interact to ensure value creation—a fundamental principle in Building the Intentional organisation.

A must-read for any practitioner in organisation design, not just those more oriented towards technology. Digital Transformation requires intentional and disciplined approaches similar to the one outlined in Team Topologies. For us, HR practitioners, the necessity to complete the picture, painting the effects of such a model on the rest of the organisation, and its components, including hierarchy, governance, but above all culture.

Did you have any experience with Team Topologies or applications of any of the team types? If so, why not share it in the Comment Section?

Team Topologies Reviews on GoodReads