Anyone who works with software teams and has to implement features and deliver software knows all too well that efficiency matters. When product teams are forced to deal with time-consuming admin, valuable working hours and even days are lost and precious resources wasted. The Team Topologies approach is a great way to reduce the cognitive load. I first heard the term about a year ago. And now many in the industry are talking about it.

What is Team Topologies?

The Team Topologies approach, devised by Matthew Skelton and Manuel Pais, specifically addresses the challenge that many organizations struggle with: not getting software to the customer fast and well enough. Software teams are often under immense pressure to create value. Apart from doing their main tasks, however, they’re also busy doing dozens of other things, and so they can be slow to implement features – or their output is lower than what everyone would like.

This is where Team Topologies comes in: a simple step-by-step model that combines four fundamental types of team – team topologies – and three core team interaction modes. This allows software teams to be structured in a way that reduces their cognitive load enough to let them to focus on what really matters: creating features and value for their end customers.

Watch the video by Team Topologies to find out more.

How do you get started with Team Topologies?

Team Topologies suggests the following approach to applying its concepts. (You can view the original here.)

1. Identify what kind of teams you currently have

2. Fit technology teams to the fundamental team types:

   1. Stream-aligned: The team focuses on a single, impactful work process, such as a product, service, or single user journey.

   2. Complicated subsystem: Responsible for a part of the system that depends on specific skills and knowledge. Most team members are therefore specialists in a particular area of knowledge.

   3. Platform: The platform team develops systems and programs that are used internally in the company and that support cross-functional teams.

   4. Enabling: Helps the stream-aligned team to overcome obstacles and detects missing capabilities.

3. Limit the cognitive load for each team:

   1. Engender a culture of trust

   2. Align the team to one or more areas on an ongoing basis

   3. Limit the size of the subsystem the team works on

   4. Provide an underlying platform for the team to build upon

   5. Break apart monoliths using natural fracture planes

4. Use the “Reverse Conway” approach to help to:

   1. Drive software systems that align to flow of business change pressure

   2. Produce software systems architectures that are sustainable for the organization

   3. Constrain the search space for technical solutions

5. Identify as-is and to-be team interaction modes

6. Explicitly guide (and limit) inter-team collaboration to

   1. Drive rapid discovery and learning at points of technological, organizational, or situational learning

   2. Inform and guide the development of internal platforms and complicated subsystem components

7. Evolve team structures explicitly over time

8. Use team interactions for organizational sensing

Use case

The best way for me to explain this is by turning to a Mimacom customer use case. This customer is a car manufacturer, and we manage their digital portfolio for them. We build their online stores, take care of other issues relating to their website – in short, we look after everything concerning their digital touchpoints.

They now have a software team in place that has the important task of building a highly sophisticated technical platform, to minimize the workload of the other teams. This platform team deals with a multitude of cross-cutting issues, such as complying with regulatory demands and all technical security-related issues, as well as highly technical matters like certificate management (= handling of all digital certificates used to identify systems).

The solution built in the platform team can now be used by all other teams in the company.

This means that the individual stream-aligned teams no longer need to worry about creating certificates to secure their own application. The platform created makes life much easier for others: They simply need to order the correct certificate for their application on the platform.

So, here we have the platform team that has thought about what exactly is needed and how this will be used, and has implemented it – which 50 to 60 (!) other teams now stand to benefit from.

What are the benefits of Team Topologies?

This approach, as Team Topologies describes it, was not specifically introduced as such at this (or indeed any other) customer, nor did it entail any complex reorganization. Mimacom simply helped the customer streamline an existing organization, improve things, and make more appropriate decisions.

And Team Topologies offers even more benefits:

• Lots of freedom: The approach affords lots of freedom for design. You divide your team by team topology, but which approach you then take, or whether you choose to work with Kanban, Scrum, or SAFe® is entirely up to you.

• Added value: Effective software is essential for creating ongoing value. Team Topologies facilitates modern software delivery, thanks to optimized team interactions and better organizational design.

• Strong competitive advantage: With Team Topologies, “fast and good” are not mutually exclusive, and you become extremely competitive in the market.

• Great success factor: When teams create a lot of value in a company, deliver good output, and exude a positive work ethic, other teams soon hear about their good work and get inspired.

I’d like to emphasize in particular the last point about “teams”. Platform and product teams are happy when they can deliver. If a team is under less pressure and can focus on its main tasks, it has more fun, is more efficient, and consequently automatically improves its environment and communication with others.

Who is Team Topologies suitable for?

No one industry In theory, Team Topologies is suitable for every industry that we currently work in. In short, Team Topologies can be adopted wherever the end customer is involved in digital innovations.

Suitable for medium and large companies A technical platform can be too expensive for startups. For companies with five to six teams, however, it’s worth starting to think about building a technical platform. And for companies with ten or more teams, it’s definitely worth building one.

No platform required To use Team Topologies, you don’t need to implement a technical solution first. A Wiki page is all you need to get started! Let’s take a look again at the use case of our car manufacturer with certificate management. Of course, it’s convenient if all teams can order a certificate at the click of a mouse. To start with, though, another good solution is to add the relevant code to the Wiki page, which each team can then copy for their own use. That in itself lessens the load.

Adoption of Team Topologies

Awareness of Team Topologies first needs to be scaled out. Many may have heard of the approach but not really know exactly what it is, how it differs from other approaches, if it’s compatible with their current organization, and so on.

For me, the key to success is clearly to reduce the cognitive load for platform teams, and so give them more creation flexibility.

Start small. It’s no use rolling the approach out over 40 teams at once. Start with a pilot project and see where it goes. Good luck!

Led by Matthew Skelton and Manuel Pais, authors of the highly-acclaimed book Team Topologies (IT Revolution, 2019), the Team Topologies ecosystem of partners, practitioners, and the Learning Academy is transforming the approach to the digital operating model for organizations around the world. https://teamtopologies.com/learn