Since the publication of the book Team Topologies in September 2019, countless organizations around the world have begun to adopt Team Topologies principles for their digital operating model. In this talk, Matthew Skelton and Manuel Pais - co-authors of Team Topologies - explore some emerging patterns and trends of Team Topologies adoption. What do organizations find difficult to do? What challenges do organizations need to overcome to make the shift to a Team Topologies approach? What combinations of techniques work well? Learn how organizations are: - Using Team Topologies as a shared language across the organization - Using Team Topologies together with Domain-driven Design (DDD) for effective boundaries - Using Team Topologies with Wardley Mapping to increase situational awareness and decide how and what to build - Using the principles of Thinnest Viable Platform and Platform as a Product to help build successful modern platforms - Understand the aspects of Team Topologies that can be more challenging including: - Assessing team cognitive load - Introducing product management and agile delivery practices for infrastructure platforms and data platforms - Shifting from “compliance via manual inspection” to “compliance as code” - Increase your success with Team Topologies with these key insights from the authors of Team Topologies.
Co-Author, Team Topologies
Co-Author, Team Topologies
Hi, DevOps enterprise summit. It's great to be here. My name's Matthew Skelton.
It's nice to be back. And we are the authors of the book, Tim typologies.
So we'd like to share with you some, uh, some ideas and experience today. Let me share my screen. So here we go. This is what we're looking at in the session today. We're look at things from teens bodies that seems 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. So to begin with, uh, the things that are really working well, tins potties provides a shared language across the organization. The combination of team to parties and Wardley maps is great for strategic thinking. The combination of team topologies, domain driven design must DDD and Wardley maps is great for thinking about the evolution of technology inside an organization and the teammate BI concept from things bodies into really helping teams kind of interact and make things, work, things that are tricky.
Things 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 typology for our organization. There isn't one single correct apology. Many organizations do not have enabling teams, or they don't have enough. Uh, in, in, in kind of conversely, many organizations have too many complicated subsystems or, or components teams. And in some places we're seeing streamlined teams kind of providing as an internal service. That's an, anti-pattern some new tools and resources that we've got available. Our online learning academy, we have now got in for graphics 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 the team's priorities. Of course, we've got the case studies in the book companies like Addie does Ericsson OutSystems IBM use switched and TransUnion, and many more. Um, since the book was published, we've got many more examples on the team to party's website as a cross foot asylum gen silica, pure gym, another, uh, uh, example from usage and wealth wizards. And we've got a whole bunch of organizations that, uh, that, uh, manual and I have worked with since 2019, since the book was published, uh, banking technology, many different government departments around the world, uh, telecoms, open banking, aerospace healthcare mortgage, and so on loads of organizations are starting to adopt a news. It seems project ideas.
Let's dive into what actually works well specifically this idea of teams bodies as a shared language, providing common patterns and kind of operating constraints, and it can help an organization organization to explore the solutions search space for it, for it to kind of technology and services. And particularly this, this idea of teams bodies as a kind of clear language as well-defined concepts. This really seems to help, for example, Kathy Keating, uh, from, from, uh, north America. Uh, so thankful today for the book teams body is it gave me the, just the framework I needed to build a really clear operational growth plan. We hear this kind of thing quite often. Uh, here's a quotation from one of our, uh, 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, some of the combination of Tinder parties on Wardley maps. So Wardley mapping being the, the, the approach to, to thinking about kind of technology and business, organizational landscape, and thinking about what needs to be, um, built versus rented versus bought. And we've got a case study on our website from foot asylum, a UK based retailer, and they used a team typologies 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 combine 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 that kind of technology and software landscape should, uh, should be situated now.
And I think that it helped them to think about how they're going to evolve those and where they should, uh, where they should place them, should they build internally, should they pull from outside and so on? Um, so it, it provided the clarity of purpose around the kind of team types and what those teams should be doing, what they should be focusing on, what kind of capabilities they should have. Um, so this combination with other teams, parties and Wardley mapping has really helped them to move things forward. Uh, so a quick, thank you to Paul and Andy from, uh, for asylum, for, uh, for that the combination of team topologies domain-driven design with DDD and watery maps seems to be very, uh, gaining traction. And that's because these, these three techniques are complimentary in particular, uh, Suzanne Kaeser, uh, who does the former CTO at a, as a cloud company and has got a particular focus on kind of model as to microservices.
Transition has talked a lot about, um, the combination of domain-driven design and watering mapping, but also now talks about the addition of teams, bodies, uh, principles in there, uh, to help organizations think about their technology choices, where they're going from a strategic direction, which teams should focus on which things and for how long. So there's a great talk, which is linked on, on the slide there, uh, from Suzanne the team API is a concept. We talk about quite a bit in the team's properties book, just a quick reminder, it's a description of everything that the team does from the perspective of outside the team. So something that describes a code and artifact 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 kind of interact. So we're taking an engineering concept like API and applying it to, uh, uh, uh, human group, the team. Um, and we've got a template on our get hub repository there. So here are a couple of quotations. Uh, Joe Wright, um, said, I just read the teammate is poverty potties book, and feel quite inspired. The idea is to list services, practices and roadmaps in a central place to help navigate in your organization.
Uh, likewise Lisa Crispin, who very well known from a test protesting perspective, uh, says, I love this team. API transparency idea is 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, close ownership of software teams need to continuously define appetite tests and evolve that teammate PAI
Let's dive into some of the things that are a bit more difficult than more tricky, um, from the team's party's book. So it's worth saying that, although the ideas in teams bodies are clear and obvious to engineers, they actually quite radical for many organizations, many people outside of engineering. Uh, I'm not so familiar with some of the kinds of concepts and things. And that's part of the reason why some of the ideas are a little bit more tricky to, to, to get traction with. The first thing is assessing team content load. In other words, kind of 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 defining the 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, um, assessing team content bodies now on the ThoughtWorks technology radar. So this came out in the volume 24 in April, 2021. And the ThoughtWorks people are saying, we use the teams, parties, authors assessment, which gives you an understanding of how easy or difficult the findings of 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, what we're trying to get out about making content explicit is how well can your teams really understand the software systems they own and develop? That's what we're, 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, in our, uh, concept of, uh, of a platform 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 kind of 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 kind of 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. Uh, I have to have really good user experience. We actually have to talk to our internal colleagues to the users of our platform. These kind of, um, approaches are unfamiliar to many organizations.
We 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 cover enable a rapid flow of change that is compliant. So let's shift from permitting to kind of accelerate. So enabling is quite difficult. And look at the question to kind of 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 API is kind of enabling teams. That kind of thing.
Reporting lines on fiefdoms are always difficult to deal with. There's nothing new there. Um, some organizations though, even encourage this kind of culture of fiefdoms and mini empires, uh, you know, the worth or influence of certain leaders is, 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 kind of power dynamics. However, what teams apologies is doing is merely highlighting the need for this kind of change. It's not, it's not fundamentally kind of difficult in itself. It's, it's just highlighting the fact that, that the, these power structures 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 of heaters less important than the flow of change and the ability to respond to new business or, or environmental kind of challenges think about using the kind of flow metrics and the four key metrics from the SRA book. And so on. You use these metrics as ways to provide different incentives in the organization.
Thank you, Matthew. So I'll continue with anti-patterns and trends that we've seen around him. Typologies.
We all start from the principles of fast flow and rapid feedback, right? So that gives us the context to understand where is an anti-pattern, um, 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 typology for their organization, for their market. And, and the answer is that there isn't one, there is, there is the, uh, an adequate typology today for the current challenges and, uh, things that need to be addressed from technology and market and customer perspective. But the key point we tried to make with Tim to pause that you need to evolve this over time. So we shouldn't expect to find the right model and just continue with that. Um, you know, uh, as a static, um, option on the organization design. So it's not a one way there, there are many paths we might take, we need to adjust continuously and find out what, where we need to go. Next.
Another anchor pattern we've seen is a lack of enabling teams, or maybe not enough. Um, and this is partially because there's not a lot of familiarity with this idea of people, especially experts in some domains to be, um, mentoring, to be teaching rather than actually executing the work, um, is also not as easy to measure the kind of return on investment if you like of this sort of teams, because they're actually helping other teams grow their capabilities, improve their metrics. And so there's not, not a direct way to, to assess them. Um, 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, um, do a bigger change of creating this 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. Um, 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 a, of a, of our system or in a certain technology responsibility to a given team. Um, and again, looking from the point of view of fast flow, then this might be an anti-pattern or not. Um, definitely we want to avoid complicated sub-system teams because of the danger of them becoming a bottleneck where many teams depend on this complicated subsystem team to do their, uh, and deliver their work. But, um, and so there should be only very exceptional cases, but like I said, we see organizations that kind of replaced 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 streamlined teams providing internal services. So, um, where's the anti-pattern here. Well, assume a line team should have very clear primary customers. Who are we serving? Um, usually these are customers outside the organization, or we might be talking about, uh, you know, citizen services in, in government agencies, for example, but, uh, streamline teams should have a very clear primary customer that they're dealing with. But often there is a 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. Um, and so instead of that, we should look at, okay, can we move this data services into a sort of platform where we have, uh, platform teams dedicated so that they provide a better service and also helps them align teams really focused on their customers because we often see a conflict of priorities where we want to help work on our end customer's needs, but we also want to provide a service internally. So we should avoid this sort of, um, anti-pattern.
And finally, the last section, uh, there are some exciting new tools and resources that we're making available. Um, first we have our team departures academy online. So these are on demand self-paced training. Um, part of the reason why we, for us, this is exciting is this allows for example, organizations to quickly, um, share that, that now 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, uh, quite well received. So this is getting started and Kim typologies in a nutshell. So these are very helpful, um, 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, you know, why are we looking at this, uh, ideas from team typologies? What are they going to help us with? We have some more guidance around our M shapes and how to create diagrams. So one of the things we noticed is people often didn't realize there's a 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, um, basically ideation to, you know, live systems and deploying changes in production. And so the diagrams should reflect that and the teams, um, in the diagram should reflect that
We have set of shapes that people can use. So we have, um, if you look at shapes starting to Polish it up com we have support for different tools like Miro boards for, 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, um, so that we make it easier for, you know, uh, people with using different tools to just, um, use the diagrams, create new diagrams and discuss, um, inside your organization, what is the best approach for us to evolve?
As we, as usual, we have a good number of resources on our website, and as well as all the tools, these are essentially GitHub repositories for templates, like for the team API, um, assessments for cognitive load, um, 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, um, someone who has background in both psychology, as well as organizational organizational design. So we think that that mix is really going to help us, um, improve the already existing assessment and really help organizations to 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, uh, for people who are interested in partnering and organizations, and we're getting to the end so very quickly, um, recap on what we saw today, uh, with we saw some of the things that work well around him to policies since the book was published, this idea of having a shared language, um, some people even call it a domain specific language for organization design.
Um, the combination of team topologies with domain-driven design with Wardley mapping, uh, is quite powerful and also some specific concepts from the book like the team API have, have been quite well received. Some things are tricky just because of the nature of, you know, organizations and what has to change. And as well as, uh, what we mentioned that kind of, um, 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, um, compliance as code, and generally moving away from compliance as a, as a kind of a blocking dependency for teams, uh, reporting lines and systems that we have to deal with and, and, um, sort out, you know, what needs to change in order to promote fast flow.
We saw a number of anti-patterns and trends that are, uh, we're seeing, you know, expecting to find the exact or the correct topology at the given moment in time. Uh, while the best we can do is have a, um, reasonably adequate topology, but expect it to evolve. Um, very frequently we saw that we need more kind of, um, 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. Um, and on the other hand, we see too many complicated subsystem teams, uh, where this should be really an exception for very specific and niche situations, streamer teams providing internal services, which makes it difficult to focus on their primary customer, which should be a, usually a customer outside your organization.
We saw a number of new tools and resources we're making available like the academy infographics, diagramming shapes. Um, we're working on expanding cognitive load assessment, uh, with more structure, with more kind of a way to, to follow up over time. Uh, and we started partner program. So this is the book again. Um, we received a lot of praise and has done quite well, and we're very happy that the book has been helping many organizations, um, get started in thinking in a more kind of modern dynamic way around how we organize ourselves for modern software delivery. And we will, um, if you're interested to keep up with news and tips, just, uh, look it up. You can sign firstname.lastname@example.org and we're always open to feedback. Let us know what has worked for you. That will be great. What has been difficult to implement in your organization? That would be also super interesting. Um, 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 the session, and we're happy to discuss in the slack on the ask me anything session.
Thanks everyone. Bye-bye.