Unlocking Flow and Effectiveness

Alexis:

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 having me. It depends on the context, but in terms of explaining what I do, the most difficult is to explain to my kids. Someone told me this week, I think a good way to think about it is almost like a teacher for companies.

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 — all the motivational aspects of getting teams to feel more autonomous and empowered, and also delivering more value more independently to the customers.

I've always had interest in the educational part. I've done a lot of editing and reporting for InfoQ as well. So although I'm a software engineer by background, I really like to help people, teams, and organizations reflect on what they might need to do differently in order to improve flow, improve the way we work, and provide more value to customers.

Alexis:

I really like the idea of increasing the value and increasing the satisfaction of the people who are within the organization. Team Topologies has been incredibly influential. What initially drew you to the challenge of organizational design?

Manuel:

I think there were a couple of things. One is, out of my curiosity to learn and try new things. I started my career as a Java developer, then had different roles as tester, release manager, and team lead. That allowed me to look at the same things from different perspectives. I have about 25 years of experience, so I can remember well when there was friction between the test team, the ops team, and the dev team — teams being very isolated, trying to do their best within their scope, but that wasn't always helpful for the customer waiting for changes or new products.

That got me thinking: at the end of the day, we should all be working towards the same goal — to deliver this product or new value to the customer. So why do we sometimes have very antagonistic views of each other?

When I moved into consulting around 2015, together with Matthew Skelton, we were doing consulting around DevOps and continuous delivery. We had this feeling that a lot of the issues are not so much technical as they are about people, interactions, sometimes lack of direction, or too much isolation between teams. We would often have client engagements where we were asked for a more technical job — implement pipelines, help adopt DevOps practices — but the real issues were happening in the interactions or lack of interactions between teams, and incentives that were not aligned.

During those consulting years, we were essentially applying the patterns we now talk about in the book and our academy with different customers. Today, almost six years after the first edition of the book, it's really great to see so many examples and case studies of applying many of the team topology patterns together with a lot of benefit 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 four types of teams you describe in the book?

Manuel:

Sure — it's a bit like playing your greatest hits. The starting point are what we call stream-aligned teams. These are very much your cross-functional product teams, with two particularities. One: they have end-to-end ownership of a stream that is valuable to customers. There are clearly identified types of customers that team is serving. Two: the idea of stream itself. You could have a product team that only owns one technical component — they work on a product, but don't provide value directly to end customers. Stream-aligned means the team is aligned to a continuous stream of value to some kind of customer, and that can be within one larger product (different user journeys, different personas, acquisition vs. retention, etc.).

Once you have stream-aligned teams with as much end-to-end ownership as possible, ideally from generating ideas and experiments all the way to deploying changes available to customers — that's where cognitive load comes in. It's a lot of information overload for a single team. So we bring in support-type teams — but they're critical to allow the stream-aligned teams to work effectively.

The second pattern is enabling teams: a small group of experts in some domain who intentionally have the availability to focus on helping stream-aligned teams learn skills and bridge gaps. They're also well placed to bring innovation and new ways of working into the organization.

Third are platform teams. The platform provides services consumed by stream-aligned teams in a way that makes their life easier. If a platform actually adds effort, requires understanding how it works internally, or relies on tickets to get things done, it's not very helpful. Often it ends up being not just one platform team but a platform group — multiple teams inside the platform, ideally also aligned to streams of value to internal customers.

Fourth is complicated subsystem teams — included reluctantly. They should be used sparsely, when there's truly a component or service that is very complicated (a complex algorithm, very outdated technology with few experts) and from a cognitive load perspective it makes sense for one team to take care of it. We need to be careful not to overuse this pattern, because it can drift into component teams and reintroduce all the dependencies we're trying to avoid.

Alexis:

You spoke about cognitive load as a key element. Can you come back to that and maybe illustrate with an example?

Manuel:

Cognitive load theory comes from psychology. Essentially, what we did in Team Topologies is recognize that there's a limit to our working memory as individuals — and as a team there's also a limit to the team's capacity. The cognitive load might have different natures, even if we can't cleanly split it like a C++ program.

The interesting question is: what are the things the team is responsible for, or has to worry about, that maybe they shouldn't — because they're not really helping deliver value better, and are actually distractions? When we think about platforms, it's always: how are we going to reduce cognitive load on the stream-aligned teams? Easy ways to provision infrastructure, deploy changes, diagnose problems in production — yes, the team uses them, but they don't need to know all the underlying details. That's where we push knowledge and details outside the team.

I've talked to teams that counted over a hundred different tools they used in their lifecycle. That becomes really unproductive. After the book was published in 2019, we partnered with Dr. Laura Weis, who has a PhD in organizational psychology, to define a model to assess cognitive load on teams. We built a product based on this model called Teamperature.

What she found is that even though we cannot measure cognitive load directly, we can assess the main drivers. They can be things related to the characteristics of the work itself, the team itself, the work environment and tools, or the processes followed.

If you're just saying “cognitive load is high because teams are overloaded and stressed,” without going deeper into what's actually driving it, you're guessing. You might be lucky, or you might be working on symptoms rather than the real causes — wasting time on things that are helpful but not addressing the highest drivers.

Alexis:

Okay. So we have four labels for teams. The temptation could be to put labels on teams and consider, “oh, that's a beautiful design, I'm done.” What kind of common missteps do organizations make regarding team interactions? Because it's not only labeling them — it's really working on the interactions between them.

Manuel:

You're spot on. One big issue is that many organizations or people who read Team Topologies think that we just design a new target operating model with this perfect idealization of which teams we should have, which platforms — and now it's just a matter of executing and everything will be fantastic. That's not how things really work.

One of the battles we're still fighting is for organizations to take a much more evolutionary approach to organizational change. The good thing is there are some great examples now. I'm thinking in particular of a company called Yassir — a super-app in the North African market for food delivery, ride hailing, financial services. They had a typical growth spurt, dependencies were piling up, teams were not autonomous. They looked into Team Topologies — but they realized it's not a model to follow by the book. It gives building blocks to think about what kind of teams you might need and how things will evolve.

What they did intentionally was take small steps in roughly four-month iterations: split this team in two, make this team more stream-aligned, introduce a platform service. Try it out for a couple of months, reflect, see how it worked, and use that for the next iteration. It's like going back to when Agile was first introduced — start breaking down huge pieces of work, but for organizational change. Don't think you can put on paper an ideal design and then it's just a matter of execution. That typically doesn't end well.

Alexis:

You mentioned platform teams. Many organizations could feel they already have platform teams. But you mentioned the interaction with the platform team is not “submit a ticket and wait.” Tell me more about how platform teams should behave.

Manuel:

Before I do that, this raises the point that interactions between teams — whether platform or others — are also key to that evolutionary approach. It's not just defining types of teams or mapping existing teams to stream-aligned/enabling/platform. It's looking at the evolution and asking: are these teams interacting in a way that is helpful? Are the interactions clear?

Team Topologies provides three core interaction modes:

1) Collaboration — two teams working together on a common problem. 2) Facilitating — one team has knowledge or skills and helps another team learn and upskill. 3) X-as-a-Service — based on “infrastructure as a service.” For a platform, the goal is that services can be consumed independently: mature, resilient, with the right onboarding and documentation so teams self-serve.

For platform teams, X-as-a-Service is one of the main interactions, but an anti-pattern I see is jumping straight to “this service will be consumed as-a-service” without going through collaboration first to understand what stream-aligned teams really need, what the right interface is, what should be abstracted versus not.

There's an interesting case from Adidas where platform teams intentionally alternate between the three modes. They expect to do facilitating work too — they're typically experts in some domain (infrastructure, testing) and stream-aligned teams might not even be able to use the platform properly without some guidance. A more mature view is to expect platform teams to alternate: sometimes collaborate when building something new, sometimes facilitate onboarding, sometimes operate as a service with good support.

Alexis:

It's interesting because the way some people describe themselves tells us something about how they envision those interaction modes. I remember when the book had just come out, a team of architects in a company described themselves as “we own that complicated subsystem because all the others are too dumb to use it.” Then someone read the book and said, “oh, you're an enabling team.” But based on their behavior, it didn't look like that — putting them in that box wasn't helping because their behavior was the opposite of what was needed.

Manuel:

For sure. When we were writing the book, the purpose of these team types was also to elicit certain behaviors expected from those teams. If you're an enabling team, the expectation is not that you're hoarding complicated services and you're the only experts who know how to change them — that's definitely not helpful for fast flow. An enabling team is there to teach and mentor and help others grow, not to be the smartest in the room.

A common question after the book is: what about a startup? You don't have enough people for dedicated platform and enabling teams. To me, it's more about the behaviors — the teams are almost like an implementation detail. In a 30-person startup, mostly everyone works in stream-aligned teams. But you can still have enabling and platform behaviors: enabling can mean mentoring from senior people; platform can mean a few people dedicating a couple of hours per week to document how you use AWS, set up deployment pipelines, etc. The patterns and behaviors are there from the beginning. Dedicated teams come later as you scale.

Alexis:

I really like that — it can also facilitate the onboarding of new people because it clarifies how it works and leaves space where you don't need to learn everything. You probably work with a lot of leaders who would like to get the benefits of a fast-flow organization. What's their role in the implementation, in the way you see that evolutionary change?

Manuel:

Going back to the evolutionary approach — for senior leadership, one of the main things is setting the tone. We're not doing a big reorg where people might be afraid their role or team will change. We're going to be doing this in an evolutionary approach, learning and adjusting when things aren't right. Not just one step change and then good luck.

That doesn't mean leaders need to be directly involved in figuring out what changes are needed. It's more about providing support: let's do this and learn and evolve. And providing the support people are going to need — especially when responsibilities or competencies change. If teams are going to become more stream-aligned with end-to-end ownership, identify the gaps. If they've never done user research or testing, they're going to need help. They need to feel supported — there will be training, there will be enabling teams. Factor that into your budgets. People should not feel they're being asked to do something different without support or learning.

Alexis:

Excellent. Looking forward a little bit, are there emerging trends or new challenges you're currently exploring around teams and organizations?

Manuel:

Yes. We continue to do more research on team cognitive load. The model we have is scientific and systematic but never complete — many factors influence cognitive load. With Teamperature, teams have a pretty good view on what's actually influencing their cognitive load, but we want to explore new areas. Obviously, AI today — with all the benefits but also drawbacks. In general, AI could reduce cognitive load if it does work the team doesn't have to do anymore. But because it's non-deterministic, sometimes the tools don't have the right context, and you always need humans driving the work — so it might also be increasing cognitive load. That's something we want to research.

The other thing we expected from the start, and is nice to see happening, is applying Team Topologies ideas outside of IT. There's an example from Capra Consulting in Norway, where they applied the ideas to the whole organization — sales, leadership. They actually shut down their management group and pushed decision-making down to the stream teams. There are also examples from NGOs in Latin America: organizations promoting digital inclusion that don't build any software, but realized they had bottlenecks in delivering social initiatives — so they're looking at whether a team could become more of a platform team so they're not a bottleneck. I think we'll see more examples of applying the patterns way beyond engineering and technology.

Alexis:

You mentioned the Teamperature assessment. Is it something already available today?

Manuel:

Yes. Go to teamperature.com — it's a product, but you can also find details about the model behind it. Teamperature is the implementation of that model. It's free to use for up to 25 teams. I'd love feedback if people want to try it out and see what they think of the results.

Alexis:

Excellent. Thank you for joining the podcast. The one thing I'd like to ask is: what is the question I should have asked you?

Manuel:

That's a difficult one. We covered a lot of ground. I think there's still more to say about how you do this transformation — from a project-oriented organization, to a product-oriented organization, and in my opinion, to a value-stream-oriented organization, where products are a means to provide value but you also have a higher-level view of value streams. This journey takes time and isn't always easy.

One part is to take an evolutionary approach. The other thing I've seen in many organizations: they haven't invested in internal people who focus on flow. We talk about fast flow — yes, you have transformation programs — but few people whose actual role is to look at flow: where are the bottlenecks, where are frictions, where are interactions not well defined? In my view it could be a kind of enabling role, but specifically about flow: how do we improve flow in the organization? Sometimes that's helping teams understand Team Topologies; other times it's helping them learn lean development or lean product portfolio.

Having an intentional group or people whose role is to do that — the return on that kind of investment is really high. As soon as you start identifying bottlenecks and unlocking work that was waiting on dependencies and unnecessary approvals, the value to the organization can be really high. Ideally teams themselves have this awareness too and feel they can raise issues around flow. Some organizations like ING Bank have, or had, a “ways of working” group helping the rest of the organization learn about flow and better ways of working. I see that as a flow enabler approach.

Alexis:

Excellent. Thank you very much, Manuel. Thank you for joining the podcast today.

Manuel:

Thank you.