00:00:00

<silence>

00:00:13

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

00:00:18

I'm Manuel Pai. It's nice to be back. And we are the authors of the book, Tim Topologies.

00:00:24

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'll look at in the session today. We'll look at things from teams, properties 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 antipas 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, team Topologies provides a shared language across the organization. The combination of team Topologies and WARDLY Maps is great for strategic thinking. The combination of teen topologies, domain driven design as DDD and Wardly Maps is great for thinking about the evolution of technology inside an organization and the team. API concept from team quality seems to be really helping teams kind of interact, uh, and make things work.

00:01:14

Things that are tricky, things that are difficult, assessing team cognitive log, applying product management techniques for platforms, getting to the point where we've got compliance as code for things like security and financial, um, um, audit and so on. And also reporting lines and fiefdoms in organizations are always difficult to work with. Some antipas that we're seeing Emerge organizations looking for the correct topology for our, our organization. There isn't one single correct topology. Many organizations do not have enabling teams or don't have enough, uh, in, in, in kind of conversely, many organizations have too many complicated subsystems or, or component teams. And in some places, we're seeing stream aligned teams kind of providing us an internal service. That's an anti-patent. Some new tools and resources that we've got available are Online Learning Academy. We have now got infographics and diagramming shapes online, freely available to the use and download.

00:02:14

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 Teams. Apologies. Well, of course, we've got the case studies in the book, companies like Adidas, Ericsson, OutSystems, IBMU Switch, and TransUnion, and many more. Um, since the book was published, we've got many more examples on the Team Ties website. Uh, so Cross Foot Asylum, sica, pure Jim. Another, uh, uh, example from uwi and Wealth Wizard. And we've got a whole bunch of organizations that, uh, that, uh, Manuel and I have worked with since 2019, since a book was published. Um, 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 and use teen topologies ideas.

00:03:11

So let's dive into what actually works well, specifically this idea of teen topologies as a shared language, providing common patterns and kind of operating constraints. And it can help an organization, organization to explore the solution search space for it, for its kind of technology and services. And particularly this, this idea of teams bodies as a kind of clear language with well-defined concepts. This really seems to help. For example, Kathy Keating, uh, from, from, uh, north America, uh, says. So thankful today for the book team's. Apologies. 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, uh, 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, to accelerate being the book, uh, the published in 2018 by IT revolution, of course.

00:04:12

So look, uh, the combination of team topologies and WARDLY maps. So WARDLY 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, uh, 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 wardly mapping to help them think, well, what things should we expect to build ourselves? What things should we expect to consume as a service? What, and thinking about how different aspects of their kind of technology and software landscape should, uh, should, uh, be situated now and, and think they, it help 'em to think about how they're going to evolve those and where they should, uh, where they should, uh, place them.

00:05:04

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, 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 of team support award mapping has really helped 'em to, uh, move things forward. Uh, so a quick thank you to, to, uh, Paul and Andy from, uh, for asylum for, uh, for that, the combination of teams, apologies, domain driven design, that's DDD and Wardly maps seems to be really, uh, gaining traction. And that's because these, these three techniques are complimentary. In particular, uh, Suzanne Kaiser, uh, who's the former CTO at a, at a a cloud company and has got a particular focus on kind of monolith to microservices transition, has talked a lot about, um, the combination of domain-driven design and water mapping, but also now talks about the addition of team topology, uh, principles in there, uh, 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.

00:06:13

So there's a great talk, uh, 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 Apologies book. Uh, just a quick reminder, it's a description of everything that the team does from the, the perspective of outside the team. So it's, it's something that the scribes, 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 a, a, a human group, the team. Um, and we've got a template on our GitHub repository there. So here are a couple of quotations. Uh, Joe Wright, um, said, I just read the Team API is 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 navigating your organization. Uh, likewise, Lisa Crispin, who's very well known from a test, its software testing perspective, uh, 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 plus ownership of software teams need to continuously define advertised test and evolve their team. API.

00:07:42

Let's dive into some of the things that are a bit more difficult, a bit more tricky, um, from the teams parties book. So it is worth saying that although the ideas in teams parties are clear and obvious to engineers, they're actually quite radical for many organizations. Many people outside of engineering, uh, are not so familiar with some of the kind 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 cognitive 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 defined cognitive load in this cogniti back in 1988, only in 2018, so 30 years after his initial research did he publish a paper applying cognitive load to, to a, a group context.

00:08:39

Interestingly, though, um, assessing team cognitive load is now on the ThoughtWorks technology radar. So this came out in, uh, volume 24, uh, in April, 2021. Um, the ThoughtWorks people there saying, we used the teams parties, authors assessment, which gives you an understanding of how easy or difficult the teams finding 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, what we're trying to get out 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, 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.

00:09:29

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, a real world physical product, I'm, 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, have to have to have really good user experience. We actually have to talk to our internal, uh, colleagues, to the users of our platform. These kind of, um, approaches are unfamiliar to many organizations.

00:10:22

We getting to the point where we have compliance as code is also a, a, 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 are going to have a rapid flow of change, we cannot have a manual inspection of changes from a compliance perspective. We have to kind of enable a rapid flow of change that is compliant. So this shift from permitting to kind of accelerating or enabling is, is quite difficult. And the, and the, 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, uh, PII rules with multiple decoupled rapid flows of change. And the answer lies somewhere in this space of self-service, APIs, kinda enabling teams, that kind of thing.

00:11:16

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 base on the flow of business change can be a real challenge to the existing kind of power dynamics. However, what Team Topologies is doing is merely highlighting the need for this kind of change. It's, 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 exist, and that if we're gonna 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 freedoms less important than the flow of change and the ability to respond to new business or, or, or environmental kind of challenges. Think about using the kind of flow metrics and the four key metrics from the Accelerate book and so on. You use these metrics as ways to in provide different incentives in the organization.

00:12:21

Thank you, Matthew. So I'll continue with anti-patterns and trends that we've seen, um, 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 is an anti-pattern, um, line, because that means it's not conducive to, to faster flow or is slowing us down.

00:12:56

One of the empty patterns we found is organizations looking for the correct or the, the best topology for their organization, for their market. Um, and the answer is that there isn't one <laugh>. There is, there is the, uh, an adequate topology 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're trying to make with team topology is 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 we need to adjust continuously and find out what, what, where we need to go next.

00:13:43

Another anti 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, it is also not as easy to measure the kind of return on investment, if you like, of these sort of teams because they're actually helping other teams grow their capabilities, improve their metrics, and so there's no not a direct, uh, way to, to assess them. Um, and so many organizations kind of, um, 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 these enabling teams, right? So we might look for some experts that can help us make this more familiar.

00:14:40

Sometimes we see too many complicated subsystem teams. Um, I think that's partially because complicated subsystem teams are closest, uh, in some ways to more traditional component teams where we're allocating part of a, of, um, of our system or, you know, a certain, um, technology responsibility to a given team. Um, and again, looking from the, the point of view of fast flow, then this might be an anti-pattern or not. Um, 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 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 replace component teams with complicated subsystem teams, and that's not the idea for fast flow. So we wanna avoid the, the components.

00:15:41

We also see streamlined teams providing internal services. So, um, where's the anti-patent here? Well, a streamline team should have very clear primary customers. Who are we serving? Um, usually these are end customers outside the organization, or we might be talking about, uh, you know, citizen and 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 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. Um, and so instead of that, we should look at, okay, can we move this data services into a sort of platform, uh, where we have, uh, platform teams dedicated so that they provide a better service and also help streamline teams really focus on their end customers? Because we often see, uh, conflicts of priorities where we wanna help, you know, work on our end customers needs, but we also wanna provide a service internally, so we should avoid this sort of, um, empty pattern.

00:16:54

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 Topologies Academy online. So these are on demands of PACE 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, uh, vocabulary that we mentioned in the beginning, shared learning and shared vocabulary across, um, the whole organization. So it can be an accelerator for, uh, learning in in large organizations. We also recently published a couple of infographics that were, uh, quite well received. So this is getting started and team topologies 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 of, you know, why are we looking at this, uh, ideas from team topologies? What are they gonna help us with? We have some more guidance around our, um, shapes and how to create diagrams. So one of the things we noticed is, uh, 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 diagrams should reflect that

00:18:29

We have a set of shapes that people can use. So we have, um, if you look@shapes.topology.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 there 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 the organization what is the best approach for us to evolve

00:19:06

As we, as usual, we have a, a good number of resources on our website, um, 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, um, this new initiative where we're gonna dig into more of the team cognitive load assessment aspects. We are collaborating with, um, someone who has background in both psychology as well as organizational de organizational design. So we think that that mix is really gonna help us, um, 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 of or not over time. So that should come up, um, later in 2021. We are starting a partner program as well, uh, for people who are, uh, interested in, in partnering and organizations,

00:20:19

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 team topologies since the book was published. This idea of, uh, having a shared language. Um, some people even call it a, a domain specific language for organization design. Um, the combination of team topologies with domain-driven design with worldly mapping, uh, is quite powerful. And also some specific, uh, 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. Um, 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, uh, 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, to deal with. And, and, um, sort out, you know, what needs to change in order to, to promote fast flow.

00:21:33

We saw a number of anti-patterns and trends that are, uh, we're seeing, you know, expecting to find the, the exact or the correct topology at a 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 are important. And sometimes that only happens when we actually, um, start them in the organization. We start seeing the value, right? Um, and on the other hand we see too many complicated of system teams, uh, where this should be really an exception for very, uh, specific and niche, uh, situations. Streamlined teams providing internal services, which makes it, um, difficult to focus on their primary customer, which should be, uh, usually an end customer outside the organization.

00:22:34

We saw a number of new tools and resources were 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, uh, 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, and tips, just uh, look it up. You can sign up@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, uh, 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 this session and we're happy to, um, discuss in the, uh, slack and the Ask Me Anything session.

00:23:52

Thanks everyone. Bye-Bye.