Team Topologies 2: Organizing Business and Technology Teams w/ Manuel Pais & Matthew Skelton

**Matthew Skelton** (0:00)
If we want a fast flow of change, we need to look at the human conditions under which that can take place.

**Manuel Pais** (0:05)
Get the work done more efficiently with faster flow, with better feedback loops.

**Dan Lines** (0:11)
Today, I'm joined by Manuel Pais and Matthew Skelton, writers of the book Team Toplogies, Organizing Business and Technology Teams for Fast Flow.

**SPEAKER_4** (0:23)
This episode is sponsored by LinearB.
Give your dev team the power to improve with team-based metrics, high-risk code alerts, and the world's first project board based on real-time get activity. Sign up free at linearb.io.

**Dan Lines** (0:38)
Welcome to Dev Interrupted. I'm your host, Dan Lines. I'm joined again by Manuel Pais and Matthew Skelton, writers of the book Team Toplogies, Organizing Business and Technology Teams for Fast Flow.
Guys, thanks so much for joining us again.

**Matthew Skelton** (0:55)
It's good to be here, thanks.

**Dan Lines** (0:56)
Manuel, what are the first steps for organizations that want to begin some type of transformation to move to these more streamlined, effective structures?

**Manuel Pais** (1:09)
Yeah, it's interesting because we recently created a couple of infographics because we get this question quite often. And again, on our website, teamtopology.com/infographics, you will find them. Obviously, there's a lot of context for each organization that needs to be taken into account. But at a kind of higher level, if you like, you can think about, okay, first of all, we need to agree that we want to achieve fast flow. If Matthew was saying, there might be some situations where that is not the goal, and then maybe Team Topology is not what you need to be looking at necessarily.
But most organizations need faster flow, they need to get changes quickly to customers, as well as respond quickly to problems.
So assuming we agree, that's what the organization is trying to achieve, then you can start identifying what kind of teams you have today, and how do those teams fit into the patterns that we talk about in the book, the four fundamental types of teams. Because again, having clarity on what kind of teams we have is going to help us understand what are we able to do as an organization, as well as what are the bottlenecks, what are the things we need to address. And so when we do that sort of mapping, if you like, and we start looking at where more this team is a streamlined team, but maybe they don't have enough awareness of how to run their service in a live environment, and so they need more kind of operational awareness, or maybe they don't actually have enough awareness on the product side and on what the customers need. And so maybe that's where they need to expand their abilities.
And the same for other types of teams. So that's what people tell us that the book really helps them have this sort of initial conversations around what is our purpose as a team, what are the gaps that we have today. And that's why the patterns in the book are useful. It's not just to say we are a streamlined team, that by itself doesn't really bring you any advantages, because we get the clarity on what are we trying to achieve? What are the gaps today? And so once you have that sort of more start to have that understanding of how we align to the fundamental topologies and types of teams, then you can also start looking at where are teams overloaded with cognitive load. And so what can we do about that? How do we help these teams reduce their cognitive load so that they can actually be more productive?
By not having to do so much context switching, have being expected to know too many things, by having either enabling teams or platform teams, helping them upskill and abstract some of the details around lower level concerns that maybe a platform can help. Again, with the focus on reducing cognitive load, not necessarily about having some shared services, but actually looking at what are the problems that the teams have today and how do we address those.
And then you can look at other things like Conway's Law and starting to see if we want to achieve some kind of systems and architecture for these systems, how should we align the teams to achieve that. And then obviously introduce the interaction modes as well and make sense of what is happening in the organization. Whenever maybe two teams were expected to collaborate to find some solution to a common problem, if that collaboration went wrong or felt awkward because maybe it took way longer than we expected, or we didn't actually find a solution, or the two teams have very different understanding of the problem, if you like. And so maybe there's a problem in the skills of the different teams. Maybe one team is more experienced than another. Whatever it is that made the interaction awkward, that we use that to inform how we need to evolve. Maybe in some cases, a given team needs help from an enabling team to actually learn a bit more about, I don't know, let's say infrastructure as code, so that they can actually collaborate with other teams around infrastructure as code. Because if they don't have the skills, then that collaboration is not going to work very well. And so we're evolving the interactions and the team structures and capabilities based on that sort of ongoing feedback.