Team Topologies With Manuel Pais

Transcript

Tiago Barbosa: Welcome to Page It to the Limit, a podcast where we explore what it takes to run software in production successfully. We cover leading practices used in the software industry to improve both systems reliability and the lives of people supporting those systems. I’m your host Tiago Barbosa, and you can find me on Twitter at t1agob using the number one for the letter I. Hello and welcome to one more episode of Page It to the Limit. I’m Tiago. And with me today I have Manuel Pais, one of the co-authors of one of the best books I’ve read lately: Team Topologies “Organizing Business and Technology teams for Fast Flow”. Manuel, welcome to the show.

Manuel Pais: Thank you very much.

Tiago Barbosa: First of all, it’s a pleasure to have you here, and before we begin, I would like to ask you if you could introduce yourself to the audience.

Manuel Pais: Sure. I co-wrote the book, Team Topologies with Matthew Skelton. So the book has been out now almost four years and has been quite successful, which is great. My background is in computer science and I had started as a developer, then I got interested in testing and QA, I became a team lead, and then I did several years of consulting together with Matthew and that’s where the ideas from the book grew in our discussions in our work with clients. Of course, before the book people weren’t talking about Team Topologies, but we were looking at certain patterns, anti-patterns and things that worked well or didn’t work well and the relationship between how the teams are structured and the systems that they were operating and all these things. So it’s a very brief background.

Tiago Barbosa: What was the driver for you and Matthew to come up with Team Topologies and you kind of answered that.

Manuel Pais: Yeah, I jokingly say we wrote the book that we wanted our clients to read so that we didn’t have to explain everything again and again. But yeah, it was distilling our experience as well as other companies that we saw that certain patterns and anti-patterns and bring that together in a consistent way.

Tiago Barbosa: Yeah, that’s a good segue to one of the things that personally got me more interested about this book is you not only cover patterns, anti-patterns and you provide best practices in a way to improve the communication between teams and all that and how to organize teams, but you also give specific examples of companies that were going through the same challenges that many of us are going through and you use their examples to kind of show the before and after. Right?

Manuel Pais: Exactly. And it’s interesting because in the book, like I said, those examples, those case studies had a limited scope. We’re just showing in this example, this company used the idea of platform as a product for example, or the way they organize their teams to have to improve communication, all those things. And what we have now if people are interested is on our website on team topologies.com, we actually have industry examples after the book. So companies and people who read the book and then try to adopt and implement some of the ideas. So

Tiago Barbosa: Cool. That’s pretty interesting. So when I’m trying to explain and kind of sell the idea of Team Topologies as well in conversations with colleagues and in my previous company I was one of the advocates for Team Topologies and we try to implement this. The question that I got very often, is this a replacement for existing methodologies or frameworks such as Agile Kanban or Scrum? Or is it something that you build on top or where does this sit basically?

Manuel Pais: Yeah, that’s a fairly frequent question or doubt. I mean, team Topologies itself just had a similar discussion a few days ago. Some people think it’s a pattern language, other think it’s Martin Fowler, for example, who wrote an article recently about team topologies. He thinks of it as like a metamodel for then actually sort of creating your own instance or implementation of what kind of teams, interactions, etc. So you can design your operating model based on the ideas and principles of the book. And then when you look at more specific methodologies like Scrum or Kanban, we intentionally didn’t go to that level because we think one of the main tenets of the book is that the team is the unit of delivery. So we should be optimizing for the team to have the necessary resources and help and knowledge to do the best work they can. And we need to think about other things. How do we get teams to be more autonomous and independent? But in terms of the way of working for us, that’s always up to the team or I personally I should say, don’t believe in this standardization of working practices across teams. Who really cares if one team is doing Scrum and the other team is doing Kanban, if both teams are evolving, they’re improving and they’re delivering on what customers actually want. Unless you’re focused on everyone must have this certification and everyone must use the same way of working. But I often think there’s sort of tendency to try to standardize ways of working that is too much. You actually, from my point of view, what you want is to, yes, you want to help the teams and say, look, there’s Scrum, there’s Kanban. If you need training or if you need to learn from others in the organization who have done this well, it’s available to you, but then make the decision as a team.

Tiago Barbosa: That makes sense. Does that mean that you could potentially use something like Team Topologies on top of Waterfall? I know that it might be an anti-pattern because team is more designed for fast flow and Waterfall is more designed for let’s say predictability and long-term vision. Right?

Manuel Pais: So it’s an interesting question because Waterfall has traditionally, when people talk about Waterfall, we’re talking about we have project and we have a number of teams involved. Might be depending on the size of a project, might be a few teams, might be dozens of teams, and then there’s a lot of coordination needed in the nineties and two thousands maybe and before the idea that we need to have a big coordination project to get synchronized teams and have Gantt charts and all this. So I don’t think that’s today in 2023, that’s not an appropriate way of organizing the work because that’s too slow that there’s a lot of missed deadlines, miscommunication and problems that are identified too late. But I would say, and coming back to my previous answer, if you have a team that has, they’re developing some project or some work or product and they decide inside the team to have a sort of waterfall approach for valid reasons. If they say, and this is also kind of typical questions, what happens if you’re not just developing software or digital services but you actually have hardware involved? So your whole product, you cannot just deliver the software part. You need to have the hardware, whatever it is, IoT or something else or actually helping a customer that they’re doing working on with the electric vehicles and charging stations and all that. So you could have a team that decides where we as a team are doing this in sort of waterfall-ish way where we need to do more design upfront. We need to then do the coding, and then the testing once we have the hardware and then only then we’re going to put something out there. So there’s sort of waterfall-ish, but it’s because the team has specific constraints that need to follow. And even then I would try to, going back to Agile and I’ll try to slice that as much as possible so that you don’t do a huge release with hundreds or dozens of features, try to break that down as much as possible.

Tiago Barbosa: That’s a very valid point. I think in, as you said, working in a waterfall approach doesn’t mean that you can’t have small deliveries and more frequent deliveries to the business internally, and then you have a larger release by the end of the quarter or whatever you decide. But when the hardware component is ready. But you can still have small releases to the business to validate your idea, your concept, and to get their feedback.

Manuel Pais: And sometimes you even have, I’ve seen examples where especially if the customer has to install the new versions of the software that they’re using, that the client doesn’t want that frequent releases they want once a quarter or something like that. But more and more those start to be exceptions. More and more the services and products are delivered in a kind of SaaS approach. And so it’s just the nature of how we evolved and how digital products and services are offered today is that you expect quick evolution and you expect ideally a lot of experimentation and figuring out if is this thing that we’re delivering actually being used, is it valuable for business because it brings profit or it brings whatever reputation or usage, whatever the business model requires

Tiago Barbosa: To grow. That makes sense. So one of the most common things that I’ve seen in my career while developing software or helping other people develop their software is typically teams that are developing the software and the business are thinking about different things and the communication is not very frequent. It’s definitely not effective because they speak in different languages. This means that almost every time when you show something to the business, then well, it’s not what they were expecting and you are already late to meet the deadlines and all that. So it’s one of the things that I believe Team Topologies is kind of trying to solve. Right?

Manuel Pais: Yeah, I mean one of the key aspects that we talk about, for example, for stream aligned teams, teams that are focused on some part of a product or a whole product or some other stream of value to the customers is that they need to have business awareness. In the book we talk about this idea of team cognitive load and the fact that I think part of the reason why what you said happens that teams, let’s say the technical teams are talking different language from the business that they have so much to worry about just in terms of tooling and frameworks and whatever processes as well that they might need to follow internally that it doesn’t even leave them the time and capacity to think about, to understand better the business. So we’ve had that divide in business and technology for a long time and it’s clearly, it’s an issue, it’s not easy to solve, but we need to bring more product awareness and understanding of the business, which is of what’s called germane cognitive load into the team. So reduced kind of stuff that is very technical, but in fact it’s kind of taking away the time and capacity of the team, but it also requires the business itself and the companies to change the way that they think about developing products and services. Where as you know, a lot of times business thinks, well we’ll just define what are the features we want and then we give this to the development teams and then they’ll just implement it. And anyone has been in the development team knows it doesn’t work very well like that because what you said, we need much faster feedback loops. Either you need very fast feedback loops with the business people who can tell you is this what we need or not or which is what I think makes more sense, bring that knowledge into the teams. And that might be, again, different teams might have different ways to get more understanding of the business side. Either it’s their learning or they actually have a business person integrated team. It’s not so easy because we’ve seen, for example with Scrum, this idea of the product owner. What happened is a lot of times they are sort of a proxy to the actual people who know about and who have interactions with the customers. So they’re sort of middleman sometimes or middle person translating the business needs into software requirements. And we know that’s not ideal as well. But yes, you have a lot of people also talking about this topics like Melissa Perri who wrote the book “Escaping the Build Trap”. You have people like John Cutler who talks a lot about this, let’s say overlap between product and teams and organizational structures.

Tiago Barbosa: Yeah, that’s pretty cool. So one of the things I wanted to mention or go back to is the core concepts of team topologies. So you mentioned, because we talked about different teams and the way the teams interact and the core concepts of team topologies, basically you mentioned four fundamental ways of organizing teams and three different interaction modes. Can you walk us through what these are and how to implement them?

Manuel Pais: In the book we’re talking about, first of all, how do we organize for fast flow, right? It’s important to understand that you can organize your company or organization in ways that are optimizing for other things, but we know that today mostly we need to be able to move fast. That’s expected from the customers, that companies can react quickly and that you can provide also similar offerings to your competition to stay in the market with all the startups and all the changes in terms of how much easier it is today for new companies to enter markets or industries that until recently were sort of, I wouldn’t say exclusive, but were difficult to get started, banking and finance, even healthcare and other areas like that. So that’s the key idea. How do we get to fast flow? And when I say fast flow, I mean fast flow of value to the customers. It’s not just how can we deliver features faster or create new software faster. It’s not about that specifically, but how do we understand better the customer and are able to provide what they need where sometimes we don’t need as many features or what we need to improve is the user experience or we need to improve the consistency of the products that we offer, whatever it might be. So in that sense, you need teams that know the products and the things you offer quite well. That’s very difficult if you actually have a technical architecture that’s based on large monoliths where you need multiple teams to make changes to the same code base even for a small feature. And so our starting point in terms of types of teams would be a stream aligned team. That means we have one team that owns a very clear, usually part of a product because products tend to be quite big these days or too big for a single team, but it could be that the team owns the whole product, but they need to have capacity and the skills to really be the owners of this product or part of product or service. So they are the ones who are going to be able to evolve this service quickly and make changes to software or user experience or whatever, or even documentation needs to be improved, but you have that end-to-end ownership. So that’s the starting point, which has implications in terms of how we think about architecture, how we think about decoupling business concepts and business offerings, etc. But that’s what we’d like to achieve for fast flow. But then as I mentioned earlier, with the complexity that we have today in technology and all the tooling, we need all the skills that we need for a cross-functional team, a stream aligned cross-functional team to be able to do their work well, that means that’s being requested from those teams. So then we introduced the other three types of teams, so in a way they work to support the stream aligned teams. In an ideal world, we would just have streamlined teams, let’s just split and decouple our offerings so that each team can own it end to end and that’s it. But in reality, that’s difficult because of the cognitive load that is being put on those teams. So the other types of teams are, I can start with the platform teams, which the key here is to have platform teams that have a different approach from the past where they think about the platform as a product itself. Yes, it’s an internal product, but it’s a product that’s being used by internal teams. So they need to have a good modern product development approach where they talk to the teams, they understand what are the difficulties of the teams, and they collaborate on what do we need to provide in the platform to reduce that cognitive load on the stream aligned teams. And then we have enabling teams, which are usually a team, a small team of experts in some domain of expertise where we might have some gaps in the teams. We might have teams that need help to upskill and to essentially do that in a much more effective way because in the past we’ve traditionally expect teams to just up-skill magically by themselves because people just spend your free time learning or doing your own projects and then you learn new skills, but that’s not very sustainable. And so enabling teams, and this is very interesting area for me because I think that’s maybe one area that is the least well understood in team topologies, how powerful it can be to have enabling teams. And we actually created a course recently called Effective Enabling Teams on our Team Topologies Academy where we’re talking about how to start and measure the value of enabling teams and then grow enabling teams in your organization because we have some really good examples where this has been quite powerful and I would say almost life-changing for the organization, but it’s very different from what many organizations expect that the experts are doing the work, they’re the experts, so they’ll just do the work for, but that creates bottlenecks, creates dependencies, and if we take a team first approach as in team topologies, what you need is to bring that expertise to the teams, not that they’re going to be experts in everything, but to have a sufficient level of knowledge across different skills and domains, whatever that might be, user experience or do we need to know more about the actual business? We need to know more about maybe the legal aspects of our business, especially in highly regulated industries. And so instead of having a dependency on some other team that’s going to do that work, we want to bring the knowledge into the teams.

Tiago Barbosa: They become self-sufficient, or at least they will have a general idea so they can be self-sufficient in most cases and avoid the bottlenecks by doing so.

Manuel Pais: Exactly. But the enabling teams, I think to some extent are underused in my opinion, because they are seen more as a cost. We have a team of experts who are helping others and they’re not actually executing or developing new stuff. And so it takes sort of a mental shift. But in that course I mentioned we try to explain how we can get started without a big investment. Just you can start by having maybe some of the platform teams. They are typically experts in some domains. So if we’re talking about more technical domains, they might have some teams that are experts in infrastructure automation or you might have some teams who are experts in monitoring or alerting, telemetry, etc. And so those teams might be in a good place to do some enabling work. They’re not enabling teams, but they could do some enabling work to help some of the stream aligned teams that might be struggling a little bit with some of those ideas. There’s an interesting example, since I’m talking to you Tiago, from PagerDuty where we did a bit of work with a large organization and they told us they have a kind of platform team that in their words: “oh, they built a tool which is kind of like PagerDuty similar to PagerDuty, but it’s our internal tool”. And I’m like thinking to myself, I couldn’t say this out loud, but why in the hell would you do that, right? I can understand in some situations that you might start there because you think you have some specific requirements, but if you’ve yourself identified that it’s basically sort of the same thing, why are you in a large organization that has a nice profit, why would you not have that team actually use PagerDuty or whatever they think fits their needs and have those people doing a lot more enabling work? Then you get in this example, and I’ve seen this in other companies where then they complain that, well, we provided these services and we have this great platform and people don’t really use it and they say they don’t have time to understand how to use it, etc, and that’s because you’re not doing enabling work. You need to reach out and actually talk to the teams and then you will see the change. And so don’t invest if you have the choice, don’t invest in building your own PagerDuty, but actually have those people that are, I’m sure very knowledgeable about this domain, do enabling work and reach out and explain to the teams on the ground how to use this and how to understand better what kind of monitoring you should do, what kind of alerts and all that. Other things that the enabling team might do is staying with a PagerDuty example, because even before you reached out to me, I quite liked the documentation that PagerDuty has available on your website about a lot of topics like incident management and so on. So an internal enabling team would be in a good position to kind of curate that knowledge that already exists and tell the teams, depending on where they are, if they don’t know anything about incident management, it’s the first time they’re doing that, where do you start? Well read this documentation from PagerDuty or read this other documentation or let’s do a workshop. So there’s a lot of work that I think is very powerful, but because it has that connotation that it’s more of a cost rather than direct. So it’s a bit harder to calculate directly the return on investment to have those teams and not as widely adopted as the other types of teams.

Tiago Barbosa: Yeah, I think you touched a very important point there, which is the fact that people and software developers, it’s very common to have that they invest their free time, which sometimes is their personal time most times, and they invest their personal time in learning new stuff. So that becomes a need and cost, and so it makes it even more difficult to calculate that as you were saying.

Manuel Pais: I mean a company I would say of any size, but especially medium to large company, shouldn’t rely on people spending their spare time learning to do their job or learning new skills so they can do their job better. Of course, people who want to do that because they want to progress in their career or they want to learn new skills, they have that interest, that’s great, but it shouldn’t be something that the organization relies on to up-skill their teams. They should have, in my opinion, more this enabling approach, whether you have actual dedicated teams or you look at which are the teams with the right expertise to help others. So one interesting example quickly is if you’re changing your architecture to micro-services. You’re not going to do that in one big bang change - hopefully! That’s not a good idea. So it’s going to take some time, months, maybe years if you have a large estate of software and products to do that sort of migration. And so the first teams that do that, even though they might be more kind of stream aligned teams, they will be in a good position to then help the other teams that are coming on and migrating later on. So, identifying these possibilities that already exist within the organization of sharing knowledge and doing enabling work, in this case between two stream aligned teams. It doesn’t have to be always the enabling team to do that is quite powerful. And so to come back to the previous question in Team Topologies, we also have these three key interaction modes or core interaction modes that we think are useful to think about to evolve the organization to help address the gaps that teams have. So that’s collaboration, facilitating, which is this idea of sharing knowledge and helping teams quickly learn new skills and X-as-a-service, which is typical for platform teams.

Tiago Barbosa: Yeah, and this is interesting because one of the concepts that you have here is that these interactions between teams, they might be or they are in most cases just yeah, they are temporary. They happen in a specific point in time when necessary. And this is something that we, sometimes I feel like the teams understand that they have the need for something, but let’s say that we don’t have an enabling team, so you have no one to reach out to and then well, you need to learn it yourself and you find the mechanisms and you invest the time to learn that. So I do see the power and the value of the enabling team for sure. So Manuel, one question that I have for you and probably one of the last questions that I have for you is applying team topologies requires you to kind of reorganize. So you need to ideally if you are not already split into smaller teams or following the stream aligned teams or something like that, so you need to reorganize, and this is from experience, something that takes time and it works better if we have senior leadership sponsorship to get this implemented properly. So is this something that you have been seeing as well while working with your customers? And if there is kind of any tip that you can give us on making this smoother?

Manuel Pais: To me it’s a bit of an anti-pattern to expect that we’re going to do a transformation, a big change to a lot of teams and we’re going to have to wait for C-level or to decide and to give the authority or the mandate to make the changes, etc. In some cases we do see that, and that’s typically coupled with another sort of anti-pattern, which is to even after reading Team Topologies, to think that we can have the ideal operating model or the ideal organizational structure that just doesn’t exist. You have organization models that will be better for some things and others not as good for what you’re trying to do. As we were talking about team interactions, that’s quite important because the fact that they’re temporary and they change over time based depending on what you need. Because what I see sometimes is the expectation we can define this operating model and then the interactions between teams are expected to be always the same. Oh, everything is like X-as-a-service or everything is, it’s always collaboration. But that’s actually a bad thing. If these two teams always have to collaborate to get something done, then it’s basically a blocking dependency between them. They are not autonomous. They should collaborate occasionally when they maybe need to clarify boundaries between the two teams or they need to find a better way to, I don’t know, integrate or test across two parts of systems, something like that. And so my recommendation, which is really same as a lot of people tell you in terms of if you want to adopt Agile or DevOps or any kind of change in approach and framework is to do it step by step. Don’t try to define a big program of transformation from the beginning. You might get to a point where there’s enough involvement, both top down and bottom up that it actually makes sense to make this sort of a transformation program. But you can start just with small things. So at the team level, and that’s something interesting we saw after the book was published because it got interest from people in very different roles and we were expecting that was more for people who deal with organization design, people in management, and in those positions that would take more interest. But we saw interest across the board, even agile coaches, architect and software engineers in general. And I think what’s interesting is that you can do small things even as a team, let’s try to adopt these interaction modes in a more intentional way. You shouldn’t need any sort of permission to do that. You just reach out to other teams and say, well, we think we need to collaborate on this and we want to frame it in this way, or we want to help to learn about X, and your team has the experience and knowledge, can you help us? You can start there and then it’s at some point of course you get to a point where if you can have top down and bottom up support, that’s ideal. And what we’ve also seen, and this is especially true in large organizations, we’ve also seen small organizations when people, let’s say who are in the leadership positions, get the ideas from team topologies and they understand it’s easier to do a broader sort of change. So some of those case studies I mentioned in the beginning, which are on the website, some of those early case studies are typically from smaller companies where they were able to, for example, one that comes to mind is PureGym. They were startup and Scale Up. They had this big monolith that kept growing and they were slowing down very quickly their ability to deliver value. And so they took team topologies and they looked at what are our value streams, what do we actually provide to the customers? And then aligned the teams with that, etc, so they did a bigger change. But for large organizations, that’s what I usually suggest. Let’s take small number of teams ideally where people already are in tune with these ideas and have interest to adopt. And in some cases, like I said, even just at the practitioner level, the team itself can start to do Team API, they can start to adopt team interactions. They can look at their cognitive load and say, well, this are the things maybe we shouldn’t be dealing with so that we can free up more of our capacity to look, understand better business. But obviously at some point they might face some barriers to do more of, take more of this approach. And that’s where having top down support is going to be helpful as well.

Tiago Barbosa: Definitely. I think the main point here is to, so if you’re trying to look for something that works for everyone and it’s like a fixed mechanism that should work the same for everyone, that would be almost impossible. So you think, I think you need to start small and learn from it and adapt as you go, right?

Manuel Pais: Yeah, I would say that. And sometimes you have even pockets of adoption. We’re talking about topology, but it could even be something else, some other DevOps when it was starting whatever, because we saw, well, different people from the same large company are in touch with us and we actually got them to, oh, did you know that these other teams, because large companies that work across multiple countries and so on, people don’t even know there’s someone else from my company doing something similar or with similar ideas. So it’s funny that sometimes we make that connection that’s fine, that it starts in pockets and then it grows and you start to see more and more teams adopting some of these ideas.

Tiago Barbosa: I just wanted to ask you, so if people are interested in Team Topologies, what’s the best place for them to get started?

Manuel Pais: I would say our main website, teamtopologies.com. That’s where you have both resources to get started. The infographics that are helpful to kind of just give you the broader picture, obviously the books, there’s the main book from 2019 and there’s the Remote Team Interactions workbook that we launched last year. And then we have an online academy with video-based training, which is academy.teamtopologies.com, and that’s how we try to scale, let’s say, both going deeper into some of the aspects of the book and bringing and case studies into this video-based training and also our latest thinking, right, since we published the book, there are new things we’ve discovered and examples. So yeah, I would say those two are the best entry points.

Tiago Barbosa: Cool. Thank you, Manuel, for your helpful insights you’ve shared with us today. It was great to have you on the show, and I wish you all the best spreading the word of Team topologies. And for anyone interested in getting to know more about Team Topologies, Manuel already mentioned, it’s Team Topologies website at teamtopologies.com or Team Topologies academy academy.team topologies.com. Thank you so much for listening in and see you next time. That does it for another instalment of Page It to the Limit. We would like to thank our sponsor PagerDuty for making this podcast possible. Remember to subscribe to this podcast if you like what you’ve heard. You can find our show notes at pageittothelimit.com and you can reach us on Twitter at pageit2thelimit using the number two. That’s @pageit2thelimit. Let us know what you think of the show and thank you so much for joining us. And remember…“Uneventful days are beautiful days!”.