Team topologies in adaptive organisations

“If change is happening on the outside faster than on the inside the end is in sight.” – G.E. Welch

“Organisations that design systems […] are limited to creating designs that map the communication structures of those organisations.” – Melvin E. Conway.

These two quotes describe the challenges of modern IT organisations: the need for change and for permanent adaptation to new circumstances is increasing: be it new wishes of the market, increased demands on the products or changing technological foundations. Furthermore, the complexity of the products seems to know only one direction: everything is becoming more powerful, more integrated, more dependent, more business-critical and more complex, so that it is becoming more and more difficult and important to keep an overview of these complex structures and to keep them under control.

At the same time, however, the structures of an organisation and the structure of the products it produces are inseparable: they influence and condition each other. This leads directly to two highly difficult questions: which organisational structure is suitable for us and our product in the current situation? And how should the organisation evolve or adapt? What should it look like in three months, six months, two years? Flexibility alone is not enough: it must also be directed and channelled towards goals. One possible answer is provided by team topologies and the temporal course of cooperation of different team types.

Motivation for change

In addition to the goal towards which flexibility is directed, the underlying motivation and the recognition of the need for change are relevant. At what points does this become visible? An adaptation in the way an organisation works or its structure is preceded by the process of the desire for change. This can have its origin in the growth of the organisation, for example. The software product that is being developed goes beyond the boundaries in which it can be developed in a team. The two-pizza paradigm is well known in this context: a team should only be so large that two pizzas are enough for lunch. This argues for team sizes between seven and nine people. In his studies, anthropologist Robin Dunbar has recognised the number 15 as the limit to the number of people a person can build deep trust with.

A good example is the decreasing cadence in the speed of development and the provision of new functions in a software product to the customer. If there is an increasing dependency of individual teams so that they can no longer act independently, the whole process slows down. The analysis of communication paths in a software architecture allows revealing conclusions to be drawn about the organisation. If the architecture does not present a “clean” picture, this is a good reason to look at the structure of the organisation.

Conway’s Law

Every organisation has visible structures, represented among other things in an organisation chart with departments. The same applies to applications, whose structure is called architecture. These two structures are very important because they draw important boundaries and influence how the organisation and the application function. The computer scientist Melvin E. Conway already stated half a century ago that the design of systems is predetermined by the communication structures of the implementing organisations. This is beautifully described in the law named after him: “Organizations which design systems […] are constrained to produce designs which are copies of the communication structures of these organizations.” This can be translated more casually into the statement “You always ship your org chart”. The structures of the organisation are always reflected in its products. If the organisations are complicated in design, the products they produce are also complicated.

It is therefore of great importance to look at the interplay between organisation and architecture. Organisations are constantly changing. Driven by market changes, globalisation, changing buying behaviour and many other circumstances, internal structures, product portfolios and processes have to be adapted regularly. In an IT landscape with monolithic legacy systems, there is often a lack of the necessary flexibility to react quickly to the aforementioned changes. For more flexibility, IT has been striving for more modularisation for years. Decisive for the success of an IT organisation is its ability to adapt quickly to changing conditions. So if you want to create software with modern architecture, you have to make sure that the organisation does not contradict this. It has to be said so strictly: modern architecture based on old organisation will simply not work. Many IT projects fail because of this problem.

Figure 1: Practical example of Conway’s Law

An example of this law is the implementation of a simple application. The software architecture is inevitably a reflection of the organisational and communication structure. If you think of your organisation differently, other architectural elements become visible. The illustration makes this clear: if you think in purely technological terms, you end up with purely technical teams. Conversely, if one thinks in terms of functionalities, functionally structured (and presumably cross-functional) teams become visible. This internal structuring has implications for the customer relationship: is a layered organisation sufficiently capable of recognising and responding to the customer’s needs?

Manuel Pais and Matthew Skelton have tried to systematically explore organisational forms and their effects in their book Team Topologies¹. In the following, we use their terms for ease of transferability.

The four types of team topologies

Many IT organisations are changing their structure more towards a team organisation. In principle, only four different types of teams are needed to build and run modern applications. The organisation can use these four types as the target point of organisational change, i.e. all teams (and projects and departments) evolve towards one of the following team types respectively.

Figure 2: 4 types of team topologies²

Stream-Aligned Team

Stream-Aligned Teams are aligned with value streams. These value streams are either related to areas of the business or organisational capabilities. Specifically, this can be a particular product or service, a set of attributes in a product or a selected persona.

Stream-Aligned Teams form the basis of an organisation and the other three team types support these teams with different activities. As a result of their role, Stream-Aligned Teams are closer to the needs and requirements of customers and receive feedback directly from them. The majority of teams in an organisation will be Stream-Aligned.

Enabling Team

Enabling Teams support Stream-Aligned Teams in building skills and successfully applying methods. They are made up of specialists in specific technical or product areas. These specialist teams work with the Stream-Aligned Teams, for example, in an advisory or teaching capacity. Through their work, the Stream-Aligned Teams are given free space for value-adding work.

Enabling teams see their task as, on the one hand, always being at the forefront of innovations and, on the other hand, making themselves superfluous through effective cooperation within the team and externally. For new technologies, they develop knowledge through experimentation and research. They try to anticipate and understand the needs of stream aligned teams and establish regular checkpoints with them. They always work out the need in the teams for permanent learning.

Complicated-Subsystem Team

Complicated-Subsystem Teams are responsible for the development and maintenance of parts of the applications that require a distinct specialist knowledge. This type of team also supports the Stream-Aligned Teams, namely by reducing the cognitive load. They master important systems, whose availability and further development they relieve the Stream-Aligned Teams of.

The Complicated-Subsystem Teams’ work increases the delivery speed and quality of the subsystems they support. They prioritise their work based on the requirements of the Stream-Aligned Teams and work closely with them, especially in the initial and development phases.

Platform Team

Platform Teams reduce the workload of the Stream-Aligned Teams by taking over supporting or infrastructure tasks such as monitoring or deployment. They work closely with the Stream Aligned Teams and focus strongly on usability and reliability of their supporting services.

The platform teams place great emphasis on the usability and reliability of their services. They regularly check this with internal assessments. For their services, they also use services from other Platform Teams whenever possible.

Cooperation between teams

In the interaction of individual teams, several variants of cooperation arise on the basis of the characteristics. A distinction is made here between the supporting activity – the facilitating mode -, the X-as-a-Service model and direct cooperation.

In facilitating mode, an enabling team supports and complements another team in order to meet challenges and to accelerate this team, for example, because the enabling team brings certain competences that are not otherwise available in the team. Accordingly, the enabling team is usually found working with other teams in supportive activities and only occasionally in direct collaboration.

Another common paradigm in collaboration is defined interfaces – here we are in collaboration then provisioning – it is called the X-as-a-Service model of collaboration. Through the interfaces there are clear responsibilities, especially therefore it is essential for effective collaboration in the X-as-a-Service model that the interfaces are cleanly and clearly defined. Direct collaboration helps to establish these interfaces in the beginning. Direct collaboration is otherwise mostly found in stream-aligned teams. Stream aligned teams are usually in direct collaboration with each other. Figure 3 and Table 1 show this again graphically and in overview.

Figure 3: Mode of cooperation of the 4 team types

Table 1: Comparison of the team types and the different types of cooperation

Time course of cooperation of different team types

These four team types and especially the three cooperation types form a very effective system of coordinates to describe the state an organisation is in. Furthermore, one can derive from them a constellation of goals that one considers particularly suitable for achieving the goals of autonomy and the avoidance of cognitive load. And with this, one can above all also formulate temporal progressions of these constellations.

For example, there may be a stream-aligned team A that takes responsibility for a certain value stream. This team may need support from an enabling team B (let’s say a team of Kubernetes experts) to familiarise themselves with this technology, which is new to them.

However, this relationship between the two teams must surely change over time: the dependency on Team B, which is of course very important at the beginning to fill technical gaps in Team A, must not be permanent. If this state of affairs becomes permanent, one has created obstructive dependencies between these teams that restrict autonomy on both sides. This would create all kinds of organisational distortions: Team A cannot fulfil its task without Team B, and Team B is not available to other teams. In the reading of team topologies, this means that an initially existing cooperation in facilitating mode must come to an end: Team A builds up the necessary knowledge and experience to the point where it can stand on its own feet.

Another example: Team A designs a new product together with a Complicated subsystem Team C (a team of machine learning specialists), which as such uses machine learning. First, this product must be properly understood, for which both teams work closely together: collaboration mode. However, after a while, as the technical implementation, roles, tasks and needs become clearer, these two teams need to separate from each other again, so that each can autonomously push ahead with its tasks. Thus, from a collaboration relationship, a service provider/customer relationship should gradually be found: Team C provides interfaces that Team A’s product can access without the need for active collaboration between the two teams. The goal is thus a transition to an X-as-a-service model of collaboration.

Conclusion

This clarity in the formulation of goals, actual and target states is the great benefit of such a coordinate system as the one in Team Topologies. It allows the visualisation, description, discussion of the state of an organisation, and its planned, purposeful change over time.

I am sure many of us have had a gut feeling for a long time that such a systematic and structured view is necessary. The progressive integration of skills and responsibilities in cross-functional teams reinforces this need. It also requires an understanding of change over time – which is also accelerating, driven by forces inside and outside the organisation. A discussion of these structures and the forces shaping them has long been needed and is finally coming into deserved focus.

Notes:

[1] Team Topologies: Organizing Business and Technology Teams for Fast Flow; ISBN: 978-1942788812
[2] Use of illustration with kind permission of the authors

This article is a joint work by Dierk Soellner, Felix Kronlage-Dammers and Luca Ingianni.

Dierk Soellner has published three other posts on the t2informatik Blog:

t2informatik develops and modernises software as a service provider. Click here to learn more.