Episode 074: High Performance Team Structure | CloudSkills.fm

Mike Pfeiffer on April, 30, 2020

In this episode I catch up with Manuel Pais, DevOps and Delivery Coach, Consultant, and co-author of the book Team Topologies.

Need help restructuring your teams? You can schedule a time with Manuel via this link for a 30 minute discovery session.

Don't forget to subscribe to our mailing list at cloudskills.io/subscribe for weekly updates, exclusive training, and advice on how to amplify your career.

Full Transcript:

Mike Pfeiffer: All right, everybody. Welcome back to another episode of the CloudSkills.fm Podcast. Super pumped to have you on this episode, and I'm excited about the guests that we have today. Manuel Pais is here. He's one of the co-authors of the book, Team Topologies. It's been basically voted as one of the best new management books by Book Authority. It's got a ton of awesome reviews on Amazon, and I'm a huge fan of this one. Manuel, how's it going?

Manuel Pais: Good. Thanks so much for having me, Mike. Thanks for pronouncing my last name correctly. That's a plus. Thanks for having me.

Mike Pfeiffer: Yeah. I'm excited to have you here, and I love the book. I've had the book sitting on my desk for a couple of months now, and I've been able to get through pretty much most of it at this point. I think the message and the takeaways are huge. There's so many companies right now that are trying to figure out how to move faster with getting their software delivery and all of these processes.

Mike Pfeiffer: It's a really interesting time, and this book is really timely. And I'd love to get into the background on everything that's in this, but maybe you could share with us what you do, how you got into the industry, maybe a little bit of your backstory, and then we can get into the book.

Manuel Pais: Sure. I would just like to mention, one of my favorite kind of compliments we got on the book was from Jeff Sussna who wrote the book Designing Delivery, and he said Team Topologies, our book, does the homework around DevOps that other books have not covered before, which is how do you organize teams and kind of the organizational design aspect of DevOps and just efficient software delivery in general. I thought that was quite interesting.

Manuel Pais: My background is, as you know, in computer science. I started in the industry about 20 years ago, and I moved through different roles from developer to build and release engineer to QA, to the team lead, and then eventually ended up in the consultant path around continuous delivery in DevOps because that's really what triggered my passion for helping teams work more effectively beyond just tooling and practices, which obviously are important, but especially when I started doing consulting, we would often see... I worked together with Matthew Skelton, the other author of the book, and we would often get clients asking, "Okay. Can you set up a new deployment pipeline using some better tooling?"

Manuel Pais: Often, we could do that, and it would help to some extent, but what we would end up discovering is that they have limitations in the way that teams were set up or the kind of incentives that each team had. Many times, they were working as islands almost. Each team, their own island perhaps. I'm sure inside a team, they tried to be as efficient as possible. But overall, it was not really conducive to efficient delivery of software or services.

Manuel Pais: That's where the ideas for the book started to gain form as we saw the things that were happening and we were trying to help his clients with patterns around how to set up their teams and especially the interactions between teams so that you have fast-forward delivery with quick response to incidents and fast feedback. That's kind of the background a little bit.

Mike Pfeiffer: Yeah. That's really cool. I'd love to dig into that. I think the book does an amazing job of really highlighting a lot of what you're just talking about there. The first section where you guys kick things off, there is a discussion about the problem with org charts and how like the communication structure of your organization is dictated by the systems design. Could we talk about that a little bit because that seems like that's a recurring theme that is consistent throughout the book.

Manuel Pais: Yeah. We wanted to highlight the fact that org chart is omnipresent in every organization, and there are good reasons to have an org chart, so you have a picture of how you're expecting things like reporting to happen and hopefully also what's going to help you align strategic goals of the organization with the work that the teams are doing on a day-to-day basis. That's all valid reasons to have an org chart.

Manuel Pais: But the problems start when people interpret the org chart as this is the way we're supposed to communicate. If I mean this one line of the organization, then I'm only supposed to work and communicate with other teams in my line of the organization. That's where problems start. One of the references we use for the book is called Team of Teams.

Manuel Pais: There's a very good illustration of the fact that if you want to kind of responsive organizations, you have to move away from the org chart as a communication tool or a representation and actually understand that what we need our networks, most of the work that we do these days in modern software delivery with complex systems with a lot of dependencies, with external dependencies, internal dependencies, it requires a lot more entertain communication and dependencies and building networks inside the organization to resolve and to address complicated problems that typically one team won't be able to deliver.

Manuel Pais: That's kind of the problem, the main problem we talk about with org chart is that the actual kind of value structures in the organization are not represented in the org chart is something that is much more organic, and it needs to be more organic because of the pace at which we changed, the market changed, the technology changes. You can't expect that whatever was your org chart yesterday, it's going to be still the same. That's going to be the communication that you need for the next six months, the next year and so on.

Mike Pfeiffer: It seems like every corporation goes through that process of annually almost reorganizing their teams and basically thinking that's going to make a difference and then you just go through the process and realize you're just kind of back where you ended up with. One of the things you guys talk a lot about in the book is rethinking your team structure and actually doing smaller teams to reduce the cognitive load for the people on the team. Is that something that you've seen just like in the field in practice be challenging for customers that are trying to rethink their team structures?

Manuel Pais: Yes. In fact, in terms of the size of the team, what we're saying is that there's an effectively a limit on how big a team can be and work effectively. There's some research called Dunbar's numbers from Robin Dunbar where he found... His work is based on studying several civilizations. It's not just kind of the modern days, but looking at how the villages were formed in the ancient times, how groups of people got together and why, what size.

Manuel Pais: We found some interesting kind of trust boundaries and for the deep trust that you need inside a team to be high performing, you're limited to, in his work, is up to 15 people, but even 15 is quite hard for software delivery. We know that stock increased communication overhead and you start having internal dependencies inside the team.

Manuel Pais: Typically, it's around seven plus minus two. Starting from that kind of constraint, if you like that, that's the size of team that makes sense. Then, yes. Then, you need to fit the responsibilities and the work and the size of software they're developing, delivering software to the size of the team, to the capacity of the team in terms of they need to really be able to, on one hand, understand enough, well enough and be able to build and run their services efficiently.

Manuel Pais: We need to restrict either the size of the software they're responsible for or the kind of, in general, the responsibilities that they have as a team to match their cognitive capacity. Then, what we've seen also is that we have a couple of case studies or examples in the book where organizations have seen that if they even break down into smaller teams, in some situations, it can help even further, and one of the reasons is if you have smaller teams and you obviously need to reduce the kind of responsibilities that they have, it tends to tie in well with the…

Manuel Pais: It tends to tie in well with the ideas from ... What are the motivational factors for knowledge workers? If you read the book Drive from Daniel pink or some of his work, he says that it's autonomy, mastery and purpose. And so we have a couple of examples in the book and in general, we're seeing smaller teams become more ...

Manuel Pais: First of all, it's easier to work as a team. You don't need even a real hierarchy inside the team. Perhaps you don't even need a team lead if it's three or four people and they can have a stronger sense of, "We understand we have a common purpose, we have autonomy."

Manuel Pais: Because the domains of responsibility are smaller and so they can focus more as well and increase their mastery. Obviously, it's not for every situation but it's something to think about that often many organizations do the reverse. They're just looking at, "Okay, this team is working well, let's give them more work."

Manuel Pais: And then when the team has more work, they need to typically ... They need to increase because they say, "We need more people to respond to this work."

Manuel Pais: And so changing that around and thinking, "Okay, let's restrict the amount of responsibilities and keep the team small but it's a repeat pattern of having coherent, well-functioning teams and that tends to be much more valuable.

Mike Pfeiffer: It's definitely my experience working at Amazon. I was having flashbacks there while you were talking about some of these things. When I was at Amazon, it was ... There were those talking about two pizza teams and basically meaning if you can't feed the team with two pizzas, the team's too big and having the autonomy and stuff. Seeing it action for me, was a career changer. Actually seeing it implemented and that's ... When I'm working with customers, I'm just like, "Man, I can see where you guys are struggling."

Mike Pfeiffer: And it's frustrating when they're there to do a technical solution. Going back to your point earlier, from the beginning of the episode. And sometimes actually getting to that high performance clip in your team has less to do with the tech and more about the things on the work chart that you can't see, like the purpose of the team, the interactions and all that. I love that. It sounds like an anti-pattern is a big team. Is there other anti-patterns in terms of the team topologies out there that people should start thinking about?

Manuel Pais: Yeah, just on that previous point, even Google has done a lot of research around what makes performing teams and one of the key conclusions they got to is that it didn't matter so much who was on the team. And then indirectly, it didn't matter as much how well their hiring a process was to find the best talent because then it depended a lot more on which team this person ends up.

Manuel Pais: And so if the team is performing, of course there's going to be a boost but if the team has issues, such as being too big or having too many responsibilities, it doesn't really help that much to have the best engineer if the team is not able to perform because of other reasons. Yeah.

Manuel Pais: I think other anti-patterns, a common thing is ... And also related to this, if you want to restrict the size of teams because we understand why there's this human limitation in fact, to how big the team should be then ... When we look at the system architecture, we should consider also the ideas from Conway's law, right. Conway's law tells us that ... And it's coming from a paper from 1968, I believe. It's been around for a long time but it became more known in the last year, especially with microservices.

Manuel Pais: And it's the fact that whatever team structures and communication paths you have in the organization, they're going to have a strong influence in the emergent architecture of the systems you are building or delivering. And so it's ... In fact, it's a mirroring effect. And the conclusions for that is that on one hand, yes, if we have smaller teams, the components in our architecture need to be smaller as well. We need to find help to create more independent decoupled components. And so the teams are also as decoupled as possible, not hundred percent but we tried that it can be more independent.

Manuel Pais: And so that's where microservices as an architecture became also ... It helps but there are also many anti-patterns in how organizations apply microservices but it helps to have smaller components but you need to take the two things together. If you an organization are, "Okay, we want microservices. We understand this is going to help us deliver faster and make things more healthier and more independent."

Manuel Pais: Then we need to look at the teams. If the team's alignment and the structures are misaligned with this type of architecture, then you're going to be fighting to get to microservices or whatever you want to achieve because of Conway's law, that in the end, the team structures are going to show up and emerge in the actual architecture.

Mike Pfeiffer: Yeah. That's fascinating stuff. And I was actually watching one of your guys' talks. I think it was DevOps Enterprise Summit in 2019, London. And you guys did a talk, something like, "Forget monoliths versus microservices."

Mike Pfeiffer: Yeah. All right. And, "Focus on the cognitive load."

Mike Pfeiffer: Because that's really, if you start thinking about it, that's one of the big benefits from microservices, it isn't necessarily the tech, it's that the teams, to your point, are more focused maybe and since they're a smaller team, maybe they have more autonomy and maybe now the systems ... The team structure now, is actually the lead system and not the org chart, right.

Manuel Pais: Yeah. Yeah, definitely. If we can look at ... It's also the idea of looking at the team that's the unit of delivery or if you like, the unit of your architecture, rather than the more technical side, whether we're using microservices or so or what have you, is let's align the units of the architecture with the teams as a unit as well because that's what you want to be. You don't want more fine grained ... You might want more fine grain architecture than that or design but you don't really ... That's not the starting point.

Manuel Pais: The starting points for each team, if it's a long-lived, stable team, which is what we advocate in the book, you want each of those units to be able to be high performing and to be able to quickly make changes, respond to customer needs and all of this fast flow ideas. And so the team needs to have responsibility for a unit of the system, if it's a larger system that is as decoupled as possible from the rest.

Manuel Pais: It might be that it's one microservice, if you want to call it that. Or it could be that the one team owns two or three microservices if they're really small but it doesn't matter as much as focusing on, "Does the team have enough capacity to really fully understand and build and operate this service or set of services?"

Manuel Pais: Because if they don't, then everything else is affected. And if you look at the key metrics from the Accelerate book from Doctor Nicole Forsgren and Jez Humble, Gene Kim, so the metrics they talk about, they all get negatively impacted if cognitive load is too high for a team. Things like lead time, deployment frequency but also mean time to repair or to restore service and change failure rate. Typically, they'll go down if the team doesn't have a good enough grasp of the software they're responsible for.

Mike Pfeiffer: Yeah, that's a good takeaway, that you can actually measure this as long as you're tracking those key metrics. That's insanely cool. And so I know that you get into the book, interactions are important, the team behaviors, the interaction between teams and stuff like that but you also share several ... Or I think it's four fundamental team topologies, right, in terms of thinking about designing based on those four different concepts. I'd love to get into that maybe a little bit. I'm going to definitely ... In the show notes for everybody listening, we'll have the link to the book. This is something that I've shared with our community internally at Cloud Skills that, "Hey, this is recommended reading you guys."

Mike Pfeiffer: And so I'd recommend everybody listening out there, go check out a copy of this book but Manuel, if we could talk about maybe those fundamental team topologists from a high level, the ones that are covered in the book, I think that'd be a huge takeaway for everyone listening.

Manuel Pais: Sure thing. In line with what I was saying, that if we want this ... There are many names for this teams, product team, cross functional team, autonomous teams. Going back to the ideas of the Agile Manifesto, that we want these teams to be able to deliver value on a regular basis, we call them in the book, one of the fundamental typologies is stream-aligned teams. There are a few reasons why we call them that or ...

Manuel Pais: Align teams. So there are a few reasons why we call them that or why we gave them a specific name. The main reason is that what we see in many organizations that are different streams of work and they're not always necessarily a product or a set of features. There are other types of streams of work. It could even be around compliance, for example. It might make sense to have a team aligned to a stream of work around making sure we are compliant in terms of the software and the industry that we work for. But essentially in the way that we expect these teams to work and to behave is this idea of autonomous product teams, cross functional with multi-skill. But that's kind of an ideal, right? For a team to be autonomous, it's not just telling them you're autonomous now, because that's not going to... That's nice as a first step, but that's not going to be enough if they don't have the necessary skills and the competencies, and often they don't have the time to build the skills because they're already being pressured to deliver on their own features and products.

Manuel Pais: So how do we help those teams actually still be autonomous, still have ownership of end to end life cycle of their product or service, but in a more pragmatic way. And what we found is these other three typologies that are essentially a support system for the stream aligned team product teams. So we talk about platform teams, enabling teams, and complicated subsystem teams. And then for each of those, it's not just the name or the composition of the team, it's actually how we expect this type of teams to behave and to interact with others that makes the difference. So the platform team, for example, you would expect them to be looking at the platform as a product, an internal product, but with the same approach where we want to develop platform services perhaps around telemetry monitoring or CICB, whatever it is that the stream teams need. We're going to provide these services, but we need to look at them as product so we know that this other teams are our clients, we need to get regular feedback from them. We need to collaborate with them to understand what they need what makes a good developer experience for these teams to use our platform.

Manuel Pais: So all these things that you would expect from a customer facing product team as well. So that's for platform teams. So enabling team is going to help essentially upscale the stream teams and help them gain knowledge in a much more efficient or faster way, because if we can have a small team of experts in some domain where we have a gap in our teams, let's say for example test automation for mobile or infrastructure as code, whatever it might be, that the stream teams are lagging behind because they haven't had the time and the opportunity to learn. Then you could have, instead of all the teams requiring an expert in infrastructure a code, you could have a small team that is going to facilitate that knowledge through whatever means makes sense to either more classic trainings or e-learning or setting up quick examples or simple examples for the teams to understand. Helping them through the good practices in this domain and the tooling as well. So essentially reducing the learning curve dramatically for stream teams to be able to gain these capabilities that they need for end to end delivery and operations.

Mike Pfeiffer: So one of the things going through my head there, actually there's a lot going on there, but I'm curious to know... Obviously a lot of what we're talking about here is predicated on the fact that we've got software teams internally, we're building and releasing software. The stuff in your book, could this be used for other enterprise companies that might not be doing software development maybe? Maybe they're still doing off the shelf software, but they're still maybe not going as fast as they want to or maybe now they're embracing more software patterns because things are virtual?

Manuel Pais: We think so. One of the aspects is that you might have... And we start seeing more and more systems or collections of systems where if you really care about the customer you need to make sure the experience for the customer using different products that they're offering is consistent. If there are different entry points and touch points between the customer and not just the software but your organization, that's something that Jeff Sussna talks a lot in his book Designing Delivery, that you want to make sure that whatever promises you make to the customer, that you fulfill them. And this might go beyond the scope of the software delivery teams. So you might have what we call service experience teams, which might not even develop any software, and they might be focused on what I just said, making sure the experience for the customers is consistent, is intuitive, is responding to their needs.

Manuel Pais: So that's one approach or one aspect of applying these ideas beyond just software. And then we think we don't have... I've talked to some people that have told us this could actually perhaps be applied more broadly in other domains even areas like HR or finance, at least some of the patterns we could start applying that. I don't know, what will be a finance platform team, perhaps they're focusing on allowing the internal teams in the organization to be more independent and be able to do whatever procurement or whatever services they need more easily or accounting, et cetera. It's early days in terms of a broader picture of how these patterns could be applied outside of software delivery, but we think some of the patterns at least could be more broadly applicable.

Mike Pfeiffer: That's great. The reason I wanted to know is I'm sure there's a lot of people listening that may be in that position. So the good news is there's still value here if you're not writing software from scratch and thinking about reorganizing teams, and on that point, have you gotten involved in that process or maybe heard from other companies about backstories on actually going through this process? Is it a painful process to reorganize based on this framework or any common pitfalls?

Manuel Pais: We're learning at the moment as well. The book, if you like, is a collection of patterns that we ourselves saw working with clients, but also we validated with other examples from people. So some of them are case studies in the book and others that we just we saw from articles or talks and this makes sense. They're using a platform patterns that we're talking about or they're using enabling teams and things like this. But in fact, in typologies as a whole if you like, is something new and that we came up with the book and we have seen... It's interesting because we see a wide range of roles of people that are interested in the book from more internal to the team, people who are just an individual contributor in the team or job coaches that are more interested in the aspect of how do I a better performing team, all the way to C level or heads of department that have a more... They understand the ideas in the book, they think it's going to help them and they already have a broader view of how they can evolve.

Manuel Pais: So we've had a couple of cases where people came to us already with their own picture of how they want to align their current teams to the typologies, how they want to set up the right kind of interactions and basically have an idea of where they want to go. One of our goals for this year and just in general is to collect case studies that we either participate or we hear about of organizations applying different typologies as a whole, if you like. And we're going to publish that on our website teamtypologies.com, and any other learnings that we go through because I'm sure there will be situations where someone says, "This idea makes sense but it didn't work for us because of X." We want to collect that and learn from that. But yeah, there are organizations starting at the more individual team level or department level and there are other organizations that are looking at a bigger picture because they have buy in already from senior management. So it depends a lot.

Manuel Pais: Senior management. So it kind of depends a lot.

Mike Pfeiffer: Yeah, that makes sense. And it kind of goes back to the tech stuff, too. A lot of the tech stuff is emerging Cloud and everybody is trying to do things in a different way than they have in the past. And so it's almost like the most progressive companies are already there with the tech, they're already there a lot of times when it comes to the team topologies and the interaction between the groups. But not everybody's Netflix, right? So the rest of the world has to catch up. But that kind was the last, I think the third part of your book really gets into interactions and talking about essential modes of interaction and behaviors of teams, and things like that.

Manuel Pais: Yes. And also the evolution side and that sensing when you need to evolve is a key aspect. So it's interesting you mentioned Netflix, because also Netflix, it's not like they have it all figured out and they're just, "Okay, this is ..." And that's the problem with major organizations that they're trying to do the big reorg that you were talking about earlier where we said, "Well we're just going to follow the Spotify model.", or, "We're going to follow Safe.", or "We're going to follow whatever framework." And they, in a way, kind of naively expect that there is an end state. That I do this transition, one step transition, and I'm in a better place. And like you said before, often that doesn't happen and then you get people are not motivated by whenever they hear there's another reorg. They kind of cringe, right?

Mike Pfeiffer: Right.

Manuel Pais: And that's part of the reason because it's too ... We need the organizations to be much more adaptive. So Netflix, actually, we got contacted by people from Netflix or I think there was a tweet where they said they were really thankful for the DevOps Topologies, which is kind of the precursor to Team Topologies. And they use that internally to evolve and to understand where are we now, what do we need to do to deal with whatever challenges we're facing at the moment. And so effectively, what you need is the organization to be much more of a living organism in the sense of we need the teams to be able to evolve and adapt and interactions. And so that's why we find that the fundamental topologies I talked, about as well as the interaction patterns, so we talk about three core ones, which are collaboration, providing X as a service, and facilitating.

Manuel Pais: With those topologies and interaction modes, you can actually get organizational landscape, if you like. You can have kind of overview of which teams do we have, what is their purpose, what are they working on? If they're aligned to these typologies and the interactions. And then we can try to address, we know that we have gaps around this domain and that domain and what do we need to put in place to address that? Do we need more help from perhaps a platform service? Or do we need more enablement around the capabilities of the teams? And then you can evolve and you can sense when things are not working for you.

Manuel Pais: And as the book, there's a book called Unlearned from Barry O'Reilly which I think is quite interesting. He's talking about what worked for us until now might not be working in the future. Even a company as successful as Netflix, if they didn't evolve their organization as well when they were facing challenges they wouldn't be where they are today.

Mike Pfeiffer: Yeah. This is fascinating stuff. I can't wait for everybody listening to go out and read a copy of Team Topologies. And Manuel, as we're wrapping up this episode, is there any other resources we should send people to to check out? Obviously, the book is the primary one. I know you guys have a website for it. Anything else that we should send people to take a look at.

Manuel Pais: Sure. We have, besides the book, there are a few other resources. We are actually right now working on what will be a free workbook around remote first team interactions because of the current situation with the pandemic and so many organizations that are kind of new to remote working. We want to take some of the aspects of Team Topologies and give more examples and expand on some of those ideas specifically for remote working because the interactions between teams in a remote context also change, and so we need to be careful about that. That's one thing that's coming out hopefully in May.

Manuel Pais: We also have recorded, we have a course around team topologies for project managers, which is kind of a self paced course through the PMI Institute. And in general, we do training and assessments where, like everyone else, we're moving all our training and assessments to remote first. But the website, as you mentioned, teamtopology.com has all that information, so if people are interested just reach out to us.

Mike Pfeiffer: Awesome. So much good stuff in there. And so for everybody listening, check out the show notes, go get the book, Team Topologies. Manuel Pais, thanks so much for being on the Cloud Skills FM podcast.

Manuel Pais: Thank you, Mike. It was fun.

Mike Pfeiffer: Hey everybody, if you want to keep up with what's going on in the Cloud, we have a weekly email newsletter called Cloud Skills Weekly, and you can subscribe for free by going to cloudskills.io/subscribe. Every single week. I'll send out my five tips and resources that cover what's going on in the Cloud, we'll focus on Microsoft Azure, Amazon web services, Google Cloud, and more. Topics will include things like Cloud architecture, application developments, containerized applications, DevOps and automation, certification strategy, career tips, and more. So if that sounds awesome to you, head over to cloudskills.io/subscribe and join the Cloud Skills weekly newsletter today.

Subscribe to the CloudSkills Weekly Newletter

Get exclusive access to special trainings, updates on industry trends, and tips on how to advance your career in the tech industry.