During the DevOps Enterprise Summit 2019 in Las Vegas, the authors of the “Team Topologies: Organizing Business and Technology Teams for Fast Flow” book - Matthew Skelton and Manuel Pais were interviewed by SolutionIQ’s Stas Zvinyatskovsky for the Agile Amped Podcast.

Matthew and Manuel talked about how they came up with the idea to write the book, the four types of teams: stream-aligned, enabling, complicated-subsystem and platform - the reasoning behind the split and definitions.

“We’re not just talking about shapes of the teams and composition, and the structure of the organization, we’re talking about the social dynamics.” - Matthew Skelton

The authors emphasized the importance of the human factor, cognitive load, and how it relates to teams. Conway’s Law and the importance of taking advantage of it’s mirroring effect was mentioned also.

 “... if we're not thinking explicitly about the two things together, the software part and the organizational side, then we're probably going to run into issues and the teams are going to be fighting against the intended software architecture because they're not set up in a way that promotes it or takes advantage of this mirroring effect.” - Manuel Pais

You can find the audio of the podcast and full transcript below:

Transcript:

Agile Amped is your go to source for inspiring conversations on topics from empowering teams to thriving in the digital age. This podcast gives you access to expert advice you can trust from the largest source of Agile thought leaders. Agile amped is brought to you by SolutionsIQ, an Accenture company.

Stas Zvinyatskovsky:
Welcome to another edition of Agile Amped. I'm your host, Stas Zvinyatskovsky, and we are podcasting today from DevOps Enterprise Summit in Las Vegas. And today my guests are: Matthew Skelton and Manuel Pice. Welcome.

Manuel Pais:
Thank you.

Stas Zvinyatskovsky:
And you are the co-authors of the newly released IT Revolution book called Team Topologies. And so we're here today to talk about your book.

Matthew Skelton:
Thanks for inviting us.

Manuel Pais:
Thanks for having us.

Stas Zvinyatskovsky:
So how did this book come about?

Matthew Skelton:
We've been working with lots of companies and organizations, helping them to become more effective at software delivery for quite a long time and we'd noticed some patterns. We'd noticed that lots of people in different organizations felt confused about how they should work inside their team or how their team should interact with other teams. A huge amount of lack of clarity within lots of organizations about how teams work together or how teams are set up to work together. That influenced the material in the book quite a lot, didn't it?

Evolving beyond DevOps Topologies

Manuel Pais:
Yeah. We're also, the DevOps topologies that came about in 2013 was your first blog post and then we had a catalog online. So with different ways where you could think about your teams and the ways they interact and try to map yourself to "Okay, what makes sense in my context in my organization?" But those were still kind of static so you could check and see if you, this makes sense for me or not. But the book also talks about how can we evolve over time instead of doing a big reorganization for Agile, DevOps, et cetera. Kind of having teams that are able to evolve over time and interactions as well.

Matthew Skelton:
The DevOps Topologies patterns have over the last few years become pretty much the industry standard for looking at different ways of organizing teams in a kind of modern software delivery context. We know that Netflix, for example, found them very useful. And so the director of engineering Philip Fisher-Ogden did a public tweet and thanked us for our work on those. And we know that other organizations like Condé Nast International and Adidas, and actually Accenture have also used the patterns quite extensively.

Matthew Skelton:
There's general acceptance that some of the, there's some really useful thinking in this collection of patterns that describes the pros and cons of different ways of working that we wanted to take that and go well beyond that initial thinking. And so the Team Topologies book goes way beyond that in terms of how to evolve organizations, how to make organizations continuously evolving in order to meet new business software delivery challenges.

Cognitive load and human aspect

Stas Zvinyatskovsky:
And so what's an example of a pattern that you describe in your book?

Manuel Pais:
So we talk, for example, we talk about four types of teams and three core interaction modes. So in our experience and looking at case studies and talks from different organizations we think we've found that this are the only four types of teams in three interaction modes you would need to be considering for effective software delivery. So we're talking about stream-aligned teams, which are kind of your product team with entwined ownership of the delivery and running the service and supporting it. And then you have, we have three different other types of teams that are essentially trying to minimize the cognitive load on the stream teams. So we talk considerably really about cognitive load in the book.

Manuel Pais:
It was also the topic of our talk here at DevOps Enterprise Summit, which is thinking about, does the software and the services that the team's responsible for fit their cognitive capacity? Their capacity to understand it well enough that they are able to make changes as well as support in production in an efficient, timely matter and safely as well? So that doesn't create anxiety and demotivation in the team members to feel like, "Oh, this is something, it's too big, it's too complex, or the quality has degraded too much. So I know that if I touch a piece of the system, I'm going to likely have to fix many other parts of the system that depend on it." So it's this idea of cognitive load is making sure the team has enough capacity to deal with the services and software they're responsible for in an efficient manner. And then we have other three types of teams that help reduce that effort, which are platform teams, enabling teams and complicated subsystem teams.

Matthew Skelton:
I think this is a good example of what's in the book. That we're not just talking about shapes of teams and composition and a kind of structure of the organization. We're talking about the social dynamics that go around these teams as well.

Manuel Pais:
The human aspect.

Matthew Skelton:
The human aspect, exactly. Cognitive load at the team level is a very kind of human centered aspect of software delivery. And actually our recommendation is that we use cognitive load as a way to right-size bits of the software system that different teams should be working on. So don't choose monolith or microservices but start with the cognitive load of the team and use that to drive the right-size of software architecture, which people like Daniel Terhorst-North have been talking about for a long time, "Software that fits in your head." But this is fairly new to lots of organizations to think about starting with a human or a team aspect and deriving some kind of heuristics for how they go about building software systems from starting from the team.

Matthew Skelton:
So the book effectively in lots of different dimensions starts with the team and then we make decisions based on the capabilities and needs of the team if you like, which is kind of a different lens, a different starting point for thinking about modern software delivery compared to lots of stuff in the past.

Stas Zvinyatskovsky:
I think it's an extremely important factor and thank you for talking about this because I don't think it enters the conversation frequently enough. We should talk more about cognitive load and enabling people to deliver value so, thank you.

Platform and Stream-Aligned Teams

Stas Zvinyatskovsky:
So you mentioned platforms as one of the patterns, one of the type of teams. And so in software delivery we have this tension in big organizations between centralization and decentralization, right? And I guess part of it is going to be in your terminology, stream-aligned teams versus platform teams. So could you talk a little bit about making that trade off between centralization and decentralization?

Manuel Pais:
Yeah, so first the definition of the platform for us in the book Team Topologies is perhaps different from what we've been used to in the past as well. So we used to think of a platform and, in this type of organizations that you're talking about specifically, as something centralized where we aggregate and we put in there all the kind of shared things that multiple teams will use and then we standardize and make sure everyone is doing it the same way. So that's not the platform that we're talking about. Because if you look again from more human, a team focus aspect, what those platforms are doing is we're often getting in the way of teams doing their work. They were being forced to use this platform, sometimes work around it because it was not providing the experience or the functionality that they needed.

Manuel Pais:
And so sometimes kind of in the shadow, almost like going around this standardized platform because it was not meeting their needs. So we're saying we need to think about the needs of the stream-aligned teams as well. We need to think about, what is the experience for them using the platform? And so one key aspect is, for example, not making them the platform mandatory. So we're not talking about from the standardization point of view, we're talking about making the right thing easy to do for the stream-aligned teams through the platform so that they don't have to worry about things like, "How do I use logging correctly? How do I do the monitoring?"

Manuel Pais:
So that can be taken by the platform as a kind of internal service, but always with a customer who, in this case are the stream-aligned teams, in mind and think about, what is the experience for these teams to use our services? Are they matching what they need in terms of functionality but also usability, developer experience and so on? So it's very different, quite different take on platforms.

Stas Zvinyatskovsky:
Okay. I think it makes a lot of sense. And in that world, what is the model of governance that fits that world best?

Enabling governance

Matthew Skelton:
So there was a talk yesterday actually where, I can't remember which one it was, but someone was talking about switching governance from being something that happened before we went to production. So a kind of silo in the flow of change, switching from that into making governance into more of an enabling force if you like. So in the book we, we talk about enabling teams who, whose mission is to help other teams, particularly stream-aligned teams to increase their awareness, increase their capability skills. And so in that particular case, for example, he might have some governance specialists who understand something about audit requirements or security or whatever it might be. They can go and help stream-aligned teams in a kind of facilitating way to increase their awareness or increase their skills around kind of implementing governance of some aspects of audit or security and whatever so that we're starting to bake in the governance requirements on an ongoing basis.

Matthew Skelton:
Governance doesn't just happen, it doesn't become something that then we do as a discreet thing. It's something that we're baking in across the organization and I think approaches like that have to be the way forward because we can't have kind of discrete, siloed, in the flow of change activities that effectively block the flow of delivery. You have to find ways like kind of an enabling team to embed that kind of, in this case governance, but the bit of auditability, securability, that kind of thing, into what stream-aligned teams build on a day to day basis.

Manuel Pais:
I would add on top of that, that's one of the ways and also whenever we see whatever controls we might have in place that could be pushed to the platform basically. So for example, another problem we have is, we talk about teams by their name, but for example, we can talk about a cloud team and it can be totally different what their responsibilities are compared across different organizations and sometimes even within the same organization.

Manuel Pais:
So, just to give you an example, if you have a cloud team who is behaving like a traditional infrastructure team, which is kind of a gatekeeper for any type of changes to infrastructure, then that's going to block flow right for the stream teams. But if they take another approach, which is more you feel like aligned with the governance in the sense of let's provide self service capabilities for the stream teams and within these capabilities we're going to embed, when possible, whatever controls and assurances we want to have and checks around security, also cost effectiveness, so that we make it easier for the stream teams to, for example, create a new environment where all these things are already embedded, you know, the right security policies and so on and so that accelerates stream teams and also increases the risk control and the kind of governance aspect.

Complicated subsystem team

Stas Zvinyatskovsky:
Thank you. I think it's important to mention that everything that we're talking about today that Team Topologies described in the book, they're all optimized for flow value, right? We haven't mentioned that explicitly, but that's the underlying principle behind this book. Okay, so we've covered I think three out of the four types of teams, stream-aligned, platforms and enabling. How about the fourth one?

Matthew Skelton:
So, it's great that we came to this one last because this is really kind of an optional one. And if we can avoid having a complicated subsystem team, then we should do. But sometimes they'll be situations where we need a team of specialists with skills that would not be reasonable to find in a stream-aligned team.

Matthew Skelton:
So we worked with a video advertising startup for example. And so then you've got kind of video codec. You need people who understand matrix maths or got PhD in something like this. You can't expect a typical, even a good software developer or tester to be able to work at that kind of level. So we kind of break that chunk off, let's say just a video codec library or a or component and we have a small team that can work on that. Now, eventually that component or service might get pushed down into the platform to be provided as a service and so it can just be consumed by stream-aligned teams and in a kind of normal sort of platform-y way. So it may only be that we have this complicated subsystem team for a period of time, or maybe we have them along on an ongoing basis if we need some really, really dedicated deep, deep skills in a particular area.

Matthew Skelton:
But to make that work, we also need to provide that kind of team with the kind of human skills and communication skills to be able to provide their software or service in a way which doesn't block flow. So they can't just go away and sit in a corner and code up some like video algorithms. They have to also understand how other teams need to consume it. You have to make sure the right documentation, you have to have the focus on developer experience so it's really easy to install that component or easy to install the library, and we've got an awareness of how the library's going to change in terms of versioning and so on. We've got visibility to the roadmap to kind of proper product management disciplines around that component. So it's not just a group of people sitting in a corner coding away on some deep technical stuff that there's a kind of wrapper around it if you like, which makes it easy for other people to work with them and consume what they're building.

Manuel Pais:
And the reason also why we, I would say this is kind of a last resort type of team, you should be very careful about implementing this type of team is because it can go wrong quite easily both ways actually. So often organizations will create kind of a specialized team around the certain component, but it's more based on the fact that it's a shared component and then they become a bottleneck, you know, in the delivery process for all the other teams that require this component.

Manuel Pais:
So we'd be very careful about really deciding on a complicated subsystem team. I Have an anecdotal episode from a company where I used to work that we, we developed border control systems and identity verification systems. And so it was interesting because, and this was way before any DevOps Topologies and Team Topologies but thinking in retrospect, it's interesting because we had one person who had a PhD in face recognition, so we had a face recognition module in the systems and everyone felt like this was not a good approach because of bus factor and holidays factor, if this person was away, no one else knew how to modify this module.

Manuel Pais:
But in fact now thinking retrospect was not that bad because the rate at which changes were required for this module were very slow, perhaps once a month or every two months. So it was perfectly fine to have someone who was the specialist around that. The problem obviously there was that there was only one person, so he's don't want to have a, a team of one, but kind of the pattern of abstracting away this complexity that required this PhD level understanding and multiple years of working the area and not, not expecting other people to have that kind of knowledge because it would take a toll on their cognitive capacity, was actually a good thing.

Conway’s law

Stas Zvinyatskovsky:
So it sounds like team topologies that you put forward in this book, they need to also be aligned with software architecture, right? And even potentially with software delivery practices.

Matthew Skelton:
Completely. Well, I kind of change it around a little bit. So because of Conway's law, which is this kind of mirroring between the communication path in the organization and the kind of system architecture that tends to get produced, the way in which we design our teams and communication paths has a strong influence on the software architecture. So what we're looking to do is maintain a kind of mirroring between the two.

Matthew Skelton:
And obviously the software architecture is going to change. So therefore we're expecting our teams to change, too. A good chunk of the book is about making sure we set up the teams in a way which enables them to change and that we're listening for signals that tell us when we need to change the shape of the teams and the relationships between the teams. So, yes, absolutely we've become much more aware of the relationship between humans and how they communicate and the software architecture. Now that's some really key learning from the last few years. Even though Conway's law was first put down in 1968, it's become much more apparent as we've been able to use cloud technologies and go much more quickly.

Manuel Pais:
And one of the consequences of that is that if you have people making decisions around our teams and our organization without considering the technical implications and implications on the soft architecture. But, like you said, the way the software delivery in general, what we'll be able to do given this constraint of how our teams are organized, if we're not thinking explicitly about the two things together, the software part and the organizational side, then we're probably going to run into issues and we're going to be perhaps the teams are going to be fighting against the intended software architecture because they're not set up in a way that promotes it or takes advantage of this mirroring effect.

Stas Zvinyatskovsky:
Yeah. Cause it works the other way too, right?

Manuel Pais:
Exactly.

Stas Zvinyatskovsky:
If you tried to go from microservices without adjusting your organization model, you're not going to get very far.

Matthew Skelton:
Sure. Exactly. I mean do, yeah. And ultimately do we want HR and non-technical managers designing our software architecture? Probably not. So we really need to kind of take that on board and think about...

Stas Zvinyatskovsky:
It would be an interesting experiment.

Matthew Skelton:
Well lots of organizations have experimented with it and find it's really tricky to deliver software so...

Reflections on the book

Stas Zvinyatskovsky:
And so we're here at DevOps Enterprise Summit in Vegas. It's October your book came out, what, about a month ago? And so what's great about this conference is that you get to hear a lot of real life stories from practitioners across industries and now that you've spent a lot of time and efforts and published this book, congratulations by the way...

Matthew Skelton:
Thank you.

Stas Zvinyatskovsky:
...you have a little bit of, you have had a little bit of time to reflect. And listening to stories, what do you think? How do they really relate to what you put forward in your book?

Matthew Skelton:
The first thing to say is we actually had been pleasantly surprised at the number of people who have said that they've already started to use some of our ideas from the book to improve how things work. So let's say there's a bank in the UK, there's organizations in Canada, one in Peru. And so that's really great to hear. People seem to be finding different parts of the book really useful and practical help to, to help them improve incrementally bits of their organization, so that's great to hear. After we've given talks and things, one of the consistent questions that we get is, "How do you assess cognitive load at the team level?"

Matthew Skelton:
So that's something we're working on. I mean at the very simplest level you can just ask team members, "How anxious are you?" "How confident are you?" as the inverse. "How confident or anxious are you about the software that you're responsible for?" And if team members are actually pretty anxious about it and not confident that they understand it fully, that's a leading indicator of potential problems down the road. But we're kind of working on some more kind of substantial measures, maybe influenced by a bit of psychology and things like this as well. There's been some research over the last sort of 10, 15 years around team cognitive performance and things like this and it's great to be able to lean on that academic research.

Manuel Pais:
I think in general when we, we wrote Team Topologies strongly influenced by our own consulting experience, but we've been attending this DevOps enterprise summit for several years and listening to the stories and we are also identifying which patterns have worked well for the organizations that have been successful in their transformations. So we tried to condense all that in the book and give this patterns that we've seen that were applicable to those organizations and also in our experience and the feedback we've got is that sometimes it's useful just to have names for these things, for this patterns and what we're trying to achieve. So that alone is helpful for many organizations and for others.

Manuel Pais:
Just yesterday at the book signing, we had several people saying though, this is just the book I need now because we're going through this DevOps transformation and there's often kind of very blurred ideas around, "What does this mean in terms of our organizational aspect and beyond the tooling and the practices? Should we reorganize or not?" So this book seems to be helpful for those people.

Stas Zvinyatskovsky:
Great. Thank you. So Manuel, Matthew, thank you for your book. I think it's an important book for our industry. Thank you for your time with us today.

Matthew Skelton:
Thanks for interviewing us.

Manuel Pais:
Thanks for having us.

Stas Zvinyatskovsky:
I appreciate you stopping by.

Stas Zvinyatskovsky:
Thank you for listening to this edition of Agile Amped. If you learned something new, please tell a friend, a coworker, or a client about this podcast and subscribe to hear more inspiring conversations.

Agile Amped:
Thanks for listening to Agile Amped. Find more inspiring conversations at AgileAmped.com, iTunes and your favorite podcast app. If you have an idea for a topic or feedback on an episode, reach out to us on Twitter, Facebook, and Instagram, or send an email to agileamped@accenture.com.