In this episode of Le Podcast on Emerging Leadership, I had the privilege to speak with Manuel Pais, co-author of the influential book Team Topologies. We examined how modern organizations can refine their structures to optimize both value delivery and employee satisfaction.
Key Insights from the Episode:
- The Four Fundamental Types of Teams:
- Stream-Aligned Teams: Cross-functional teams with clear end-to-end ownership, directly responsible for customer value streams.
- Enabling Teams: Experts who mentor and facilitate skill acquisition, reducing cognitive load for Stream-Aligned teams.
- Platform Teams: Provide self-service internal services that reduce friction and cognitive load for Stream-Aligned teams.
- Complicated Subsystem Teams: Manage complex domains or components that require deep expertise, sparingly used to avoid creating excessive dependencies.
- Understanding Cognitive Load:
- Cognitive load limits the effectiveness of teams. Organizations must actively manage and reduce it to increase efficiency, satisfaction, and delivery velocity.
- Identifying the drivers of cognitive load helps leaders prioritize and address issues proactively.
- Moving Beyond Labels to Interactions:
- Effective use of team structures goes beyond labeling—it’s about managing interactions: Collaboration, Facilitation, and X-as-a-Service.
- Teams should dynamically alternate between interaction modes, especially Platform Teams, to effectively serve their customers.
- Role of Leaders in Evolutionary Change:
- Organizational change must be evolutionary and iterative. Leaders must clearly communicate that change will be gradual, learning-focused, and supportive.
- Leaders must create and maintain environments where people feel supported as roles evolve, especially regarding new skills and responsibilities.
- Investing in Flow:
- Manuel emphasizes the value of dedicated roles or groups focused solely on improving flow within organizations, acting as “flow enablers” to identify and remove bottlenecks.
Reference Links:
Transcript:
Alexis: [00:00:00] Welcome to the podcast on Emerging Leadership. I’m your host, Alexis Monville. Today, I have the pleasure of speaking with Manuel Pais, co-author of the influential book Team Topologies. Manuel is a leading voice on organizational design and team effectiveness. In ‘Team Topologies,’ Manuel and his co-author, Matthew Skelton, explore how successful teams organize themselves to achieve continuous and sustainable delivery.
Manuel, welcome to the podcast on Emerging Leadership. How do you typically introduce yourself to someone you just met?
Manuel: Hi, first of all, thanks for for having me. Depends what is the context, but in terms of explaining what I do, the most difficult is to explain to my kids. So someone told me this week, I think a good way to think about it is almost like a teacher for [00:01:00] companies like I am.
I wouldn’t say necessarily teaching, but helping organizations think about what else they might need to do to improve flow, to improve the engagement of teams. Obviously all the motivational aspects of getting teams to be more, to feel more autonomous and empowered, and but also delivering more value more independently to the customers.
I see myself. In that way a lot. I’ve always had interest in kind of the educational part. I’ve done a lot of editing and reporting for InfoQ as well, for example. So although I’m a software engineer by background, I really like to help people and teams and organizations be able to reflect and think about, okay, what might we need to do different in order to.
Improve our flow, improve the way we work, and also [00:02:00] provide more value to the customers.
Alexis: I really like the idea of increasing the value and increasing the satisfaction of the people who are within the organization. So the both things really like that. Team topologies. Incredibly influential. What initially you to the challenge of organizational design?
Manuel: I think there were a couple of things. One is, I guess out of my. Curiosity to learn and try new things. I started my career as a developer, a Java developer, and then I had different roles as tester, release manager, and then team lead. And so that allowed me to start kind of the same things from different perspective, right?
Mm-hmm. As someone in, in a test team look at. The work that the development teams are doing. You know, obviously I’m now have fairly fair, a fair amount of experience, 25 years, so I feel [00:03:00] a bit old, but I can remember well when there was all this friction between, you know, test team and the ops team and the dev team and the, the teams being so very much isolated and, and trying to do the best within their scope.
But that was not necessarily very helpful for. The customer at the end that is waiting for some changes or some new product and so on. So that kind of start got me started thinking, okay, why at the end of the day, we’re all working in the, we should be all working towards the same goal, which is, you know, to deliver this product or to deliver some new value to the customer.
So why do we have. Sort of sometimes very antagonistic views of each other. And then the other thing that happened was, this was sort of in the back of my head as I was working for different companies, and then when I moved into consulting around 2015, so together with Matthew Skelton, the other [00:04:00] co-author of the book, Tim Topologies, and we were doing consulting around DevOps and continuous delivery.
This. Feeling that actually a lot of the issues are not really so as much the technical side as it is the people, the interactions, the sometimes lack of direction or too much isolation. Between teams that were the real problem. So we, we would often have client engagements where we were asked kind of a more technical job to, you know, implement some pipelines, help us adopt some DevOps practices, which is, which is fine and they’re helpful.
But at the end, the real issues were happening in the interactions or lack of interactions between teams, incentives that were not. Aligned, which at the end of the day were not beneficial for the organization and, and the customers. So we, during this consulting years, [00:05:00] we were. Essentially applying the patterns that we talk about in the book team topologies and in our academy and so on, with different customers at the kind of more localized way.
Like, let’s see if, for example, the platform pattern, can we help this team usually, for example, team that’s taking care of the CICD pipelines, can they act in a more. Platform as a product type of way that we talk about. Right. What would be needed? Well, they would need to become, provide services that are more self-service.
They would need to reduce the amount of, you know, ticket based back and forth to reduce the time it takes to provide what, what, uh, product teams need. And so that was sort of the origin. And obviously today, almost six years after the first edition of the book, it’s really great to see. So many examples and case studies of actually applying the whole of, [00:06:00] or many of the team topology patterns together and that providing a lot of benefit and and return.
Alexis: You already started, and I’m sure you are probably a little bit tired of doing it, but could you briefly outline the, the four types of teams that you in the book?
Manuel: Sure. It’s a bit like the. Playing your greatest hits. Right? But it’s totally fine. So the starting point are what we call stream malign teams.
So this would are very much your cross-functional product teams. Type that with two, I would say two particularities. One is that it’s a kind of product team, but that is working on end-to-end, that has end-to-end ownership of. A stream that is valuable to customers. So there are some identified types of customers at the end of the day for that team that they know these are the people or the [00:07:00] type of customers that we are serving.
And whatever we do, they are the primary customers that we need to sort of serve, if you like. And then the second thing is this idea of stream, because. You could say you have a product team, but that if they’re only, you know, maybe they’re taking care of some, one component of a large product and there’s a bit of confusion, right?
Is it a product team? Well, they’re working on a product, but do they provide value directly to end customers? No, because they just, between quotes, own one technical component. Right? So the idea of streamlined teams is. You need to clearly identify what are the streams, and this can be within one larger product.
You identify different streams of value to customers, which might be different user journeys, or it might be around different user personas for the same product. Or it can be, you know, one team is focused on acquisition, another on retention, and you know, whatever. [00:08:00] Makes sense from a business perspective, but that is aligned to some continuous stream of, of value to some kind of customers, and we wanted to make sure that was clear.
And then once you have these stream aligned teams with. As much as possible end-to-end ownership. Ideally from we can actually generate ideas and maybe some experiments and things. We want to try to improve our stream for the end customers all the way to, we actually are able to build this, this experiments or features or what have you, and deploy them and have them being.
Available to the customers, and that’s where things get a bit difficult because obviously you’re talking about owning the whole lifecycle from product ideation to customer availability of what you’re doing, and that’s where the problem of cognitive load comes in, right? This is a lot of information [00:09:00] overload for a single team and the competencies that you would need in such a team, right?
If, let’s say they have. No help. If you would say to a team, now you are on your own doing all this, it’s going to be very difficult. And we know that as time goes on, technology tends to become more complicated and more things we need to know and and more practices and so on. So then we bring in the, what we could say are support type of teams, but they’re critical.
To allow the streamline teams to work effectively. And so you either typically need to increase the skills and competencies in the streamline team. And for that pattern we find is very helpful is to have an enabling team. So that’s another type of team where usually a small group of experts in some domain of knowledge are intentionally so the key, the key here is that they actually.
Are putting in, they have the availability to focus on [00:10:00] helping the streamlined teams learn the skills and, and bridge some gaps in their competencies. And they’re also in a good position to bring to the organization innovation, new ways of working, or maybe some new tooling and making the bridge between what.
The organization does and, and uses today and what is available outside in, in the industry. And then we have platforms which typically you, I mean, we could say you might start with a platform team as in one team that takes care of some, some kind of services that are consumed by the s streamlined teams in an, in a way that makes their life easier.
Because if we provide a platform, but actually this is just adding up more effort, setting up more need to understand how the platform works, or you need to manage work through tickets to get things done, then that’s not. A very helpful platform in the, in the sense of reducing the [00:11:00] load on streamlined teams.
But usually it ends up being not just one platform team. For most organizations, you end up with what should be a platform group, like a grouping of teams working in a platform. Ideally, those teams inside the platform are also aligned to some streams of value to internal customers. The in the stream aligned teams, right?
Mm-hmm. And then there’s was another type of team that we. Sort of reluctantly felt we had to include no discredit to the complicated of system teams, but we should use them sparsely when there’s really, sometimes we know there’s a component or a service or some part of a larger product that is very complicated because either the algorithm is very complicated or it could be.
In some occasions, the technology is very outdated and you only have a few experts who understand how to make changes to this technology. There are some exceptional situations [00:12:00] where it’s say, actually from a cognitive load perspective, we need a team that takes care of this component or subsystem so that we don’t sort of.
Impact the other streamlined teams with all the knowledge that would be required for them to be able to make changes to this component, right? Mm-hmm. But we need, we need to be careful not to overuse this pattern because it then becomes very similar to, or you risk getting into component teams and then you start having all these dependencies.
Because if we have many component teams, then to make a change. That the customer needs, I’m gonna have to start coordinating between component A team, component B, and all these kind of issues that I think a lot of us are familiar with,
Alexis: unfortunately. Yeah. You spoke about cognitive load as a, as a key element.
Can you come back to that and maybe, uh, illustrate with an example?
Manuel: Sure. So in terms of brief. [00:13:00] Kind of background initially, cognitive load theory from a field of psychology. But essentially what we did in Tim Topologies is if there is cognitive load limit. So there’s a limit to our working memory, right, as individuals, but as a team, we, it starts as a group of individuals.
It, it’s more than that. But if I have a group of individuals, there’s also a limit to their capacity as a group. So what’s interesting then is that the cognitive load might have different natures, and even though we cannot cleanly split and say, well, this. Part of my working memories is allocated to the actual business problems, and this other part of my memory is allocated to some kind of more tool related problems or something like that.
Because you know, we’re not a c plus plus program, so we don’t work like that. Everything is sort of mixed, but if you start to be able to determine, [00:14:00] well, actually, what are the things that the team is responsible or has to worry about that maybe they shouldn’t. Because it’s not really helping them deliver value to the customers better or, or more effectively are things that are more distractions, right?
So we start to be able to differentiate, not just say, well, the workload is, is too high, or the cognitive load is, is high on the teams. That’s very common. But then. What is the kind of work that, and, and knowledge and needs that the team should focus versus what they actually should be kind of isolated from?
And so I. That is the key idea, right? So when we talk about platforms, for example, it’s always from the point of view, how are we gonna reduce cognitive load on the streamline teams? Well, if we provide easy ways to, you know, the typical examples are, you know, provision infrastructure or easy ways to deploy their [00:15:00] changes to production with deployment pipelines or easy ways to diagnose problems in the live environment.
All these things that, yes, the teams. Will help the teams to use them, but they don’t necessarily need to know all the details of how those things and those services work underneath. Right. That’s where we start to be able to push down and outside the team certain knowledge and details that they really should not be the core focus.
Right. ’cause I’ve talked to teams that had, they started counting and they had like had to understand. Over a hundred different tools that they used in their lifecycle and frameworks and all this stuff. So that becomes really not very productive. Part of the work with its after the book was published in 2019 was to, let’s take a more deeper analysis of what team cognitive load really means.
And so we partnered with Dr. Laura [00:16:00] Vais, who’s PhD in organizational psychology, and she was able to. Do the research and, and find actually different academia research and, and, and papers and, and findings that helped us. She was able to define a model to assess cognitive load on teams. And so this model that we’ve developed and has now been, we built a product based on this model, which is called temperature.
So as in taking the temperature of a team temperature. Mm-hmm. And so. What she found is that even though we cannot measure directly the cognitive load, we can assess what are the main drivers, what are the things that are driving cognitive load up in the teams right there. So there are a number of different potential drivers.
So it could be things related to the characteristics of the work itself. Could be about the characteristics of the team itself. It can [00:17:00] be about the work environment and tools. It can be about which processes we follow. So it’s really interesting and we start to see more organizations adopting this way of looking at almost like an indicator for team health and team productivity.
If. You are just looking and saying, well, cognitive load is high because teams are very overloaded and stressed, but you don’t have a way to go deeper and say, well, it’s actually because they have too many stakeholders asking. Things and there’s no clear direction, or is it because they have, you know, poor tooling that makes it difficult to do their work and increases cognitive load?
Without that kind of insight, then we’re sort of guessing what can we do to help these teams, right? And mm-hmm. We might. Be lucky, and obviously we talk to the teams. We might realize, yes, maybe we need some new platform services or [00:18:00] something else, or some training or what have you, but we might also actually be looking at the symptoms and not the real causes of that high cognitive load.
And that means we are wasting in a way our our time because we’re not actually working on the highest drivers of cognitive load. We might be working on some things that are helpful, but are actually not the main problems that we should be looking into.
Alexis: I. Okay. And so in your experience, we have four labels for teams.
The temptation could be to, to put labels on team and consider, oh, eh, that’s why you have a so beautiful design and I’m done. What kind of common missteps organization make regarding those team interactions, but ’cause it’s not only leveling them, it’s really working on the interactions between them.
Manuel: Yeah, no, I think you’re, you’re spot on that that is one.
Big issue is that even many organizations or or people of who [00:19:00] read Team Topologies or they heard about this, you know, types of teams, they will sometimes think that, like you’re saying that, well, we just design a new target operating model, or however you want to call it, and we have this perfect.
Idealization of which teams should we have, which platforms and you know, and now it’s just a matter of implementing, executing, and everything will be fantastic. And that’s not how things really work, right? So one of the. I would say the battles that we, we are still fighting is for organizations to take a much more evolutionary approach to organizational change as well.
The good thing is there are some really great examples now that we start to see where some organizations, I’m, I’m thinking in particular a company called Yasir. I think it is not very known in in Europe or the us, but they, they are a big app in the [00:20:00] North African market. They call it a super app for doing multiple things like food delivery, ride hailing and other stuff, financial services.
What’s interesting is that, you know, they had this typical growth spurt of the organization and things were not working very well anymore. Like they like in when they were a startup. Essentially they realized, okay, we need to change the way we organize because there’s all the dependencies. Teams are not autonomous, et cetera.
And they looked into team topologies, but they realized it’s not that team topology tells you it’s, it’s not a, in my opinion, it’s not a model for you to follow by the book is. Giving you some building blocks to think about what kind of teams we might need, how are things going to evolve over time? The evolutionary part is key.
So what they did that I found interesting is they actually intentionally said, let’s, I. Take small [00:21:00] steps and do, they had like four month iterations essentially, where they would say, well, we, we made this change. Like we split up this team into two smaller teams, or we tried to make this team more stream aligned, or we introduced some kind of platform service, so they would make small changes, try it out for a couple months and then.
Reflect and see how did this help us or not? How did it work? And then use that for the next iteration. It’s really almost like if you’re, if you would be back to when you know Agile was introduced, it’s like start breaking down this huge pieces of work that we used to, to have that required this big planning upfront.
And then at the end when you are delivering, you realize there are a lot of things that were not. Based on assumptions that were not true and all this stuff. It’s essentially the same thing, but for organizational change. Start to [00:22:00] break it down to a level where you can make small changes and learn from them and not think that you can put on paper this ideal design and this.
Then it’s just a matter of execution. ’cause that always typically doesn’t end up well.
Alexis: Yeah. You mentioned something just before. There’s probably something about the platform teams that probably many organization could feel that they already have some platform teams. But you, you mentioned something about the interaction with the platform team, and it seems it’s not some, some teams to which you submit tickets.
That’s what, so tell me more about how, how platform teams behave.
Manuel: Yeah, sure. Just before I do that, I think that that raises also the point that the interactions between teams, whether it’s you know, platform or any other kind of teams, are also key to that evolutionary approach, right? [00:23:00] It’s not just defining types of teams or trying to map your existing teams to stream aligned or enabling platform.
It’s actually looking at. The evolution and are these teams interacting in a way that is helpful or not? Are is, are the interactions clear or not? So that was also the key aspect of team topology is to provide, again, some building blocks, some core interaction modes for teams to leverage. And it’s not about saying, oh, we only do this interaction.
It’s about are this. Three types of interactions helpful to frame your communication and working with other teams so that you have a clear idea of what are we trying to achieve? Why are you, why are we collaborating? Is there like a common problem that we need to solve together? Or is this more like actually one team depends on the other because the other team.
Own [00:24:00] some, some skills or some tooling. So we, we are actually depending on them, it’s not that we, it’s not a collaboration in the sense of solving some, some type of problem. So this framing of the, the interaction modes helps us work better with other teams, with, you know, with less waste and, and with more purpose.
So the three interaction modes are collaboration, like I just mentioned, two teams working. Together on some common problem facilitating, which is one team that has some knowledge or skills that is helping another team learn and upskill and gain knowledge. And then we have what we call X as a service, which is obviously based on the ideas of infrastructure as a service, this kind of approach where ideally for a platform that is your.
Your goal for you, the services you provide in the platform, is that they can be consumed independently, that you have a service that is mature enough and resilient and has the right [00:25:00] onboarding and documentation for teams to be able to self-serve, understand what service does, and use it and go on with their work.
So. For platform teams. That sort of is one of the main interactions, but another kind of anti pattern I see is that related to the previous question, is that when organizations are. Defining and say, well, we need this platform. We need this. This teams in the platform, they typically jump to, oh yes, this service is gonna be consumed in this as a service way.
But oftentimes that is you need to alternate between, yes, at some point that service might be stable enough and and easy to consume, but. You need to go through collaboration first to understand what do the streamlined teams really need from the platform? What is the right interface? What should we abstract versus what we shouldn’t?
AB abstract in the platform. All that should be coming from [00:26:00] collaboration with the streamlined teams and finally the platform team. And there’s interesting. Case from Adidas that they do this very intentionally, where the platform teams should also expect to do some facilitating work because they will be typically experts in some domain, right?
Whether that’s infrastructure or testing or you know, something that the platform provides some service, but there’s the whole knowledge of the domain of the skill. That maybe your streamlined teams don’t have, so they, they might not even be able to use the platform properly because they don’t know what’s a good practice and why should I use this service that the platform provides.
Right. So I think a more mature view that I’ve, I’ve seen in companies like Adidas is to have this expectation for the platform teams or, or the teams working the inside the platform. You are gonna need to alternate between these three interaction [00:27:00] modes. Sometimes you’re gonna have to collaborate when you’re trying to build something that helps the teams to reduce cognitive load.
Sometimes you’re gonna have to help them onboard and learn about the service and the domain. Other times it’s acts as a service, so you basically need to take care of the operations of that service and obviously fix incidents and provide a good kind of support to the teams using that service.
Alexis: It’s interesting because the way some people describe themselves tells us something about how they envision those interaction mode.
I remember when the book was just out and a, a team of architects in the company, which was a bit surprising to me, but that’s how they were organized. Those architects owned very complex things.
Manuel: Yeah.
Alexis: That, that all the, all the other teams were supposed to use, and that was very complicated for the other teams to use that.
And they consider themselves as, oh, we own that [00:28:00] complicated subsystem because all the others are, are so dumb, they dunno how to use it. And then, uh, someone read the book and they say, oh, well you are an enabling team. I said, based on their behavior, it does not look like that.
Manuel: For sure. Yes, that’s.
Alexis: In that box was not helping because their behavior was exactly the opposite of what was needed for the other teams.
Manuel: That’s a really good point, and when we were writing the book that the purpose of these types of teams was also to elicit certain kinds of behaviors that would be expected for these types of teams.
Right? Like you’re saying, you know, if you are in an enabling team, the expectation is not that you are. Sort of hoarding some complicated services and, and you’re the only experts who know how to change it, then that’s definitely not helpful for fast flow. And also it’s not expected behavior from an an enabling team, which is there to [00:29:00] teach and mentor and help others grow rather than being the smartest in the room.
Which is interesting because effectively. Also common question after the book is, okay then if you need these different types of teams, then for example, in a startup, then you. What do you do? Because you cannot have, you don’t have enough people to have dedicated platform enabling teams. And that’s interesting to me in this sense because it’s, again, it’s more about the behaviors and the teams are almost like an implementation detail between quotes.
At some point it makes sense to have dedicated teams, but if you are in a 30 people startup, yes, probably you, you have most everyone works in. Kind of streamline teams. Everyone can do everything, but that doesn’t mean you cannot have some enabling and platform behaviors. Where maybe in this scenario, enabling essentially means, you know, having some mentoring from people who are more senior in the company, [00:30:00] helping the new people or new teams.
Maybe the platform pattern in a startup is actually just. A few people who dedicate, you know, a couple of hours per week to document how are we doing, how we’re using AWS, how are we setting up our deployment pipelines? You know, you don’t actually have real platform services, but maybe it’s just a wiki that helps other teams.
Okay. If I follow this sort of guidelines and guidance, it helps me get started to deploy a new service or something like that. So the pattern is there and the behaviors are there, and then the actual dedicated teams is, might come later when you grow and you scale up. Also, you shouldn’t just never create the teams, the dedicated teams.
It’s a matter of scale, but the behaviors can be there from the beginning.
Alexis: I, I really like that because that can really also facilitate the onboarding of new people on the team [00:31:00] because it clarifies how it works and it leaves some spaces that you don’t necessarily need to learn everything from in that particular area.
You. That part, you need to learn everything there. So let’s focus on that first. That’s helpful. I, uh, I feel you probably work with a lot of leaders in organization that would like to get the benefits, let’s say, of a fast flow organization. All the things you were describing at the beginning, what are their roles in the implementation in the way you, you see that?
Evolutionary change.
Manuel: So do you mean like for specific types of, of leadership, like CTO or,
Alexis: yeah, for example. Yeah.
Manuel: Yeah. I think going back to the idea of an evolutionary approach, I think that would be one of the main things, especially people in senior leadership, is sort of setting the tone that. We’re not doing this big reorg where people might [00:32:00] be afraid that, you know, their role is gonna change or the the team they work with is gonna change.
It’s actually telling them, look, there’s gonna be changes, but we’re gonna be doing this in an evolutionary approach. So we learn and we adjust when things are not right. It’s not just, you know, one step change and then good luck and hopefully things are are better. So that would be. A big one. And it doesn’t mean that you need to be directly involved in figuring out what changes are needed.
It’s more providing the support that, you know, let, let’s, let’s do this and, and learn and evolve. And it’s also providing the support that. People are gonna need, especially if you know it’s, there are changes in terms of their responsibility, the competencies that they need. If we’re talking about, for example, you have teams that are going to ideally become more stream aligned with more end-to-end ownership, then make sure that we are identifying what are the gaps that these [00:33:00] teams have.
Because if they’ve never done actual user research or if they never done testing or what have you, then they’re gonna need help. They, they. Need to feel that they’re going to be supported in that journey, that there’s gonna be training or there’s gonna be some enabling teams perhaps. So providing that level of support and for people to know that we’re not sort of alone, and that we’re just being asked to do different things and there’s no support.
So you probably need to factor that into your budgets as well to make sure that we, we can do that. And yeah, I think tho those two things. Making it. There’s nothing like set in stone. It’s about learning and taking steps towards improving the way we work and how we’re delivering value. And secondly, that, you know, people feel like there’s gonna be support in this journey.
It’s not suddenly we’re gonna be asked to do something different without [00:34:00] necessary learning.
Alexis: Excellent. And so looking forward a little bit, are there emerging trends or new challenges you’re currently exploring around team and organization?
Manuel: Yes. I mean, we continue to do more research on team cognitive load.
’cause what we have so far, the model we have. It’s scientific model and, and it’s systematic, but obviously it’s not, we can never say it’s complete. There are so many factors that can influence cognitive load on teams. We have a pretty good starting point with model and with temperature that allows teams to have a pretty good view on what is actually influencing their cognitive load.
But there are. New areas of research that we want to explore. Obviously today with artificial intelligence and all the benefits, but also drawbacks it can bring. Mm-hmm. That’s an area that’s, that’s very interesting that we want to research, like how does it impact [00:35:00] cognitive load on teams where it’s important to, if we can help set expectations.
Right. ’cause. You could say, well, in general, our physical intelligence is going to reduce cognitive load if it’s able to do certain tasks and certain work that the teams don’t have to do themselves anymore. But on the other hand, because it’s not deterministic and because sometimes the tools don’t have the context as necessary, and you always need the humans driving that work, it might be increasing cognitive load.
For the teams, right? If you know the way the the tools work is sometimes helpful, sometimes not so helpful. But this is something we want to research. And then the other thing that we start to see that we kind of expected from the time we wrote the book, but it’s nice to see. Happening in, in real life, let’s say, is, uh, applying the ideas from team topologies outside of it.
So that can be, [00:36:00] there’s an example from a, a company Norway called Capra Consulting, where they actually applied the ideas to the whole organization, so to sales, to leadership. They actually. Shut down their management group and, and try to push down this decision making as much as possible to the stream teams.
Mm-hmm. So that’s one example. And then there are even examples. I’ve been doing a little bit of guidance with NGO in Latin America, where they’re also looking at the patterns of Tim Topologies and they don’t build any. Software, right? These are initiatives to promote inclusion of socially disfavor people in kind of the digital world and the digital working market.
And so they realized like they have some bottlenecks in delivering their initiatives, their social initiatives, and they start looking at, okay, could this team become more of a platform team so that they are not a bottleneck so that other teams can [00:37:00] self-serve what this team is doing inside the organization?
So I find that really, really exciting and, and I think we’ll see more examples of applying the patterns. Way beyond engineering and technology.
Alexis: You mentioned the team temperature assessment or way of looking at the health of the team in a way, yeah. Is it something that is already available today?
Manuel: Yes. So if you go to temperature.com, essentially it’s a product, but you can also find details about the model behind it so that you can understand what is the research that was done, what’s, what are the drivers that we’re looking at?
And temperature is the implementation of that model, if you like, into, into a product that’s free to use for up to 25 teams. So yeah, I would love feedback if people want to try it out and, and see what they think about the, the results.
Alexis: Excellent, excellent. Thank you [00:38:00] for having joined the podcast. That maybe the one thing I would like to ask you is, what is the question I should have asked you?
Manuel: That’s a, uh, difficult question. I think we covered a lot of ground, I think in this time, and the question about, I think there’s still more questions about kind of how do you do this transformation from whether you are kind of a project oriented organization. Obviously today there’s a lot of organizations trying to be a product oriented organization.
I think there’s even. In my opinion, another kind of step, which is a value stream oriented organization where the products are a means to provide value, but you actually have a higher level view where you understand the value streams. But this journey, you know, obviously takes time and it’s not always easy.
One part of, like I said, is to take an evolutionary approach and, and the other thing. Is that what I’ve seen in many, [00:39:00] many organizations, they haven’t invested in internal people who focus on flow, right? Regardless how much we talk about fast flow, yes, you have transformation programs, but people who are actually there.
Role is to look at flow and look at where are the bottlenecks, where are the frictions, where are interactions not well defined and therefore causing problems, which in my view could be a sort of enabling role, right? But from a flow perspective, how do we. Improve the flow in the organization where sometimes maybe we have to help teams understand ideas from team topologies, but maybe other times we have to help them learn about lean development and lean product portfolio or what have you.
Right? But having this intentional group or people in the organization whose role is to, to do that, that’s something that I. I think the return on, on [00:40:00] that kind of investment is, is really high because as soon as you start identifying bottlenecks and you start to see where the work is, is waiting because of dependencies, unnecessary approvals and, and this kind of things, when you start to remove and unlock that.
The value to the organization is can be really high. And so having some people focused on that, obviously you, ideally, the teams themselves have this awareness and they raise. Issues where we are blocked or you know, the way this platform service is provided is not really helpful. That would be healthy, in my opinion, if the organization is set up so that everyone feels they can raise issues around flow.
But you probably. Would benefit a lot from having a group of people who are focused on this. Some organizations like ING Bank, for example, they do have a ways of working group. I’m not sure that’s still the name that they use, but [00:41:00] people who are helping. The rest of organization, learn about flow, learn about better ways of working and and things like that.
So I see that as a kind of flow enabler approach as well.
Alexis: Excellent. Thank you very much, Manuel. Thank you for having joined the podcast today.
Manuel: Thank you.
Leave a Reply