Charles Humble talks to Team Topologies co-author Manuel Pais. They discuss how the rapid adoption of Team Topologies may be being driven by companies seeking a new competitive advantage as DevOps and Cloud become ubiquitous; applying software engineering thinking to organisational design; the challenges of cross-team collaboration in a remote context; and using Team Topologies patterns for remote working.
Subscribe: Amazon Music | Apple Podcasts | Google Podcasts | Spotify
About the interviewee
Manuel Pais is co-author of Team Topologies: organising business and technology teams for fast flow. Recognized by TechBeacon as a DevOps thought leader, Manuel is an independent IT organisational consultant and trainer, focused on team interactions, delivery practices and accelerating flow. Manuel is also a LinkedIn instructor on Continuous Delivery.
Resources mentioned
Remote Team Interactions Workbook
Susanne Kaiser on Joining the Dots Between Wardley Mapping, Domain Driven Design and Team Topologies
Team Topologies Academy
Team Topologies Book
WTF is Cloud Native? Recommended Reading List 2021
Full transcript
Introduction
Charles Humble:
Hello, and welcome to the third episode of "Hacking the Org", the podcast from the "WTF is Cloud Native team?" here at Container Solutions. I'm Charles Humble Container Solutions Editor in Chief, and for this episode, I'm joined by Manuel Pais. Manuel is an independent IT organisational consultant and trainer focused on team interactions, delivery practices, and accelerating flow. He's also a LinkedIn instructor on continuous delivery, but is perhaps best known as the co-author of the book Team Topologies alongside Matthew Skelton. The two of them have just published a new remote team interactions workbook that builds on some of that thinking, setting it in a new remote working context. Team Topologies is a book that's been referenced by both our previous guests, Susanne Kaiser, and Randy Shoup. It's also on the Container Solutions recommended reading list, which I will include a link to in the show notes, and it is a book we at Container Solutions reference frequently on our own client engagements. I'm absolutely delighted to have Manuel join me on the podcast today to talk both about it. And the new remote interactions book. Manuel, welcome to the show.
Manuel Pais:
Thank you, Charles. It's also a pleasure for me to be here. We've known each other for many years. It's always nice to have a conversation and thanks for the nice introduction.
What has driven the rapid adoption of Team Topologies?
Charles Humble:
Pleasure. So I've been honestly astonished by how quickly and broadly the concepts of Team Topologies have been adopted.
Manuel Pais:
Me too.
Charles Humble:
And I was curious as to why you think that might be. It's unusual in our industry for something to be picked up that fast, I think.
Manuel Pais:
Yeah, we didn't really know how well the book was going to be received and we felt there was a need for more clarity around how to think about the organisation, evolution and not just types of teams and interactions, which is the fundamental patterns in the book, but more broadly, how do we evolve the organisation so that we adapt to all the challenges that we see around us. And possibly part of the reason of the interest has been, obviously, in the last couple of years. The book was published late 2019, we had a lot of changes and social political, et cetera and so, that even stressed more the need for organisations to adapt quickly and what was happening was the existing models while useful were not enough. And Team Topologies is probably not enough that we need to continuously find more about how organisations work, how we help people to be more productive and how do we organise our teams around that?
Manuel Pais:
So I think combination of the challenges in the last couple of years, plus lack of really more concrete or analytical body of knowledge around organising. So there was of course the Spotify model and Agile, DevOps, but there, wasn't a structured view of what can we do? What are some building blocks for us to think about? Okay, if we have these problems or this challenges in the organisation, what can we do to deal with it where we're not relying on sometimes solutions that don't scale very well—Like we just think, "Oh, we're just going to hire more people." That doesn't usually scale very well. That's probably not the most effective way to adapt the organisation. So I think those are some of the reasons probably there others we don't know about. And I would also say the IT Revolution did a great job. The publisher, because their target audience, they also run the DevOps Enterprise Summit conferences. And so they really have a good audience that listens to what we were saying and other books that they've published.
Charles Humble:
I wonder as well, if it might be partly down to companies seeking the next competitive advantage. There's this idea that companies that adopt things early and that sort of innovator/early adopter stage, they do that because they're looking for competitive advantage. And the case of DevOps and public cloud. Obviously it varies a bit by industry and location. But in general, adoption is broad enough at this point that there isn't necessarily competitive advantage there. At Container Solutions we talk about this idea of Cloud Native being as much about how your organisation works as it is about the technology—containers and so on. So I wonder whether you think that in effect culture or company organisation is where the next competitive advantage might come from and then that might in turn explain some of what's driving this rapid adoption of Team Topologies that we've been seeing.
Manuel Pais:
Yes, in fact, more than just me agreeing last year, the State of DevOps report, the one from Puppet Labs came out, I think June last year, 2021. They had that kind of conclusion and they were looking at different organisations and basically those more technical aspects of, "Yes, we need to embrace cloud. We need to adopt DevOps practices, et cetera." Like you said, are a baseline these days. They're not going to make a huge difference. They're going to help you compete with other organisations, but then actually the clarity on the organisational structures, especially clarity on teams, what are the mission of teams, how they relate to each other? Do we have clarity on who do we need to reach out to when we have certain kinds of problems. How do we interact in a clear way that is more productive and we have less conflict and we have more common approaches to do things across the organisation is where we see some competitive advantage today exactly like you said.
Manuel Pais:
Even though Team Topologies has been quite well received, of course it takes time, especially in the larger organisation to get the ideas adopted throughout, and so that was one of the conclusions of their report, in fact. So we can expect that possibly in five, 10 years, that's not going to be an advantage anymore. But at the moment, yes.
Are there any things you wish you’d been cleverer or emphatic about in the original Team topologies book?
Charles Humble:
Just thinking a bit more about the wide adoption that Team Topologies has had. I think it's inevitable when something gets picked up that quickly and that broadly that there may be misunderstandings or misinterpretations or things you wish you were more clear about or more emphatic about in the book. Do you have any of those?
Manuel Pais:
If you don't have haters then you're not successful enough. We're lucky there aren't many. Whenever it's respectful, we try to debate the ideas and try to understand different points of view. And it's true that team topology is actually not necessarily applicable to every organisation, but to a lot. Yes. But there are some specific cases where maybe if you're more focused on R&D that maybe not everything is as applicable, even though we'd still want to probably go fast and have results fast. But going back directly to your question, you can never have it all. So I think the book also the appeal is because the patterns and when we talk about types of teams interactions, and then we talk about some constraints like cognitive load, Conway's Law, et cetera, all those things are fairly easy to understand and people can quickly relate that to their own experience.
Manuel Pais:
So I think that's also why the book was adopted quickly. The part that I still see missing is the evolution part. Because I think sometimes people get the main patterns from a talk or from some article. So they just focus on the types of teams interactions. But part three of the book is all about the evolution. It's not just at one moment in time to say, "Well, we should have this stream-aligned team. We should have this platform, et cetera." What's key and especially for the interactions is, how do we use that to evolve, to detect new gaps, to detect new challenges and then adapt. And so that's maybe the thing that we could have put more at the forefront, but it's in the last part of the book. But maybe we should have brought that to the attention earlier in the book so people realise it's not just about core patterns, even though that's really important as well. But things evolve and they take other shape as you get more rich and that's just normal as well.
How do you avoid reorg fatigue setting in?
Charles Humble:
Yes. Something I've learned from my many years in the industry is that obviously large scale company reorganisations are very complicated and difficult to get right. I've worked in a lot of organisations where they've been done and they've been, disastrous. And I think everyone listening to this podcast is probably familiar with the idea of continuous delivery and software and why it tends to be generally a better approach than a sort of big bang type approach. And I think Team Topologies is advocating that same idea at an organisational level, but then how does that work in practice? How do you avoid reorg fatigue setting in?
Manuel Pais:
So, that's a difficulty when we have organisations that are really into Team Topologies. Actually this might seem weird, but actually it's like trying to slow them down a little bit. Because we don't want them to do another big reorganisation. I think it's a matter of scale as well. We've seen examples where at obviously startup, but scale up at certain size. If you get people on board, you can do things more quickly and more broadly. We have some examples on our website of companies like PureGym or Wealth Wizards, which are at scale up stage and they were able to take broader change to the organisation and was quite successful. But for large organisations, we effectively try to tell them... And going back to this idea of evolution is like when you're changing and yes, you might be adopting some ideas from Team Topologies you still need to learn. It's not like these are absolute truths, you're just going to apply them and everything's going to be much better.
Manuel Pais:
You have to try to be agile with your transformation, apply this to maybe a small number of teams. Try to get the actual patterns so when you read the book, it might seem easier than it actually is to get teams to understand, what team are we, how should we relate to others. And then change those things on a gradual basis and change the way teams interact to be more intentional, to be more mindful in the sense of, 'Why are we having this interaction? How do we know if we're reaching the goal of this interaction or not? And if we're not, then what does that tell us?" so there's always a process of learning even if you're trying to transform the organisation.
Manuel Pais:
And so it's going to be a bit slower in one way, because you're not applying this big change to the whole organisation at once but you're going to get faster feedback. It's the same idea that DevOps told us about and other movements of "get fast feedback". So we start small and get quick feedback on, does this work or not? Are there things we need to adapt to make it work for us? And so then you take smaller steps and then as you get validation and you get also internal internal wins that you can show "we try this and we had this benefits", then it's easier to bring it to the rest of organization and ideally have the rest of organization get interested in it. And that's sort of what we've seen even in organisations quite large, where we're not directly involved, but we see even from the way they increase their interest, for example, in our online training, we see that this is growing inside that organisation and that's quite nice. It means it's more organic and yeah. Being picked up by other parts of the organisation
Can you talk about applying software engineering thinking to organisational design?
Charles Humble:
More generally. I think one of the things that I really love about the book is how you've applied software engineering, thinking to organisational design. Can you maybe talk a little bit more about that?
Manuel Pais:
Yeah, that was intentional also because both me and Matthew have a software engineering background. And in fact, in the beginning we saw more software engineering type of people pick up the book. Now we see more broadly being picked up. So yes, some of the core principles, software engineering around loose coupling. If you want to be able to evolve quickly, you need loose coupling, high internal cohesion. These are principles that we can apply to teams as well it's not just about the software. And so when we apply this to teams where we have loose coupling, but that also then brings us to, "Okay, we have loose coupling of what?" Well, we need to understand what are the value streams.
Manuel Pais:
And we need to understand within the value streams, what are the actual products or even sub value streams that we can then align teams too. And so when we do that alignment, we start to get teams with more clarity of purpose of who are their customers, what is their mission, et cetera. But when you take a step back we are applying these principles of loose coupling and high cohesion inside the teams. And those are helpful principles to help us think about how we're organising teams.
Don’t Repeat Yourself and Coupling
Charles Humble:
I think that's actually a really interesting sub point there, which I've seen play out a few times now. So when I started working in IT, there was this huge emphasis on having common components in object oriented terms. The whole don't repeat yourself thing. And although I think it probably is possible to avoid this, what we used to tend to end up with was huge team coupling, where everyone was incredibly dependent on a small number of people that were maintaining these common components that were then being used throughout the rest of the software organisation. And then we got a shift to autonomous teams, I think partly inspired by Dan Pink's Drive book. And that allowed us to move faster, but it also meant that a lot of common functionality gets written over and over again in different places around the organisation. I'm curious to know how you sort of see that and how you see that playing out maybe at an organisational level.
Manuel Pais:
So don't repeat yourself is interesting. And I say this as someone who believed very strongly in that principle and I think there are different shades to it. And I did believe, 10 years ago, that we should always be aiming for, "Don't repeat yourself." But I think both, like you're saying in practice we've seen lots of problems that come up from trying to apply that principle to broadly. And also with my own experience, I started to realise, well, we need to have clear scope for this principle. If we're talking about one service or even one system that we have in a software based system. Yes, we probably want to avoid repetition and we want to avoid having code copied in multiple places with small variations and then gets very difficult to test or even make sense of where did this all come from?
Manuel Pais:
So we definitely don't want to have that. So I think at the unit of the service or even the system... yes, you don't want to repeat yourself. But then when we look at the level of the organisation, there might be actually very valid reasons why we might have duplicated functionality, if you like. For example, companies are more and more present around the world. Because they're less barriers and so on. One thing that organisations that really want to succeed in different markets is to understand customers in different parts of the world, expect to interact in very different ways. Because of their culture, because of also technology, even though that's becomes less of a differentiator. We know that in regions like Asia, for example, it's much more mobile first, even though now that's basically all over the world, but used to be different.
Manuel Pais:
But even from a cultural perspective, the way people in different parts of the world will want to interact with your brand, with your services is different. And so if we have a company that is around the globe probably makes sense that you have teams that are providing very similar service, very similar functionality. Let's say in US or in North America and in Asia, but you actually need very different approach. And you need the teams to understand who are the customers that we're targeting in this region and how do they want to consume our service, et cetera. That's one example. There are more where it seems counterintuitive, especially for us as software engineers. , we are repeating things. Yes. But there is a value to that and we can see it because we are able to bring more benefit to the organisation.
Manuel Pais:
It's just something we have to live with. The problem, I think is always accidental, which at a level of a system can be within different parts of an organisation. If it's intentional, because we know why we need to do this repetition because we have different markets or we have different types of customers or regulations, what have you then that should be okay as long as we can show the value. When it's accidental, that we're just not paying attention and things get all messed up with technical debt, et cetera. Then obviously that's not a good thing.
How do you get cross-team collaboration to work in a remote context?
Charles Humble:
Now you mentioned that the book came out late in 2019 at the top of the show and obviously that's pre pandemic. So the pandemic happens, everyone shifts to working remotely. And now we're at a point where there's some debate going on in my own country. And I think wider about whether that's a good thing. I generally think that it is. And I think that some of the counter-arguments are nonsensical. There's an argument that says, "Well, lazy people won't work if they're not in an office," but lazy people can look just as busy in offices as they can at home.
Charles Humble:
So, what you do is you measure the output of your team and then you can tell whether people are actually working or not, and then it doesn't matter where they are. And I just think it's a silly argument really, but there are undeniably challenges with remote work. And one of those challenges I think is that it is pretty straightforward to get collaboration working within a team, but it's much harder to get cross team interaction to work. Would you agree with that? And if so, do you have any thoughts or advice on it?
Manuel Pais:
That's partially why we wrote this workbook that came out... Well in Europe, just coming out now end of May, is effectively what you just said. This was at the start of the pandemic. Then it took longer than we wanted to get the workbook out. But even at start of the pandemic, we started doing a talk about this problem of effectively in the remote context which was new for many organisations. Usually within a team, like you said, you could rather quickly figure out, how do we want to work? What do we want to use—chat tool or do we do video calls? And when et cetera, because those people are working together on a regular basis. But like I said, between different teams, it gets more complicated. It's not that in the office, it was easy or clear actually, but was almost like you were in the office and sometimes things would surface sometimes almost accidentally, but you would surface certain problems or certain things that... Well, actually, we need to get together to address this thing.
Manuel Pais:
It was not ideal by any means, but you did have some touch points that now you don't have in the remote environment. But on the other hand, it brought to light those problems, which I think is a good thing. Now it's clear that we need to be more intentional about how do we work remotely? When should we interact? What is the purpose of this interaction between teams? I think you were talking about competitive advantage of focusing on the organisation, design and structures, et cetera. I think in this remote context, it's even more. I think it's going to be clear that organisations that just adopted some chat tools and basically change their security settings so people can access the systems from home. Let's not name any names. Of course, there are some steps you need to take, but that's just the basic things that you need to do.
Manuel Pais:
And then you need to think about how are we actually helping the teams talk to each other when they need to talk to each other? How do we reduce noise, because then there's also a lot of noise when you have this huge virtual workspaces with maybe hundreds of channels and people are like, "I don't even know where I should be looking at." And so the natural reaction as human beings, they're going to focus even more on their own team and try to stay away from the rest of the world around them in the organisation. We need to be a lot more thoughtful about how do we organise the virtual workspace as well and the tooling to be, as you say, in team technologies to have a team first approach if we want to help teams really be efficient in this remote setting.
How do you think about collaboration in a remote context?
Charles Humble:
There's a couple of really interesting things that I'd like to pick up on there actually. So you said that something that you've seen and I've certainly seen it as well, is that companies will put the basic tools in. So you get like video calling and chat and whatever, but then everyone rather left to get on with it from there. And it's always seemed to me, the tooling is in many ways, the least important bit. I mean, yes, you need the tools in place, but that's simple. How do you think about sort of collaboration in a remote context?
Manuel Pais:
Like you said, tooling, we need the tooling and I expect there's going to be better tooling. In fact, we've had contacts with some companies and startups that want to create better tooling. That is more team focused for remote communications in particular, but we're not really there yet. But you can still do a better job of using the tooling in your favor. So one of the things that you mentioned collaboration specifically and in the workbook that is coming out, these things are not rocket science, for example, adopting some naming conventions for your chat channels, whether it's Slack or Teams or something else where we could, for example, if we know two teams need to collaborate to solve some problem or figure out how we're going to do something, we could create a temporary channel for that collaboration. That's a very simple example of, we clarify these two teams are collaborating for some time.
Manuel Pais:
This is where we expect most of the synchronous communication to happen is in this channel. That's the simplest example where we are trying to reduce noise and promote having clarity. Of course, we don't want also to be too prescriptive and say, "Well, tell every team you need to do exactly this," but we can provide some useful ideas and common ways of doing things that teams can adopt to improve. And that's what we see that teams generally are happy to as long as we're not sort of mandating, but we're saying "Look, here's a way that can help make things clear." They're generally happy to use that because they feel the pain right now of all this channels, all this noise happening. And we don't really know how do we fit in there. And there are other aspects of trust.
Manuel Pais:
And how do you build trust in this virtual environments, et cetera. So these are all things that we can help with by applying some simple patterns and common ways like naming conventions tracking dependencies between teams using the team API that we talk about in the Team Topologies book. And now we give some examples in the workbook of how to apply the team API, to actually evolve the interactions, clarify the channels, clarify the communication patterns. All these things are going to be necessary on an ongoing basis, like with the reorganisation, it's not something that is a one step transformation, we keep improving things. We keep identifying, "Well, there's still a problem here. What can we do to address that?" And it's continuous
How do you minimise additional team cognitive load in a remote setting?
Charles Humble:
Early on in the book, you talk about how remote teams need to over communicate and also the need for a strong written culture in remote, which is something that I've also spoken about quite a bit. But something I've seen happen repeatedly in a remote context is, you end up with too many chat messages, instant messages that become interruptions and which you also touch on in the book, a lack of context to questions. So you have to hunt around all the time with the original message. What advice do you have in terms of managing this?
Manuel Pais:
Yeah, in fact, what happens is we increase cognitive load for teams also on the communication. Not only they typically have too much cognitive load just to do their day to day work and to deliver their services or software, if that's the case, but now we're also increasing cognitive load on communication because there's so much lack of context or there are too many messages, too many distractions. We don't really know how to focus or how to handle all this different stuff that's happening. So, I think my advice would be first start with you with your team and assuming you already have fairly good working practices internally in your team, start looking outside, start looking at what do other teams need to know about us? How can we make this clear? How can we clarify how they can communicate with us?
Manuel Pais:
You can use team API or some other artefact, or just adopt some consistent way where you are helping other teams communicate with you. So, they understand which channels should they use if they have a request for your team or if they need to collaborate with your team, how should they ask for that et cetera? And like I said before, this is going to evolve. You're going to discover over time, "Well, actually we need to clarify this as well. We need to clarify that and just keep evolving that whether you use team API or something else, the way you expose your team to others. So that's I would say the starting point, and you're going to have to sort of promote a little bit, your own ways of working to others and communicating.
Manuel Pais:
It's not going to be from one day to another that everyone. Oh, okay. We're going to look at your team API and figure this out. So you need to do a bit of marketing, if you like, or promoting and evolving your ways of working and how you interact with others. And then after that, hopefully, we see then other teams also start to adopt similar ways of clarifying their communication, how they prefer to be contacted, et cetera. That's the ideal case. It's quite organic that you see you start and maybe other teams already have started and you start to see this because teams realize this is helpful. We start to do it more, but also you can propose, "Why don't we adopt some common naming conventions?" Especially, as you identify problems, you see there's too much noise, too many messages.
Manuel Pais:
You can, obviously, depending on where you are in the organisation, but bring that up to the surface and say "Let's figure out a better way to deal with this," but of course, you need in the organisation to have focus on these principles of reducing cognitive load on communication as well, reducing noise, making sure things are more predictable, easier to find that interactions are more well defined. Those are the principles that you would need to have in place to then look for better ways to communicate in a remote setting.
What are you thinking about in terms of Team Topologies now?
Charles Humble:
That's all very good advice I think. I'm going to add one more in which is from the first chapter of the book, which is the idea of making messages self contained. And I really like this, partly because... We were saying earlier how Team Topologies applies software engineering thinking to organisational structures, and, in this case communication. And I just think it's interesting. So in the book you give the example of, instead of saying what do you think, which requires a context switch and maybe scrolling around to answer the question for yourself of what do I think about what? A question like, "Do you think we should switch from component A to component B due to the performance problems we're seeing with component A?"... gives the reader of the question the context, and they don't have to hunt around the original question on the chat thread. And I really like that as a... Again, another piece of advice. So make your messages self contained. I thought it was very cool. What's next for you? What are you thinking about in terms of Team Topologies now?
Manuel Pais:
One of the main things we're working... Actually, I just had a call yesterday with people involved in this project, is to actually have better, more grounded ways of assessing cognitive load and measuring cognitive load on teams so that we can measure this over time and see if the actions we're taking to improve and reduce cognitive load are being successful or not. So we're actually doing this in collaboration with a company in the UK, where they have people with the right profile that have academic background in psychology, but also they have experience with organisation design. So it was sort of accidental to find them, but it was really a good profile. And so we're taking the ideas of team cognitive load and making them more structured. And hopefully, we'll have some sort of tool that people can start using. We hope to have a first version before the end of the year and then evolve that and see if it's helpful and how can we improve it.
Charles Humble:
Sounds very exciting. I look forward to seeing that and I will make sure to link to the Remote Team's workbook, which I believe is coming out, as we record. I think it's coming out next week.
Manuel Pais:
I think next week in Europe. I've actually seen someone from the US. I was in a call, and they had the book in their hands and I said, "I don't have it..."
Charles Humble:
You don't have it it yet which is a bit unfair as the author!
Manuel Pais:
Figured I should have a copy by now, but it's just... With the current supply chain, et cetera and all these things. So yes, in Europe, I think the physical copy is available end of May. By the way, the other project we have, which is ongoing, we started last year is the Team Topologies Academy, where we tried to condense our... Not just the knowledge from the book, but the experience we've gained afterwards and new insights into online training. And what's also exciting for me is we're starting to have guest instructors as well. So it started with our own Team Topologies related courses, and now we're going to have people who are going to bring their experience in other domains, like domain driven design or worldly mapping and how that overlaps with Team Topologies. How can you use two things or more in conjunction to actually even get better outcomes? I just want to say there's also something quite exciting for me in terms of project.
Charles Humble:
Yes. Funnily enough. We had Susanne Kaiser on the show last month.
Manuel Pais:
Yeah, she's amazing.
Charles Humble:
Yeah. She really is. And she was talking about the book that she's working on, which combines Team Topologies, Domain Driven Design and Wardley Mapping. It was a fascinating conversation with her really recommend checking out that episode. But also I'm really looking forward to her book coming out. And more broadly, I think it's very exciting to me to see that the work what's happening in this space. The amount of thinking that's going on in terms of organisational design and remote organisational design, I think is really exciting. And I'm grateful to you for joining me this month for this episode of Hacking the Org from the WTF as Cloud Native? Team here at Container Solutions.
Manuel Pais:
Thank you for having me, Charles. That was great.
Previous article
