Matthew Skelton

Hi, DevOps Enterprise Summit. It's great to be here. My name's Matthew Skelton.

Manuel Pais

I'm Manuel Pais. It's nice to be back.

Matthew Skelton

And we are the authors of the book, "Team Topologies." So we'd like to share with you some ideas and experience today. Let me share my screen.

So here we go. This is what we'll look at in the session today. We'll look at things from Team Topologies that seem to be working well for organizations around the world. There are some things that are a little bit tricky, a little bit difficult. There are some anti-patterns and trends. And finally, we'll look at some new tools and resources.

To begin with, the things that are really working well: Team Topologies provides a shared language across the organization. The combination of Team Topologies and Wardley maps is great for strategic thinking. The combination of Team Topologies, domain-driven design, that's DDD, and Wardley maps is great for thinking about the evolution of technology inside an organization. And the Team API concept from Team Topologies seems to be really helping teams interact and make things work.

Things that are tricky, things that are difficult: assessing team cognitive load; applying product management techniques for platforms; getting to the point where we've got compliance as code for things like security and financial audit and so on; and also reporting lines and fiefdoms in organizations are always difficult to work with.

Some anti-patterns that we're seeing emerge: organizations looking for the correct topology for our organization. There isn't one single correct topology. Many organizations do not have enabling teams, or don't have enough. And conversely, many organizations have too many complicated subsystems or component teams. And in some places, we're seeing stream-aligned teams providing an internal service. That's an anti-pattern.

Some new tools and resources that we've got available: our online learning academy. We've now got infographics and diagramming shapes online, freely available to use and download. We're starting to expand our cognitive load assessment. And finally, we've got a partner program up and running.

So let's just have a quick look first, a recap about who's using Team Topologies. Well, of course, we've got the case studies in the book, companies like Adidas, Ericsson, OutSystems, IBM, USwitch, and TransUnion, and many more. Since the book was published, we've got many more examples on the Team Topologies website. So Cazoo, Footasylum, Genshin Impact, PureGym, another example from USwitch, and Wealth Wizards. And we've got a whole bunch of organizations that Manuel and I have worked with since 2019, since the book was published: banking, technology, many different government departments around the world, telecoms, open banking, aerospace, healthcare, mortgage, and so on. Loads of organizations are starting to adopt and use Team Topologies ideas.

So let's dive into what actually works well. Specifically, this idea of Team Topologies as a shared language, providing common patterns and operating constraints. And it can help an organization to explore the solution search space for its technology and services. And particularly this idea of Team Topologies as a kind of clear language with well-defined concepts. This really seems to help.

For example, Kathy Keating from North America: "So thankful today for the book Team Topologies. It gave me just the framework I needed to build a really clear operational growth plan." We hear this kind of thing quite often.

Here's a quotation from one of our large government clients: "Thank you again for the workshop in January. The long-term effect has been remarkable. It has helped us to agree on a common vocabulary for describing teams and has been adopted as a natural successor of Accelerate. Thank you." So Accelerate being the book published in 2018 by IT Revolution, of course.

Let's have a look at the combination of Team Topologies and Wardley maps. So Wardley mapping being the approach to thinking about technology and business organizational landscape and thinking about what needs to be built versus rented versus bought. And we've got a case study on our website from Footasylum, a UK-based retailer, and they used Team Topologies to help identify some boundaries and think about their business domain and what things should sit in the platform and so on.

But crucially, they combined this with Wardley mapping to help them think: well, what things should we expect to build ourselves? What things should we expect to consume as a service? And thinking about how different aspects of their technology and software landscape should be situated now. And it helped them to think about how they're going to evolve those and where they should place them. Should they build internally? Should they pull from outside? And so on.

So it provided the clarity of purpose around the team types and what those teams should be doing, what they should be focusing on, what kind of capabilities they should have. So this combination of Team Topologies and Wardley mapping has really helped them to move things forward. So a quick thank you to Paul and Andy from Footasylum for that.

The combination of Team Topologies, domain-driven design, that's DDD, and Wardley maps seems to be really gaining traction. And that's because these three techniques are complementary. In particular, Susanne Kaiser, who's the former CTO at a cloud company and has got a particular focus on monolith-to-microservices transition, has talked a lot about the combination of domain-driven design and Wardley mapping, but also now talks about the addition of Team Topologies principles in there to help organizations think about their technology choices, where they're going from a strategic direction, which team should focus on which things, and for how long. So there's a great talk, which is linked on the slide there, from Susanne.

The Team API is a concept we talk about quite a bit in the Team Topologies book. Just a quick reminder: it's a description of everything that the team does from the perspective of outside the team. So it's something that describes the code and artifacts provided by the team, how they work, practices, principles, communication channels, and what their current and next focus is to help other groups in the organization interact.

So we're taking an engineering concept like API and applying it to a human group, the team. And we've got a template on our GitHub repository there. So here are a couple of quotations. Joe Wright said, "I just read the Team API as part of the Team Topologies book and feel quite inspired. The idea is to list services, practices, and roadmaps in a central place to help navigate in your organization." Likewise, Lisa Crispin, who's very well known from a software testing perspective, says, "I love this Team API transparency idea. It's definitely even more important now that we're all remote." So the Team API aspect helps with remote-first software development.

As we say in the book: for effective team-first ownership of software, teams need to continuously define, advertise, test, and evolve their Team API.

Let's dive into some of the things that are a bit more difficult, a bit more tricky, from the Team Topologies book. So it's worth saying that although the ideas in Team Topologies are clear and obvious to engineers, they're actually quite radical for many organizations. Many people outside of engineering are not so familiar with some of the concepts and things. And that's part of the reason why some of the ideas are a little bit more tricky to get traction with.

The first thing is assessing team cognitive load. In other words, how confident or anxious are you about the systems that you build and run? We should say this is a very new research area. Applying cognitive load to a group is very new. Even John Sweller, the person who first defined cognitive load in this context back in 1988, only in 2018, so 30 years after his initial research, did he publish a paper applying cognitive load to a group context.

Interestingly, though, assessing team cognitive load is now on the ThoughtWorks Technology Radar. So this came out in volume 24 in April 2021. The ThoughtWorks people there saying, "We used the Team Topologies authors' assessment, which gives you an understanding of how easy or difficult the teams find it to build, test, and maintain their services. By measuring team cognitive load, we can better advise our clients on how to change their team structure and evolve their interactions." So this is something which ThoughtWorks at least recommend that you start to try in your organization.

Conceptually, really what we're trying to get at about making cognitive load explicit is: how well can your teams really understand the software systems they own and develop? That's what we're getting at. And we'll mention a little bit more about that later on.

Another tricky thing is applying product management to internal platforms. In our concept of a platform, a platform is a curated experience for engineers who are the customers of the platform. It doesn't have to be about technology. That's not the main focus. The main focus is experience. And just like a real-world physical product, I'm free to buy it or not. I'm not forced to use it. A platform is optional to use. No team is forced to use the platform.

So how do we get adoption? We have to do internal marketing. We've got to advocate for use of the platform. We have to make it usable. We have to make it really useful, have to have really good user experience. We actually have to talk to our internal colleagues, the users of our platform. These kinds of approaches are unfamiliar to many organizations.

Getting to the point where we have compliance as code is also a mindset shift: a shift from permitting people to do things to enabling them to do it. It's a very different way of thinking. But that's what we have to do if we're going to have a rapid flow of change. We cannot have a manual inspection of changes from a compliance perspective. We have to enable a rapid flow of change that is compliant.

So this shift from permitting to accelerating or enabling is quite difficult. And the question to ask ourselves inside organizations is this: what would be needed for us to be compliant with security or finance or PII rules with multiple decoupled rapid flows of change? And the answer lies somewhere in this space of self-service APIs, enabling teams, that kind of thing.

Reporting lines and fiefdoms are always difficult to deal with. There's nothing new there. Some organizations, they'll even encourage this culture of fiefdoms and mini-empires. The worth or influence of certain leaders is often based on how many people report to them. So moving from this kind of functionally oriented organization to one based on a flow of business change can be a real challenge to the existing power dynamics.

However, what Team Topologies is doing is merely highlighting the need for this kind of change. It's not fundamentally difficult in itself. It's just highlighting the fact that these power structures exist, and that if we're going to be really effective in the 21st century of building and running software systems, we need to address that.

So try and find ways to make the reporting lines and fiefdoms less important than the flow of change and the ability to respond to new business or environmental challenges. Think about using the flow metrics and the four key metrics from the Accelerate book and so on. Use these metrics as ways to provide different incentives in the organization.

Manuel Pais

Thank you, Matthew. So I'll continue with anti-patterns and trends that we've seen around Team Topologies. So we always start from the principles of fast flow and rapid feedback, right? So that gives us the context to understand where an anti-pattern is lying, because that means it's not conducive to faster flow or is slowing us down.

One of the anti-patterns we found is organizations looking for the correct or the best topology for their organization, for their market. And the answer is that there isn't one. There is an adequate topology today for the current challenges and things that need to be addressed from technology and market and customer perspective. But the key point we try to make with Team Topologies is that you need to evolve this over time. So we shouldn't expect to find the right model and just continue with that as a static option on our organization design. So it's not a one-way. There are many paths we might take. We need to adjust continuously and find out where we need to go next.

Another anti-pattern we've seen is a lack of enabling teams, or maybe not enough. And this is partially because there's not a lot of familiarity with this idea of people, especially experts in some domains, mentoring, teaching, rather than actually executing the work. It's also not as easy to measure the kind of return on investment, if you like, of these sorts of teams, because they're actually helping other teams grow their capabilities, improve their metrics, and so there's not a direct way to assess them. And so many organizations kind of refrain from this. But there are ways in which we might start doing some enabling work, even if we don't do a bigger change of creating these enabling teams, right? So we might look for some experts that can help us make this more familiar.

Sometimes we see too many complicated subsystem teams. I think that's partially because complicated subsystem teams are closest, in some ways, to more traditional component teams, where we're allocating part of our system or a certain technology responsibility to a given team. And again, looking from the point of view of fast flow, then this might be an anti-pattern or not. Definitely, we want to avoid complicated subsystem teams because of the danger of them becoming a bottleneck where many teams depend on this complicated subsystem team to do and deliver their work. And so there should be only very exceptional cases. But like I said, we see organizations that kind of replace component teams with complicated subsystem teams, and that's not the idea for fast flow. So we want to avoid the components.

We also see stream-aligned teams providing internal services. So, where's the anti-pattern here? Well, a stream-aligned team should have very clear primary customers. Who are we serving? Usually, these are end customers outside the organization, or we might be talking about citizen services in government agencies, for example. But stream-aligned teams should have a very clear primary customer that they're dealing with.

But often there is the temptation, especially teams dealing with data that's consumed, that is needed by other teams, that they also do this kind of secondary role of providing a service to other internal teams. And so instead of that, we should look at: okay, can we move these data services into a sort of platform, where we have platform teams dedicated so that they provide a better service and also help stream-aligned teams really focus on their end customers? Because we often see conflicts of priorities where we want to help work on our end customers' needs, but we also want to provide a service internally. So we should avoid this sort of anti-pattern.

And finally, the last section: there are some exciting new tools and resources that we're making available. First, we have our Team Topologies Academy online. So these are on-demand, self-paced training. Part of the reason why for us this is exciting is this allows, for example, organizations to quickly share that vocabulary that we mentioned in the beginning, shared learning and shared vocabulary across the whole organization. So it can be an accelerator for learning in large organizations.

We also recently published a couple of infographics that were quite well received. So this is Getting Started and Team Topologies in a Nutshell. So these are very helpful, not just to understand kind of the core ideas, but also to communicate, again, with other people in your organization or outside the organization in terms of why are we looking at these ideas from Team Topologies? What are they going to help us with?

We have some more guidance around our shapes and how to create diagrams. So one of the things we noticed is people often didn't realize there's an implicit flow of change in the diagrams in the book. So from left to right, this is the flow of change where we're going from basically ideation to live systems and deploying changes in production. And so the diagrams should reflect that, and the teams in the diagram should reflect that.

We have a set of shapes that people can use. If you look at shapes.teamtopologies.com, we have support for different tools like Miro boards, for example, and other tools as well. So you have the native shapes in there. So they're as similar as possible to the book, but with some small differences, so that we make it easier for people using different tools to just use the diagrams, create new diagrams, and discuss inside the organization what is the best approach for us to evolve.

As usual, we have a good number of resources on our website, as well as all the tools. These are essentially GitHub repositories for templates, like for the Team API, assessments for cognitive load, and other techniques.

We're really excited. We just started this new initiative where we're going to dig into more of the team cognitive load assessment aspects. We're collaborating with someone who has background in both psychology as well as organizational design. So we think that mix is really going to help us improve the already existing assessment and really help organizations look at cognitive load over time and effectively understand if whatever measures we took to reduce cognitive load or manage cognitive load are being effective or not over time. So that should come up later in 2021.

We are starting a partner program as well for people who are interested in partnering and organizations. And we're getting to the end, so very quickly recap on what we saw today.

We saw some of the things that work well around Team Topologies since the book was published: this idea of having a shared language. Some people even call it a domain-specific language for organization design. The combination of Team Topologies with domain-driven design, with Wardley Mapping, is quite powerful. And also some specific concepts from the book, like the Team API, have been quite well received.

Some things are tricky just because of the nature of organizations and what has to change, as well as what we mentioned, the nature of team cognitive load, which is a new area that's being developed. But then other aspects like focus on product management for platforms as well, compliance as code, and generally moving away from compliance as a blocking dependency for teams, reporting lines and systems that we have to deal with and sort out what needs to change in order to promote fast flow.

We saw a number of anti-patterns and trends that we're seeing: expecting to find the exact or the correct topology at the given moment in time, while the best we can do is have a reasonably adequate topology but expect it to evolve very frequently. We saw that we need more enabling teams. We need more familiarity and understanding why these teams are important, and sometimes that only happens when we actually start them in the organization, we start seeing the value. And on the other hand, we see too many complicated subsystem teams, where this should be really an exception for very specific and niche situations.

Stream-aligned teams providing internal services makes it difficult to focus on their primary customer, which should usually be an end customer outside the organization. We saw a number of new tools and resources we're making available, like the academy, infographics, diagramming shapes. We're working on expanding cognitive load assessment with more structure, with more way to follow up over time, and we started a partner program.

So this is the book again. We received a lot of praise, and it has done quite well. We're very happy that the book has been helping many organizations get started in thinking in a more modern, dynamic way around how we organize ourselves for modern software delivery.

And if you're interested to keep up with news and tips, just look it up. You can sign up at teamtopologies.com. And we're always open to feedback. Let us know what has worked for you; that would be great. What has been difficult to implement in your organization? That would be also super interesting. And in general, we're available on social media, Twitter, LinkedIn, et cetera.

That's it. Thank you very much. We hope you have some new learnings from this session, and we're happy to discuss in the Slack and the Ask Me Anything session.

Matthew Skelton and Manuel Pais

Thanks everyone. Bye-bye. See you soon.

Bye.