Matthew Skelton and Manuel Pais on Software Architecture, Team Topologies, and Platforms

Transcript

00:20 Daniel Bryant: Hello, and welcome to the InfoQ podcast. I'm Daniel Bryant, the News Manager here at InfoQ and Product Architect at Ambassador Labs. I recently had the pleasure of sitting down with Matthew Skelton and Manuel Pais, software delivery consultants, and coauthors of the book, Team Topologies. I've known Matthew and Manuel for quite some time now, and I've learned a lot from them. Matthew has long been discussing the pragmatic implications of Conway's Law on team design, and Manuel has led the DevOps writing team here at InfoQ for a number of years and he's covered all aspects of software delivery.

00:48 Daniel Bryant: Practically, every online conference I'm going to at the moment, whether it's focused on architecture, DevOps or the cloud, the Team Topologies book they wrote is mentioned, often alongside classics, such as Accelerate and the DevOps Handbook. I was keen to dive into the core ideas of the Team Topologies book and explore how they relate to the modern role of software architect. 

01:04 Introductions

01:04 Daniel Bryant: Hello, Matthew. Hello, Manuel. Thanks for joining me today.

01:07 Matthew Skelton: It's good to be here. Thanks.

01:08 Manuel Pais: Thanks for having us.

01:10 Daniel Bryant: Could you briefly introduce yourselves, please?

01:12 Matthew Skelton: I'm Matthew Skelton. I'm the co-author of the book Team Topologies, along with Manuel. My background is in software development. Originally, I started off building software for brain imaging machines, and then moved into other stuff around oil and gas, and then local government, and then financial services, and then other things. Now, I spend most of my time helping organizations to become more effective at building and running software.

01:33 Manuel Pais: I'm Manuel. I'm the other co-author of the book. I also have a background in computer science. I started as a developer 20 years ago. I've had build and release management roles, testing, team lead, and a lot of consulting around DevOps and continuous delivery. The book came about because we found issues around how teams are interacting. Today my role is as IT organizational consultant and trainer, as well.

01:59 Why should a software architect pay attention to the concepts discussed in Team Topologies, such as organisational design, Conway’s Law, and “team APIs”?

01:59 Daniel Bryant: Awesome, so we were talking off mic, this is the InfoQ Architecture podcast, so the typical persona is architect or tech leader. Why should someone with that kind of role in modern software pay attention to the content of the book, Team Topologies?

02:11 Matthew Skelton: That's a really great question. It comes down to this, the software architect or the systems architect of the past, who focused almost exclusively on technology, whether it's running applications, or whether it's bits of off-the-shelf equipment, or software, whatever. That focus purely on the technology is just not relevant anymore. We now know, through plenty of studies, that there's strong evidence that something like Conway's Law is actually real. Conway's Law being this mirroring of the communication structure in the organization to the likely software architecture that we're going to produce. It's not a one-to-one mapping but there is a force there, a kind socio-technical mirroring happening.

02:49 Matthew Skelton: What's interesting, if you read the original paper, written by Mel Conway in 1968, it's really rich and there's lots and lots of interesting ideas and detail in there. Effectively, the shape of the organization is a constraint on the solution search space. If our organization is set up in a particular way, we may never find a particular solution, actually, this is a strategic problem.

03:11 Matthew Skelton: That's why it's interesting from an architectural point of view. Modern architects, when we're thinking about it, if you're an architect, your job involves dealing with software. You need to know about software, you need to know about modern cloud services, and probably IOT, and things like this, big data, but you also need to know about things like Conway's Law.

03:29 Matthew Skelton: You need to be thinking about how HR is interacting with the organization. You need to think about how facilities are laying out the desks in their offices. You need to think about how the CIS admins are managing Slack or Microsoft Teams or your chat tool, because all of these things, in the associate technical context, affect architecture.

03:46 Matthew Skelton: The old architecture effectively is dead. The new architecture is very much alive. That's kind of exciting from my point of view, but it's also maybe slightly daunting. There's a lot to think about. Obviously, we cover some angles, some of those aspects in our book, Team Topologies, but this is entirely relevant for architects to be thinking about these new dynamics inside the organization.

04:05 Manuel Pais: Yeah, and I would just like to add that we still see some people who are thinking that they don't need architecture in because we have all this great cloud offerings and services, but as Matthew was saying, it's reducing the scope of what architecture is. It's true that cloud helps us offload a lot of what used to be some concerns for development teams, but there's still a lot that we need to know around how do we put together these different pieces.

04:32 Manuel Pais: Then all the way up to thinking about what Matthew was saying about the organizational architecture and how that impacts the overall system architecture. There's a lot that still needs good architecture. We still need teams to have pretty good capabilities around technical architecture as well. It's definitely something that is very needed to create efficient modern software systems, even though we might not always need an architect role per se in every team.

05:01 What is a team API? And what are the advantages and disadvantages of thinking about team APIs?

05:01 Daniel Bryant: Very nice. Now, I'm a big fan of the book, as you know. One thing I've used as a tool for architects is helping folks map their old world to this new world being pitched. I really liked the team API's description from the book. Yes, as soon as you go APIs... Everyone knows what an API is these days, right? So could we dive into it a little bit more? When you talk about team APIs in the book, how does that relate to say, software APIs? And what's the advantages and disadvantages of thinking about team APIs?

05:29 Matthew Skelton: API means application programming interface. It's a description of how a bit of software like a library, or a component, or a service, is supposed to be interacted with, how something else calls it, and the shape of the data and the shape of the response and so on. We took this very technical term deliberately because it would resonate with engineers and people who write code. We're inspired or guided by Conway's Law, where we're thinking about this technical mirroring between the organization shape and then the likely system architecture. If you have software APIs, then why wouldn't you have an interface into the team? Because you're likely to have a mirroring, so effectively the team APIs is a definition of the interface into a team.

06:07 Matthew Skelton: It covers a whole bunch of stuff around what the team's working on? What they're responsible for? How you can contact them? Which other teams they're expecting to talk to over the coming weeks? Which teams they're currently talking to right now in order to achieve something? It seems to be really useful, doesn't it Manuel? These various organizations you've started to adopt this, and this helping them think about the responsibilities for different teams.

06:29 Manuel Pais: We've had several people telling us it's almost a change in perspective because many teams already have a team agreement or team charter, which makes a lot of sense for the team internally to agree on what is our purpose?

06:41 Manuel Pais: How do we like to work? What practices we want to adopt? At least to have this kind of North star or, goals for the team, which is all super valuable, but the team API is then saying, okay, let's flip this to some extent and think about the teams around this.

06:57 Manuel Pais: The teams that need to interact with us, just like a service that is external needs to interact, perhaps with the services that we maintain. It helps people think about the same information to some extent, but how do we make this now clear to other teams? And sometimes there's missing information in those team agreements because it's implicit knowledge inside the team that teams outside don't have.

07:22 Manuel Pais: That is very helpful, especially today in this COVID pandemic aspect, because most teams work and most people working from home. In many organizations makes it even more difficult to understand when and how should we contact other teams. Where is the information about their systems? When are they going to release some feature or do some piece of work. We found that many organizations found it useful to have their teams creating this team APIs, it's making them visible to the whole organization. We reduce the load on understanding the communication patterns, especially in distributed, remote, working.

08:02 Could you explain how “cognitive load” impacts software architects and engineers?

08:02 Daniel Bryant: You mentioned something there that I've heard you both talk about it. I've learned a lot from you both about cognitive load. I think that's the thing that... When I heard of it and when I've talked to other people about it, they all including me, recognize it straight away, cognitive load.

08:14 Daniel Bryant: With these big systems we're building now, even the long list, it's really hard to understand all the technology. I'm guessing what I'm hearing you both saying is yeah, sure. It's hard to understand technology, but it's hard to understand the social, people aspect of it in the same way.

08:27 Manuel Pais: Yeah. I would say many things contribute to cognitive load. The amount of things, different aspects that teams have to know about to be able to deliver their work. Without going into a lot of detail, cause you can distinguish different types of cognitive load, but there's definitely an aspect of... We have to know about technology. We have to know about practices and we have to know about communication with other teams as well. We have to know about our internal organization processes as well.

08:55 Manuel Pais: There's a lot that these teams need to know and often what's left out or they don't have enough capacities to actually grow their understanding of the actual business and the customers that they're trying to serve. You get this teams who are almost kind of order-taking teams where there's a backlog that someone else created and prioritize for them to deliver, but not because they don't want to, but they just don't have the capacity to actually dig into. Who are our customers? What are they trying to do? What problems are we trying to solve?

09:25 Manuel Pais: The book, we talk a lot about fundamental typologies, interactions, et cetera. It's all really focused on reducing cognitive loads on teams so that they can be more autonomous, which is something that we hear a lot from Agile and devOps to some extent, but we don't always actually have good techniques and practical approaches to reduce that cognitive load, so teams can actually be more autonomous and have a strong sense of the business needs.

09:54 Matthew Skelton: It's a case of trying to make teams autonomous and decoupled, so loose coupling between teams.

10:00 Manuel Pais: We go back to Conway’s Law as well.

10:01 Optimise for fast flow of change

10:01 Matthew Skelton: Exactly, Conways’ Law We want a fast flow of change. That's what we need. That's literally on the front cover of the book, organizing business and technology teams for fast flow. That's a subtitle. That's our starting point. If you want a fast flow of change, you need a limit on the cognitive load that a team is going to find itself with for a particular system, otherwise you won't be able to deliver rapidly.

10:20 Matthew Skelton: If you want a fast flow change, you need to have a end to end ownership that you need no handoffs. Sometimes it's called you build it, you run it. Some people call them devOps teams, whatever you build this thing and you run it production and you get that very fast feedback coming back from the live environment.

10:32 Matthew Skelton: That was that kind of fundamental starting point.

10:34 Manuel Pais: Of course, what we've got here from an architecture point of view is if we've got a focus on making sure teams are substantially independent and decoupled, then guess what, our architecture is going to flow from that. We've got a nice loosely coupled architecture, with well-defined services and so on.

10:49 Matthew Skelton: That again, that's why it's interesting from an architect perspective. There's plenty of examples of companies who have really been doing these kinds of approaches for many years, that the classic coordinator is Amazon web services, AWS, and whether or not there's a famous memo, which might be kind of apocryphal or it might just be made up. It doesn't matter whether it's made up or not, because the principles in this memo where it talks about each team must communicate only through standardized interfaces and there'll be no other kind of entertained communication allowed, and all the interfaces must be externalized pulling all this kind of thing.

11:18 Matthew Skelton: Those principles, if you look at them through a different lens, what they're trying to do is make sure we've got team autonomy, team independence, loose coupling between these different teams and therefore the architecture will flow from that. That was the insight from Jeff PCIs back in, whenever it was 2002, and clearly that was... That's helped AWS to scale this kind of loose coupling. If you listen to the architects who really get this stuff... I've seen lots of software, lots of different contexts. They're always talking about loose coupling, asynchronous, message driven systems.

11:44 Matthew Skelton: These systems have existed since the 1960s. It's not like we're inventing them, they've been proven for decades. Let's have our teams in the organization loosely coupled, substantially independent, and with well-defined communication between them ideally asynchronous.

11:59 Decoupling architecture and workflow

11:59 Matthew Skelton: It means that some of these big frameworks, scaled agile frameworks, they might help some organizations to get out of a swamp to get onto dry land, but ultimately a lot of them focus on continued synchronization every six weeks-

12:13 Daniel Bryant: Release trains.

12:15 Matthew Skelton: Released trains, whatever it's called. There's lots of different versions, but lots of synchronization between multiple teams. But that means that these teams are not loosely coupled and therefore the architecture is likely not to be loosely coupled. You've got to kind of local maximum there, which is difficult to get away from.

12:27 Matthew Skelton: Our focus in the teams bodies book is on how the teams interact, the team API being a kind of a key aspect of defining how... It's a thinking tool, really. It's not something you define and then walk away from it. It's a way of thinking. It's a way of discussing. It's a way of having conversation.

12:41 Matthew Skelton: We're focused on how to make sure that teams are loosely coupled and independent and fast flow and therefore the systems that we're building. It should be better to answer producing systems that have similar properties.

12:52 Matthew Skelton: The caveat there perhaps is that like in the example of AWS, where they made this very strict separation between teams and therefore allowing different services to evolve independently much more quickly, but also because they correctly identified, or they probably had a good idea of what those independent services are, which it's something else that I see still a lot.

13:14 Manuel Pais: If you're on Twitter on a regular basis and then see people complaining about even things like microservices. I usually say, microservices is step 10, not step one of identifying what are your independent streams of work? Because you might have a great microservice architecture where in theory each team is responsible for a nice independent microservice with their own data store and everything.

13:39 Manuel Pais: Then when you look at the business needs the offerings or features that you need to deliver, or even user journeys... When you need to deliver those, then you look at the architecture and you need to involve multiple teams, four or five, six, and teams to actually deliver that thing, which is what brings you business value.

13:58 Manuel Pais: Before we actually go into microservices, it's not purely technical decisions. They need to be aligned with independent kind of streams of business value streams. That's something that's often missing as well. Conway's law helps us, but it will also need to... Whether we're applying ideas from domain driven design or and github.com/teamtopologies. We have a number of tools and techniques and templates. One of them is called Independent Service-Heuristics. We joke that it's like DDD light, cause it's just a simpler set of questions that can help you start thinking about what are really independent services that we can then align with different teams.

14:39 Manuel Pais: Therefore we talk about stream aligned teams in the book. Regardless of how you're doing it, whether you know, a simple tool like that, or more involved in mentoring design, which is great it just requires more understanding. We need to start there or have that as one of the key points of how we're thinking also about architecture and teams together, for fast flow, for independent streams of work. Otherwise, if we focus first on, let's do microservices because it's supposedly gives us more independence and faster flow, but we haven't thought about the actual independent value streams for our business, then we get to a problem there where we haven't really achieved faster flow.

15:21 Could you discuss the four types of team topologies: stream-aligned team, enabling team, complicated subsystem team, and platform team?

15:21 Daniel Bryant: Definitely be nice to come back and touch on some of the boundaries you mentioned. That's super interesting, before we do, I'm really keen to dive into the teams that you both mentioned, because I really enjoyed seeing the presentations, and it resonates with a lot of folks, we got a lot of nods in the audience when you present the four fundamental team topologies. You've already mentioned stream aligned teams, the Manuel, will you both dive into the four types of topologies.

15:42 Matthew Skelton: Sure. A starting point, like I said before is a fast flow change. If you want a fast flow change we want no handovers from wanting to another. Instead of having separate dev team, QA team, release team, ops team, just to have one team that responsible for build and release and runtime. You build it, you run it. That kind of model has been in place for quite a few years in lots of different organizations, and we didn't invent it.

16:04 Matthew Skelton: What we did is put some principles around it and some additional context and justification starting with this fast flow of change, but we also need rapid feedback. We need good telemetry from digital telemetry from production and the live systems, and also feedback from our customers. We need to get close to the user of the system. There are other techniques for getting that kind of feedback.

16:23 Matthew Skelton: If you have a team that is responsible for all that stuff over time, they will have to deal with more and more and more things. They'll have to do a security, governance, audit, infrastructure, logging, metric, the whole works, right? Then they start intermitted things and they started... They're having a mobile app, and at some point the cognitive load on that team gets too high. Then you can't do enough of that. You can't keep growing teams. A team as a high performing unit is limited to... It depends, but something like eight people, nine people in some organizations with much higher trust, you can get up to about 15, but even then that's kind of like two teams paired together. There's a limit on the team side basically. Therefore there's a limit on the cognitive load. Yes, you can hire more experienced people but you still get to a limit.

17:05 Matthew Skelton: At some point you have to say, what's the most important things that this team needs to be focusing on? And what can be offloaded somewhere else? That's where these three other team types come from, which are the enabling team, the complicated subsystem team, and the platform team. Their primary purpose effectively, of these other three team types, is to reduce the cognitive load on the stream aligned teams.

17:26 Matthew Skelton: That's a very different way of thinking about the purpose of these kinds of teams, because it helps us to have a very honest conversation about where we need that kind of investment, where we need that focus. It means that for example, when we talk about platform, instead of going ahead and building a great big, massive technology platform, our focus is effectively... Our starting point is we are there to reduce the cognitive load on the stream aligned are using your platform and that's kind of it.

17:50 Matthew Skelton: There isn't really anything else that you're doing. Isn't really anything else that you should be doing. That's always the focus and it seems people keep coming back to this and keep telling us this is a really, really useful framing or way of thinking about these other teams other kind of bits of technology in the organization. It keeps us much more honest and nimble. Much more lean in that sense about how much other stuff we need to build and where we have other kind of teams in place.

18:13 Manuel Pais: With platforms in particular, it's often hard for people to move away from the kind of traditional idea of platform as well. This is where we centralize shared services. When there's this difficulty to think about focusing on what are the needs of our internal customers, versus what are the things that are shared, and therefore we're going to build them in this platform.

18:36 Manuel Pais: This type of modern platform is much more focused on... I like to call it has to be platform as a product. That means we're looking at our internal customers and it's not so much about what should be where should this be in platform or not. Actually, the answer as Matthew is saying, comes from... Does this help reduce cognitive load? At least one stream-aligned team usually will be then applicable for multiple teams, but you could possibly even have a platform service just helping one team offload some of the cognitive load they have today around parts of the system more of the tech stack actually, which are not really very meaningful in terms of adding value to the service, to the end customers. There's a quote I like a lot from Paul Inglis, who is CTO at you Uswitch, and they used to have almost hundred percent autonomous teams without any platform.

19:26 Manuel Pais: And he said, they got to a point where each of the teams had to make so many decisions around infrastructure, and services, either kind of low level part of the stack. That they realized we need to have some sort of platform to help these teams offload, because what he was saying is, that we're spending a lot of time making low level decisions, which have low value for the business.

19:51 Manuel Pais: Because there's that limit on our capacity as a team that has a limited size, then what are the things that we can offload? The modern and platform means that we start with the needs of the teams, which is the same as you do for a product, right? You don't start a startup where you're not looking at what are the needs you're trying to address, or if you do, and you start just building stuff a high chance, they won't succeed.

20:14 What are the benefits of creating a “Thinnest Viable Platform”?

20:14 Matthew Skelton: It reminds me of, I saw a talk, I think it was Matthew, maybe both of you. You were talking about the thinnest viable platform, kinda like the MVP -- minimum viable product -- I really love that concept because I've definitely seen teams when I was a consultant that built out amazing kind of mini Amazon's, mini clouds without even talking to the developers. I'm like, no wonder they're not using it. You never talk to your customer.

20:37 Matthew Skelton: The thinnest platform you can build is a Wiki page with like a list of four services that Amazon or Azure provide, or Google cloud provider, and someone has curated an experience for the engineers who are using this, and they say, right, if you use these for services like this, with this kind of configuration and this way, it'll be really easy for you to build on AWS. That is a platform. Just because you haven't built any technology yourselves, you've still curated something.

21:01 Matthew Skelton: You still reduce the cognitive load on these teams who are going to use it and that's the ultimate goal. Better for the organization because there's less extra code, it's quicker, the less to go wrong. It's more nimble and so on. Everyone wins basically, if you take this thinnest platform approach.

21:16 Manuel Pais: There's also sometimes misunderstanding that a good platform means we're building similar services to what already exists. That's not what we're saying, we're saying leverage as much as you can of your third parties and actually healthy dynamics that you are competing with those third parties. The teams can have that option like, okay, am I going to use the AWS service? And on top of that, I have to perhaps write all this code and understand all the configuration, et cetera. Or do I have an internal platform service, which actually makes that much easier for me. What they're focusing on is almost like a translation that AWS can not do. AWS doesn't know your specific internal needs for your teams, but they are your customers and you are working the same organization. It should be much easier to understand what is a useful abstraction here, or a useful wrapper here, so that I'm not rebuilding the service. I'm using a third party service, but on top of that, I'm making it much easier to consume for internal teams, because I'm abstracting the way details that they don't need to know.

22:20 Manuel Pais: They can, if they think they need to, and they can dig into it, but here's a more competitive, between quotes, service internally which means you have to know a lot less about that specific car provider service, how it works.

22:34 Matthew Skelton: That's actually a really important role for the modern architect. Particularly if you're combine principles with something like Wardley mapping. You're thinking about the strategic landscape, you're thinking about how things get commoditized and whether you need a custom build, or whether you can just consume as a product. Without actually... There's an organization based in the UK called Footasylum, they sell clothing. They actually use a combination of platform thinking, and flow thinking, from team to parties with Wardley mapping. We've actually got a case on our website from them. It was just amazing to see it come out. We hadn't been working with them at all, but they gone ahead and done this.

23:05 Matthew Skelton: And it really helped them to work out what they needed to build internally in their platform. They save loads of effort cause they realized they didn't need to build a whole lot of stuff. They used to Wardley map your principles and then map that onto the team typologies principles and said, our platform can be much more than we thought it needed to be. They saves a lot of effort and they can move more quickly. That's a great focus for kind of architect, minds and activity is around that kind of strategic part of working out what's the minimum amount of platform, with a minimum amount of stuff, that we should actually be building here. Not the biggest amount, the smallest amount keeping it nimble.

23:38 What skills should the modern software architect focus on developing?

23:38 Matthew Skelton: That's what I'm hearing from both of you is there's a mind shift here for the modern architect. Yeah. I've definitely seen this at conferences I've been to, or when I can go to conferences, folks saying that you need to think more about the human factor, like you're a technical leader, not just the boxes and lines type person that maybe we saw. Maybe I did to be fair 10, 20 years ago. I'm thinking that the mental models, the opportunities for software architects now, is probably quite vast. You need to focus on where you can have the most value.

24:03 Matthew Skelton: Yeah. And then potentially be able to skip from one kind of zoom level to another. Sometimes you're working at the strategic products, Wardley mapping type level. Other times you're working at the team level between multiple teams, sometimes you might be just working at the value stream level.

24:17 Matthew Skelton: There's a far more opportunities than there perhaps were in the past. That's probably because software systems now involve more people and therefore the social aspect becomes more important and also kind of more complicated, fundamentally, potentially even complex in terms of how they work. It's not surprising, there's additional dimensions that have come in.

24:32 Manuel Pais: We're also seeing, as we talk to different organizations that are adopting some of the ideas in team topologies or during the online trainings that we run... We often see people start having this question, if we want to think about the different types of teams and what are the platform services that we need? Or what are the enabling teams that we need so that we can have stream aligned teams or product teams go faster?

24:57 Manuel Pais: Then you also start thinking about who is looking into this? who is looking at what is missing and what lies in between teams, in between the team boundaries? That could perhaps be the role of a system architect or enterprise architect. As you were saying, very well, Daniel, you need to have this kind of understanding of teams of commerce law.

25:18 Manuel Pais: Also, it's a matter of having the responsibility and having the authority, or the possibility to make those changes at the team level. If that's what you need. If you realize, well, we need an enabling team which is going to help some of the teams understand better how to do monitoring. How to do telemetry for their products or services. There's an opportunity there as well.

25:41 Manuel Pais: What you usually say is that whoever in the organization makes decisions about organizational structures, team structures and composition, needs to work together with whoever makes decision about the software systems and their architecture. Whether, that's the same person or team then great, or if you need to bring together HR people and software architects together to make those decisions and think about what they need that also works.

26:06 Manuel Pais: Depends from organization to organization, but clearly there's a kind of brother view of what architecture is not just systems, but the architecture of the teams essentially.

26:16 Matthew Skelton: Really crucially we're in a situation in a kind of business situation where things are changing very rapidly and that's no longer going to change. We've got a really rapid expansion and acceleration of how the technology is playing out, cloud IOT. Apparently now you can play doom on a pregnancy test device. It's just amazing, right? The amount of compute power, which you just throw away. That's just absolutely incredible because the speed of technology means that the architects need to be thinking about, how can we set things up to change?

26:43 Matthew Skelton: They're not architecting for things being static. We are helping things to evolve. That's a very different way of thinking.

26:50 Daniel Bryant: Evolution.

26:51 Matthew Skelton: Yeah, evolution is a very different way of thinking from the past where we kind of design something that was going to be basically the same for many, many years or five years or 10 years or something. Now they're all the architects. It's more about working out how to make sure that this thing can adapt very, very quickly, potentially over the course of months or certainly years. That's a key aspect of what we talk about in part 3 of Team Topologies is setting things up for evolution. Listening to the signals inside the organization that tell us for example, that although we got the domain boundary right last year, the domains actually changed. The international regulations for trade in this sector or the kind of compliance requirements-

27:23 Daniel Bryant: GDPR classic.

27:24 Matthew Skelton: GDPR, all of these kinds of things have changed. We're now no longer able to send this kind of data from this country to that country and so on. We have to expect this stuff to evolve. Again, a good role for architects is to get involved in thinking about how we would detect in an organization that we've got our domain boundaries wrong, that they were okay in the past the external environment or the internal business environment, or whatever has now changed, and we now need to be able to evolve the system.

27:50 Matthew Skelton: That's incredibly important responsibility for architects to be able to do that. Some of the teams probably these patterns will be part of the architect's toolkit.

27:57 Manuel Pais: Also even besides the rapid change in markets, also just admitting that you might get it wrong. You're probably going really wrong. The independent services that we were talking about, or the bound of context in domain driven design kind of terminology, you're going to make mistakes. We should be expecting that we're going to be sensing for... Actually we thought this to seem like independent and have their own different lifecycle, but then what we realized in practice is that these two teams are often having to collaborate and sort out how their different APIs need to evolve to be compatible or whatever it is.

28:35 Manuel Pais: Then we realized actually, we probably didn't get it right. Having the honesty or not being afraid to realize that we need to constantly evolve and sense when actually we didn't get it as right as we thought and so we need to adapt. That's kind of one of the core ideas of team typologies as well for me. One of the ideas that I was trying to get across is that we should not be thinking about static boundaries, should not be thinking about static models, even for our team structures. Things like Spotify model have been quite helpful. Like Matthew was saying for many organizations who are in much worse place, but you need to be careful not to look at it as a static model. We need to have evolving organizations much more like... If organizations would be like a living organism that needs to continually adapt. It's not a static thing that we just follow this model and expect it to work indefinitely.

29:31 How can people learn more about Team Topologies?

29:31 Daniel Bryant: Fair enough. I'm conscious of time here, gents. Other than say buying the book, which everyone should do, of course, what's the best way to get started in this kind of stuff? If folks with liked what they've heard, maybe they're a practicing architecture. I need to start thinking about this building the mental models, trying some of this stuff out, learning in a safe environment. How would you recommend folks get started?

29:48 Matthew Skelton: Just visit our website teamtopologies.com. We've got some case studies. If you go to teamtopologies.com/examples, you'll see some case studies from organizations that have adopted the teams typology since the book was published. The two most recent examples on that are, as I mentioned from Footasylum, which is a retailer and you Uswitch, which is a utilities comparison website, really great case studies there.

30:11 Matthew Skelton: There's some good level of detail that will resonate for architects. There's also some other kind of online learning that we've gotten there. Lots of videos, talks, slide decks, this kind of thing, sign up for our newsletter because we've got lots of things coming in the future. For example, we plan to do a series of kind of visual patterns and anti-patterns to help explain some kind of good interpretations or what we've written about and some less good interpretations of what we've written about.

30:35 Matthew Skelton: The maybe some anonymous examples of organizations that we've seen that are doing it really badly. Of course we've got training as well. We spent the last few months really reworking the training that we have before, which was all in person training, reworking that into fully remote first. Actually, I'm sure this is not a surprise to many listeners, in many respects the remote training is actually better than in person, because for example, you can save a copy of the mirror board that we're using the work, the digital whiteboard, save a copy of that.

31:03 Matthew Skelton: That's really easy for everyone to take away and remember what we're doing and that kind of thing. We're actually in the process of collaborating on some additional training as well. We're collaborating with experts in other fields, for example, our first kind of collaboration training is around DDD domain driven design.

31:18 Matthew Skelton: We'll have DDD experts giving that training, but it's contextualized to team topologies. We'll be doing hopefully some other training as well, maybe around architecture, maybe around Wardley mapping, things like this and bringing in additional ideas into this space to explore it more and to bridge some of these areas where sometimes historically been a bit separate.

31:36 Daniel Bryant: Be sure to link all that in the show notes. Well, thanks for your time today, gents.

31:39 Matthew Skelton: Thank you Daniel.

31:39 Manuel Pais: Thank you so much.