Manuel Pais on DevOps Team Topologies: From DevOps World | Jenkins World 2019

Brian Dawson: Hello, this is Brian Dawson at DevOps World | Jenkins World 2019 in Lisbon for a special live edition of DevOps Radio. And today I'm happy to have with me Manuel Pais, the author of the Team Topologies book, which you'll hear me rave about. It's a fantastic book, and I actually think it's gonna be a book that will be recognized as being extremely important to successful adoption of DevOps and enterprises in our industry overall. Also joining me is Sam Fell. I don't think I can do either of these guys justice introducing them myself, so I'm gonna hand it over to you, Manuel. Hello?

Manuel Pais: Hello.

Brian Dawson: Can you go ahead and introduce yourself to our listeners?

Manuel Pais: Sure. First of all, thanks for that introduction. I co-wrote a book, Team Topologies, with Matthew Skelton. We have worked together for several years in consulting with different clients. My background is I started as a developer. Then I had roles in build-and-release management and then testing and team lead. Then in the last five years I have done consulting mostly around DevOps, continuous delivery. The recurring problems that we saw, me and Matthew, with clients is that often we're looking at improving the tooling and the way we deliver software. But you will often have awkward interactions between teams and gaps in communication, and that actually affects much more the end result than whether you have 2A or 2B to do the same thing.

Brian Dawson: Phenomenal, phenomenal. I've gotta withhold digging in 'cause I know I've gotta let Sam introduce himself. First, Sam, I'd like to thank you for getting Manuel out here and bringing the book to my attention. Again, I think it's really valuable. So with the facilitator of this conversation here, can you go ahead and tell our audience a little bit more about who you are?

Sam Fell: Certainly. Thank you for that. Sam Fell. I previously led marketing over at Electric Cloud, which is where I had the honor of meeting Mr. Pais when he was working for InfoQ. So I had many a long conversation with him about some of the things that we were doing there. Now I'm working in the marketing team along with the rest of the other Bees here in the hive. So I'm happy to be here. I'm excited to be here with Manuel.

Brian Dawson: Awesome, thank you. I appreciate you bringing this relationship forward. You know what, let's just go ahead and jump right in and start asking you some of the hard questions. As we've talked about, you're an author of a book that I'm a fan of, Team Topologies: Organizing Business and Technology Teams for Fast Flow. Maybe you could kick off the discussion by sharing with us some key takeaways, key lessons that are provided by the book you and Matthew wrote.

Manuel Pais: Sure. One of our ultimate goals with this book, if you like, is to help organizations become more of a living organization and adapt to changes in their environment, not only technology but also the market, in a more continuous way rather than what we see often, which is big-bang reorganizations because now we need to be agile or we need to be DevOps. That's not very effective in the end. It always causes side effects that are not always positive. So how can we become an organization that has the right types of teams and interactions that it's easier to then adopt new technology without major disruption? That's what helps also the business then achieve faster flow because we're not being constantly distracted by this new technology.It's much easier to adopt that with the patterns that we talk about in the book. We mention four types of teams, four topologies – stream-aligned teams, platform teams, enabling teams, and complicated subsystem teams – and then we also talk about three core interaction modes between teams, that is collaboration, X-as-a-service, and facilitation. These patterns help us think about the day-to-day interactions between teams and making that more explicit so that there's less ambiguity in terms of what's our role, what are we supposed to provide to other teams. Then that helps integrate ideas and practices around DevOps as well.

Sam Fell: Manuel, a question. You wrote this book, and it's based on the experience that you and Matt have with organizations. Talk a little bit more about your experience and how you came up with these different topologies, the different groupings.

Manuel Pais: Right. Yeah, it's interesting. We worked together for some years with different clients around the world, mostly in the UK but around the world. Obviously we had these conversations coming from several years ago, and we were looking at these patterns and seeing what worked and what didn't in these clients and at what moment in their evolution, because it's also about evolution of the organization.And so we started to solidify these ideas around platform teams and stream teams, but also with input from publicly available talks and case studies. I always go to the DevOps Enterprise Summit, where you get all these case studies from large organizations.When we were writing the book, we were trying hard to find maybe there are some other patterns, but somehow we think that these four topologies and the three interaction modes are –

Sam Fell: Those were the buckets.

Manuel Pais: Yeah, are the core. You should be able, most organizations, to leverage that to, like I said before, clarify what are we trying to achieve, how do we expect teams to interact, and how do we embark and adopt new technology practices and evolve?

Sam Fell: 'Cause the book has lots of diagrams and ways for people to get a concrete vision of how these teams are aligned and how they're structured. So I guess what you're saying is that if I'm the leader of one of these DevOps initiatives and I read your book, I should see something that resembles my team's current setup in the book.

Manuel Pais: Exactly. I don't believe any organization will start at zero. They are gonna have some of this going on. But often it's the lack of clarity and understanding what is the purpose of these teams and what they're doing. There are also a number of case studies in the book from different companies. Team topologies as a whole has not been – is a new idea, right, from the book. We started to see some clients try to adopt that as a more –

Sam Fell: Yeah, just a structure to work off of.

Manuel Pais: You've seen pieces here and there. Platform teams are very common. We now understand what makes a good platform team and a good platform service because it's often about how we do it, not just having a platform by itself. There are many examples from data, CyTV. I like the examples from Auto Trader in the UK, which are not as big as these other organizations, but they do really cool stuff. So we have some of those case studies in the book, and we're also publishing some more on our site, teamtopologies.com.

Brian Dawson: I'll ask it this way. Of the topologies that you've documented and captured, is there one particular topology that you're seeing as most prevalent? And then, two, is there a particular topology that you're seeing people are finding the most success with, and are they the same?

Manuel Pais: The initial topology, if you like, that any organization is going to need are stream-aligned teams. So you can look at this as kind of product teams or cross-functional teams. They are the ones delivering the business value to the customers. So any organization that wants to provide products and value to customers is going to need those teams, and we have so many names for those development, delivery teams, whatever you'd like. But we talk about these teams as being aligned to a stream of work. So it might be a whole product. It might be part of a product.

Sam Fell: A feature.

Manuel Pais: Yeah. And they need this cross-functionality to be able to own the end-to-end lifecycle, because we know now with research from Dr. Nicole Forsgren, Jez Humble, Gene Kim, and so on in the Accelerate book we know that the high-performing teams have this ownership of the end-to-end lifecycle of their applications or services. And so we want that cross-functionality, but in practice that is quite hard because then you're expecting a team of between seven, plus or minus two people, to have all this knowledge around testing, infrastructure, automation, security, et cetera.

Sam Fell: Complicated subsystems.

Manuel Pais: Possibly, but mostly the platform should be able to start providing these services to the stream team. So what we're saying is then the stream teams can focus most of their effort and capacity into the actual business problems and what they're trying to deliver and not have to have this kind of full-stack approach.

Brian Dawson: They don't necessarily have to be deep domain experts. You codify some of that domain expertise into the platform.

Manuel Pais: Yes, as internal services.

Brian Dawson: As internal services. They have to have understanding of that domain to leverage what's been provided by the platform, right?

Manuel Pais: Exactly.

Brian Dawson: But you're lessening the burden of having to have your rock star QA expert – a rock star QA expert distributed onto every team. Is that correct?

Manuel Pais: Yeah. Or, for example, with CI/CD, since we're at Jenkins World today, for CI/CD you would like to have your platform to provide not only the infrastructure for CI/CD and the pipelines, but also perhaps some good practices around how should the pipeline look like, which activities would you expect to have to ensure certain criteria for the locations you're delivering. And so you provide these good practices, and you share them via the platform. The stream teams should have some autonomy to change it and adapt to their needs, but this can reduce very strongly the time it takes for them to understand CI/CD if they are new to it or to leverage the tooling and the practices that are known to be recommended.

Brian Dawson: Good. Now before I hand off, 'cause I know Sam has some questions queued up to dig in a little deeper, are you seeing – what I'm hearing, and I'm probably wrong so correct me, is that what we're starting to align on in at least your first step in a DevOps team structure or team topology is to move to product or feature-oriented cross-functional teams. Is that correct?

Manuel Pais: Yes, and more broadly, moving organizations to product orientation rather than project orientation. There's a book from Mik Kersten all about that, Moving from Project to Product. So as an organization, ideally you're doing that as well because then you want the teams on the ground to be aligned to this product orientation. In the book we talk about the stream teams being inside business units or business segments because otherwise, no matter how agile these teams are, if their starting point is – before they start, there is this gap with the business that we create a project, and you come back in three months or whenever and provide this stuff.

Brian Dawson: You've already inhibited the collaboration that is encouraged and necessary for a successful cross-functional team. You're basically saying, "Don't align 'em under this big, monolithic software work. Put 'em in the line of business which is an extension of a cross-functional focus that now involves the business."

Manuel Pais: Exactly, for the stream teams. And then perhaps your platform teams and enabling teams that we talked about, perhaps they are part of a –

Sam Fell: Centralized.

Manuel Pais: Yes, some kind of engineering productivity or whatever you want to call it. That might make sense because then that product is software and services. They're in the business of providing this software for the internal teams.

Brian Dawson: So they are business-aligned, right. Awesome. And I'll squeeze another one in, something that just popped into my mind. There's been a lot of conversation I believe saying we're just gonna talk, whether it's conversation about the Spotify model.And I see a lot of overlap and alignment between the Spotify model and some of the topologies that you have outlined in the book. Can you comment on that correlation or how much you reference that?

Manuel Pais: Yes, definitely. The Spotify model, even though the Spotify staff has been warning people that there is no Spotify model in the sense that there was in 2012, I believe, or 2014, and they have evolved since then. They have this kind of continuous adoption.But nevertheless the model has been useful for many organizations to start thinking about we actually need to plan and budget for learning, for sharing, and aligning teams to business with tribes. Supposedly that's what you're doing. Some of these aspects have been helped by the Spotify model, but we find that we need to also think about this kind of more evolutionary approach and how do teams evolve and how do they interact in a meaningful way, and also in terms of capabilities, how do these teams – we were talking about cross-functionality. You can't just set up a team and say, "Well, now you're cross-functional, and we're gonna do all these different things."

Brian Dawson: "Go work together."

Manuel Pais: You need to help them skill and evolve, yeah.

Sam Fell: There's a cognitive load that you need to manage.

Manuel Pais: Yeah. So that's why we talk about also not just platform, but enabling teams that are usually small teams of experts in some domains that might be broader or narrower depending on what you need. These are going to help and facilitate the knowledge in those stream teams, which can be through any number of techniques, workshops, book pairing on examples. They're there to help them learn, not do the work.

Brian Dawson: It's funny. There's not a direct correlation, but there is some overlap to guilds in a Spotify model, which recognizes you need self-encapsulated teams, and they need the freedom of cross-functional teams. But you can't do that at the expense of shared expertise, coordination around larger business objectives. So the center of excellence approach or the platform team approach, like guilds, helps propagate that knowledge across teams or aligned teams.

Manuel Pais: Exactly. Either guilds or other people or it's also known as communities of practices. I think those are quite useful not only for the sharing of good practices and tools and so on, but also just to build communities so people know each other. That facilitates then when they have to interact inside teams.

Sam Fell: Collaboration and trust and ...

Manuel Pais: The only caveat there is that there is that that does not necessarily address the gaps in the current capabilities of the teams. It might help.

Brian Dawson: It doesn't do it in a structured, deliberate way.

Manuel Pais: Exactly. There's where these enabling teams, together with the platform services, are really focusing on what are our gaps today. If let's say, for example, we are creating a new app for iOS for Apple and we don't have the experience, none of our teams has that experience, you can either try and recruit experts for these teams, but that's gonna take time and be expensive probably. Or you can find a small number of experts that act as enablers to the stream teams and bring that knowledge. Or it can be broader domains like continuous delivery in general. There's one example in the book from OutSystems, who are a low-code platform based in Lisbon, actually. They have a team, an engineering productivity team which one of the areas of responsibilities is around continuous delivery. They themselves evolved as the stream teams started to become more knowledgeable around continuous delivery and have more specific requests on what they needed help with. This enabled the teams also to evolve and perhaps start with a broader domain that they're helping the teams with for a lower maturity and then over time focus more on specific domains.

Brian Dawson: Awesome. Sam, did you have – I've got a list of questions, and I want to make sure that you get a chance to chime in.

Sam Fell: Well there are some other things. We've been talking a lot about teams, and teams are made up of people. Now people are not computers, and so you can't throw too much at them. So tell me a little bit about your guys' thoughts on – I guess you're both guys, so I can say that – your guys' thoughts on cognitive load, 'cause I thought that was a fascinating thought process you went through.

Manuel Pais: So cognitive load, just to set up the background, is the amount of working memory being used to solve a problem or to deliver some functionality typically in stream teams. But there are different types of cognitive load. You have intrinsic load, which is related to the skills that the team has. So if you are lacking some skills that you need, that's gonna tax your working memory. I have to think about, "How do I write this code," or, "How do I use this tool?" There's extraneous cognitive load, which is any kind of task that is related to being able to deliver my work but is not directly influencing the outcome that I am trying to achieve. And there's your main cognitive load, which is everything around the business related to the knowledge I need to have and put in memory to solve problems. So if I'm working on a banking application, I need to know how bank transfer works, for example. And so for stream teams, what we're saying is we want to reduce intrinsic and extraneous cognitive load as much as possible so we leave more –

Sam Fell: Business knowledgeability.

Manuel Pais: – capacity, yeah, for the business focus and actually being able to deliver faster. That's when the platform and enabling teams and sometimes complicated subsystem teams help to reduce that cognitive load and say, "We are taking care of these extraneous tasks for complicated parts of the system."

Sam Fell: So it's specialization, right? It's specialization and having these people focus on supporting that stream motion so that the other folks, the cognitive load for them is really just about solving the problem in front of them, not worrying about if I've gotta ride a bike, I just need to figure out how to ride a bike. I don't have to think about, "Do I have to make sure that the screws are there? Do I have to check the tire pressure first?"

Brian Dawson: "Am I gonna have to be an expert in bearings?"

Sam Fell: Right. "The chain's off. I've gotta put the chain back on. I don't have a glove."

Manuel Pais: Exactly. You don't have to know how to build the bike or what's good materials for the bike. You want to use it, and you can have some training wheels to help you get going faster and easier. That's what essentially the roles of the platform-enabling teams are, because I find and I still see many cases, because on the one hand there's this divide still between business and technology teams and also this kind of myth that, "Oh, you are engineers, and you can just take any demand and find out what's the right tool."

Sam Fell: "You'll figure it out," yeah.

Manuel Pais: "You'll figure it out." The teams are already pressured to deliver, and we're still asking them to do all this other stuff. What ends up happening is they're gonna take shortcuts.

Sam Fell: Well, they have to, right? They want to please people. They want to deliver what they're asked, but the load is too great.

Brian Dawson: We've been using the term "enabling developer" or "software professionals," whether they're developers or operations, and to focus on building and delivering stuff that matters, right? Spend your cognitive load on moving forward and building and delivering stuff that matters versus spinning our wheels. I do want to shift a bit and ask what is your take on the current state of organization and team structure in the community today, and how is that inhibiting and/or enabling companies' or businesses' abilities to achieve successful DevOps transformations? Are we there? Do we still have a lot of work to do?And I'm gonna give an opinion real quick before I hand off the question. I just had a conversation with a number of customers at a Birds of a Feather conversation earlier, and what kind of surfaced is that for most of the people I was talking to and the conversations we have, at the root of the friction they were running into, it was organizational. It was organizational structure. So I at least know for these three it's still a major problem.What are you seeing out of it?

Manuel Pais: I would agree with that. What I find is that there's still a lot of confusion I think around DevOps and what is a DevOps team and do we need a DevOps team. Again, it's about clarifying what is their purpose. So we were talking about cognitive load, and in the context of team topologies, we're saying the purpose of the platform team and enabling team is to reduce cognitive load. That helps always to think about should we do this or not, and then you pose the question: Is this gonna help the stream teams go faster and have less to worry about? Then it sounds like a good thing to do. So with DevOps, it obviously has helped a lot with practices and new tools and ways of doing things. I think what's missing is clarity around ownership and who should do what and who are the users and who are the providers. If we just expect – even if we're doing DevOps transformation, but then the end result is we expect all the teams to know all these practices and be able to apply all of that, that's probably not gonna be very effective. It depends on the size of the organization as well. For a small startup, yes, it probably makes sense that two to three teams, they all have more or less the same kind of knowledge. But quickly as you grow, it starts to become necessary to have these other mechanisms through the platforms, but also good interactions. We are also not saying – while stream teams don't have to worry or understand any of this, they do have necessary baseline knowledge around –

Brian Dawson: To your analogy earlier, they have to understand that a bike has gears. You pedal it. Here's how it runs. But you don't need to be an expert in cranks and pedals. You can understand how it comes together.

Manuel Pais: A baseline understanding, and you should also promote that if the stream team is interested to collaborate with the platform, actually – because many times engineers are naturally interested in new technologies. We're not saying you should try to prevent that, but kind of funnel that into this collaboration with the platform. If you have an engineer that actually he is great or she is great at the business side but also at the technology and they want to help adopt Kubernetes or what have you, why not let them collaborate with the platform team even if they want to stay in the stream?

Sam Fell: Would that be the role of an enabling team to help onboard Kubernetes and get it fitted up with the platform team? Is that where they step in and help out?

Manuel Pais: Possibly. Specifically, Kubernetes, my take on it is that it's not a platform.

Brian Dawson: It's not a platform. Yes, you hit right on it. [Laughter]

Manuel Pais: So we're aligned there. It's the foundation. "Platform" implies that we have teams and we have people who take care of this and provide support and documentation. But also then they collaborate with stream teams to perhaps we want to adopt some and use some new tool in the ecosystem of Kubernetes, and we can see how the stream team is going to use that with our input as well. So making sure there is this healthy collaboration approach and that the platform team is working on what the stream teams need and that they don't go off and, "Let's build this great Kubernetes-based platform," and then we come back and find out, actually, no.

Sam Fell: That no one wants it, right.

Manuel Pais: Or they don't know how to use it. And then the enabling teams can help – well, often the platform team is gonna do some enabling at the same time. That tends to happen. But if they build the services, they tend to have the knowledge around _____.

Sam Fell: To promote it and advertise it, right.

Manuel Pais: For some of this, including Kubernetes, I would expect the platform team then also takes on that kind of role. But they should be careful not to conflate them because if you are developing a product as a – platform-as-a-product, it's a very different set of activities and work than if you're facilitating all this to the stream teams. So you want to have clarity on what are we doing right now or for this period of time. But that's a pattern that we've seen several organizations adopt.

Brian Dawson: I wish we could go forever. Honestly, hopefully we can get a beer or something later, and we'll get a chance to talk. I'll catch you. You're doing a book signing later on today, right?

Manuel Pais: Yes, at 5:00.

Brian Dawson: In the CloudBees booth?

Manuel Pais: Yes. Sam got me to sign 500 copies.

Brian Dawson: Now that is awesome. Again, I think that's big because I think this is really, really important, and probably not enough people know about it. So it's time to put you in the spotlight.

Sam Fell: Although when you say "not enough people," I'm gonna give you a chance to give yourself a little ring on the bell.

Brian Dawson: I set that up on purpose. Not enough people know about it, softball over to you.

Sam Fell: Except for you're number what?

Manuel Pais: We're number three in this list from BookAuthority on new management books that takes on the ratings and all that stuff into consideration.

Sam Fell: Fantastic.

Brian Dawson: Congratulations. That's awesome. I also love the category that it's in, number three in management, which I read as speaking to getting management in the business to understand that this stuff is important. You can't just show up one day and say, "You know what, we're gonna do DevOps without _____.

Manuel Pais: I was mentioning to Sam before that we do training. So far we've mostly done fundamentals, introducing concepts, and we have very different roles of people who come, from agile coaches focusing on the teams and software architects, but then also out of engineering and CTOs. They have to understand what is the impact of teams and interactions on the outcomes and service that we provide.

Brian Dawson: Actually, this is a good segue for one of the questions I wanted to squeeze in. I'm really curious on your opinion. And that is what is your take on what is beyond the DevOps, right? There's been a lot of discussion here at the show and even in the conversation that we've had here about the relationship between the technical function or software function and the business. So to that end, do you have an opinion or prediction on what's beyond DevOps? How do the business and software work together better?

Manuel Pais: I think going back to the beginning of the podcast, my point of view is that DevOps has brought a lot of good practices and helped solve the problem of – the original problem of the divide between development and operation groups. I think that we need to move to thinking about the teams and the whole aspect of team topologies, which is to focus on what kind of teams do we have and how do they evolve to adopt DevOps and whatever comes next, while keeping the business ability to deliver quickly and efficiently and also to respond to problem incidents quickly? So if we keep this in mind, we can bring in not only DevOps but whatever is the next set of practice ideas into the organization without this kind of big bang.

Sam Fell: Architecting the team for agility and learning.

Manuel Pais: Yes.

Brian Dawson: And evolution. You used the word "evolution" a lot, right? Team topologies, but going off of what you just said, it's not just about architecting a team for today for DevOps. It's the agility based on the immutable fact that we are going to need to evolve eventually later to whatever is next.

Manuel Pais: It's much more about understanding our current capabilities and what do we need to do to improve and where do we need to go.

Brian Dawson: So a quick question that I try to get as a standard part of the podcast. I'll spare you the "DevOops" because that's gonna be a little bit complicated. But what I do love to share, what is recommended reading? What, aside from your experience, has really influenced your creation of this book, your role in this community and space that you think our listeners should take some time out to read?

Manuel Pais: Sure. I'm just gonna mention some classics by now, but when I read The Phoenix Project by Gene Kim, that really – at that time I was working on starting my consulting work around DevOps and continuous delivery. But that really rang a bell about, actually, the way that people are interacting and the problems they have day-to-day can be much more significant than the actual tooling and the things you are trying to implement. It has a big impact. So that was the starting point, and then since then books like Accelerate which give us research-based practices and metrics that correlate to high performance, and the Project to Product that I mentioned. I think those are all by now kind of classics, if you like.

Sam Fell: And should be required reading.

Brian Dawson: Yeah. And I'm gonna add –

Sam Fell: Team Topologies. But your book is a little different than those other books in that it's not really designed to be read all the way through. You can read it all the way through, but if you don't have the time or if you're a higher-level manager and you just want to try and understand, "Oh, this looks more like my team." So talk a little bit more about how the book is structured.

Manuel Pais: I would say ideally you would read the book end to end the first time and then you can use it as a reference in terms of if I am an engineer on a platform team, for example, then I can go back and understand what kind of behaviors should I be expecting and ways of interacting with the others.If I'm a business manager, maybe I want to read – so the first part of the book is all around concepts that have been around for quite a long time like Conway's law, Dunbar's numbers, all these research-based aspects that actually influence the ability of teams to deliver.So from a business point of view, you want to understand that as the background to what we talk about. And then the second part of –

Sam Fell: Prescriptive.

Manuel Pais: Yeah. So we talk about the topologies, the interactions, and then the evolution and this idea of becoming a sensing organization that can understand the environment and morph like animals that camouflage or change their shape to fit in better with the environment.

Brian Dawson: Awesome. And so I have another pressing question that struck me when I was walking, and I have to ask. So you're based here in Lisbon, right?

Manuel Pais: I'm actually in Madrid, although I'm from Lisbon.

Brian Dawson: You're from Lisbon, okay. So is it true that European developers are just cooler?

Manuel Pais: As a European I would have to say yes.

Brian Dawson: Yes, absolutely. So any final thoughts for our listeners?

Manuel Pais: Talking about the book again, but I think have a look at the book and the ideas in there because I think they fit. Different roles will get some value from different ideas we talk about in the book. But just in general, the idea of being clear about ownership and understanding who needs – are you consuming or providing a service and software and to who? Who are your users? Who are your –

Sam Fell: Suppliers and consumers.

Manuel Pais: – customers? Interestingly, that's still something that's not always very clear, especially inside organizations.

Brian Dawson: Well, I'd like to thank you not only for our conversation here today. And thank you, Sam, for putting this together and joining. But I want to thank you for the work that you've done. Again, I do think it's really important that you have captured and qualified this stuff, categorized it, and it's gonna make a real difference. I look forward to hopefully catching up with you later in the show or after the show and continuing the conversation.

Manuel Pais: Sure, and Matthew Skelton as well. Thank you for your kind words.

Brian Dawson: All right, so that concludes this episode of DevOps Radio live from DevOps World | Jenkins World in Lisbon with Manuel Pais, author of Team Topologies. Make sure you check out the book. Check out his homepage as well as that of your colleague, Matthew Skelton, right?

Manuel Pais: Yes, or teamtopologies.com. Then you will find all the information.

Brian Dawson: All the information. All right, awesome. Thank you, and hopefully you enjoy the rest of your show.

Manuel Pais: I will.