Tap into Fast Flow with Team Topologies & Platform Engineering

Five Years of Team Topologies

Julian Wood: Welcome to another episode of "GOTO Unscripted" from the fabulous GOTO series. And I'm joined by seriously one and only Manuel Pais. Manuel, welcome to "GOTO Unscripted." How are you today?

Manuel Pais: I'm good. Thank you for the invitation, and congrats on saying my name very close to the actual Portuguese pronunciation. I appreciate that.

Julian Wood: My Portuguese, unfortunately, is not particularly good, but I thoroughly enjoy Portuguese tarts. So that's my enjoyment...

Manuel Pais: So do I.

Julian Wood: ...of many things Portuguese. So Manuel, you're obviously very famous for being one of the co-authors of "Team Topologies." It seems crazy, but that's five years ago. When you look back at five years of "Team Topologies," what goes through your head of what's been going on, or how do you reflect on it?

Manuel Pais: First thing is it seems like 10 years or 15 because so many things happened. Obviously we expected the book to dwell with a certain audience. The book was published by IT Revolution, which they've published several reference books, "The Phoenix Project," "DevOps Handbook," "Accelerate," etc.

So we knew we were in good company, but we were a bit surprised how quickly the book sort of reached a much larger audience and all sorts of people from Agile coaches, architects, even people who are individual contributors who just found the ideas very appealing, I guess, and meaningful. And I think it makes sense because effectively both me and Matthew Skelton, the other author, have a software engineering background. So in a way we were applying with our customers before the book came out software engineering principles and approaches to how we organize teams because that ended up being usually a bigger problem than the tools and practices if teams don't communicate when they should, if there's lack of clarity on their responsibilities and interactions and so on. We were surprised how quickly it got to a large audience and keeps expanding. Then a lot of things happened.

Some of the highlights for me, in particular, have been that we've been able to set up an online academy for video-based training for people and organizations to be able to scale the ideas of team topologies. We've created...we expanded the research around team cognitive load. So we now actually have a model with the help of Dr. Laura Weiss who has a Ph.D. in psychology. She brought in all her experience and the research that's available to actually how we identify the drivers of team cognitive load.

We actually have built a product around it called Teamperature, which is sort of in... There's already a version available and we've been getting good feedback from customers, but there's still a lot more that we want to research, and find out about team cognitive load. So that's another highlight. And then, of course, seeing how many organizations have adopted the ideas at different scales, different contexts.

I think, for me, one of the strong points of team topologies, which was intentional from the beginning, is not to be too prescriptive, right? If you read "Team Topologies," you don't come out with, okay, this is the model we should implement and create these teams or those teams. It's more about the principles of fast flow and managing cognitive load and then sort of building blocks, almost kind of like a Lego, right? These are some building blocks that are probably helpful if you want to organize for fast flow.

So we saw adoption really by now across multiple industries and scale. In the first years, so 2020, 2021, it was clear that it was more early adopters, kind of smaller companies that had the buy-in from leadership that, yes, this makes sense for us. And even the first case studies that we published on our site, on teamtopologies.com, were really those early adopters.

But then three years, three, four years later, we start to see a lot more recognizable brands and big companies. So there are some really good examples from even JPMorgan, SAP, ING Bank in Europe, and other examples. So that was really a highlight.

The last one, and then I'll stop, is the Fast-Flow conference. So there is a conference that has happened for two years in London, which is sort of the starting point of Team Topologies, but then it's really about talking about fast flow, how we organize other approaches that combine well with team topologies. So this is a nonprofit conference that has been run by volunteers in London who have done an amazing job. And it's actually going to be the first Fast-Flow conference in the Netherlands at the end of March 2025. So those are some of the highlights that come to mind, but there's a lot more.

Recommended talk: Insights on How Team Topologies Drive Organizational Success • Manuel Pais • GOTO 2024

Bridging Communication Gaps with Team Topologies

Julian Wood: Team Topologies, in my mind, sort of boils down to solving a communication challenge, and part of it is technical communication and part of it is human communication. So what do you think resonates with team topologies with organizations, big and small, that are adopting it? What do you... Communication is a tough nut to crack, especially when it's us IT nerds who have difficulty either communicating or think we know what's best or don't know how to navigate this whole, you know, software industry that we're in. So what do you think sort of really resonates with people?

Manuel Pais: That's a good question. I think from what I've seen, part of it is obviously team topologies also build on Agile, DevOps movements, especially DevOps. We were strongly involved, both of us, in DevOps and continuous delivery sort of movement. I think one of the key reasons is many organizations have done or are focused on this move from being project-oriented to being product-oriented.

And from Agile, they got this, you know, focus on teams being more autonomous, being able to deliver more autonomously. But I think there weren't enough of those building blocks that I was talking about, like, okay, how do we actually do that in a way that makes sense? And some organizations were sort of burned a little bit by the fact that they assumed autonomy means, well, the team can do whatever they want.

As with most complicated things, you need a balance, like, yes, the team should be able to make decisions faster by themselves, but also there's an aspect of how we leverage and make sure we're not, you know, having every single team doing things differently or repeating the same things. And so also kind of the product orientation, which means partially you need to have much more focus on the customer. As you said on kind of technical people, we're very strong in technical side. Sometimes we don't have that kind of focus on the customer.

It wasn't very clear, I think, for many organizations, how do we do that? How do we get these teams that have traditionally been more focused on development, on the technical side, how do we get them to be more product-oriented? And I think "Team Topologies" provide some building blocks for that in terms of cognitive load and thinking about, actually, if you want the team to focus more on what is called germane cognitive load, on focusing on kind of the problem space and the solutions space and who are your customers, what user personas do you have? All this is kind of more product-oriented. If you want the teams to really be able to focus on that, you need to reduce some of the more technical details that are often burdening those teams, right?

That's what I think is that combination of providing some ideas and ways to organize that, yes, promote this product orientation and going faster, which is obviously what many organizations want is to, hey, why can't we deliver this stuff faster to our customers? And "Team Topologies" provides the kind of building blocks that I think we're missing from Agile because Agile was more... In some way, and I didn't want to... Obviously, Agile was super important, but it was often more about intent and not how do we actually put this into practice in a feasible, realistic way?

Julian Wood: And I think this is also parallel with DevOps where lots of people say DevOps is undefinable because it isn't a tool, it isn't a practice, it isn't the people thing, it's all things together. But obviously, we're in a people-driven business, and "Team Topologies," I think, provides that sort of framework for not just organizing your teams, but understanding how your teams think about what they do and their part in this sort of machine of a company software delivery lifecycle.

Manuel Pais: For sure. With some customers, I worked even directly with the teams to help them understand who really are your customers, who should you be focused on. And you'd be surprised or not that many teams don't have clarity on that. Who are we working for? They have different responsibilities, different things they need to do, but at the end of the day, they don't have that focus on the customer. Are we really helping the customer and the business, obviously?

As you said, just helping teams have this focus and the types of teams that we talk about in the book then help. I think Matthew said he acts as sort of a magnet. If you want to be this type of team, let's say, streamlined, then you should be focusing on the end customers who buy your services or products. You can't be focusing on all potential customers. You need to have sort of a kind of domain of responsibility that makes sense, that's reasonable for one team. And so, it helps teams.

I've had teams tell me, "Well, we think we're streamlined because we work for external customers, but we're also a kind of platform because it provides internal services to other teams and we're also helping enable other teams. It's like that's probably too much, right, if you're doing all those different things. So we need to find a balance.

Obviously, team topology is a lot about how the team of teams works together, like this grouping of teams, working together and communicating when it makes sense to communicate and collaborate, and on the other hand, acting more like a service provider when that makes sense, when that helps with fast flow?

I think those things really have helped teams sort of start to focus more and have a better understanding of why we are here at the end of the day? What is the value we provide to the business? Because often, yeah, the business itself, if you like, especially organizations where you have an organizational divide between technology or engineering and business side, which is still the case in most places, then yeah, the teams who are on the engineering side don't always have that clarity, like what exactly is the business goal here? Who are the customers we should be focusing on and should be understanding a lot more how we help them or don't help them? Etc.

I think that another aspect of Team Topologies is bringing this, which we've been talking about for, I think, decades of bridging the gap between business and technology. I think Team Topologies helps a little bit with that, as does obviously kind of more generally the product orientation and customer orientation.

Recommended talk: Adaptive Socio-Technical Systems with Architecture for Flow • Susanne Kaiser • YOW! 2023

Unlocking Fast Flow by Managing Cognitive Load

Julian Wood: You've been talking about cognitive load as being sort of, I presume, one of the blockers to flow. Would you mind just explaining flow a little bit? What does that mean? Is it between organizations, within an organization, software coding, speed? Those are all the things that come into my head, but I'd love to hear you just define what flow means and then this cognitive load measurement that you're talking about and how to interact. Because I would gather that removing cognitive load or simplifying cognitive load allows more flow. Is that correct, or how does one understand that?

Manuel Pais: There are some nuances to that. So in terms of flow, obviously, there are many different definitions of flow. In Team Topologies, we're talking about the ability to deliver changes to your customers and to the business in a rapid way, but also a safe and sustainable way. So that's how we look at flow.

Then the next step is, what do we need for fast flow if we want to accelerate this delivery of value to the customers? There are some implications of wanting to be a fast-flow organization where you need to expect then, first of all, we need to have teams aligned to these different flows of value, right? That means we need to identify, understand what are different flows of value. What are the things that we provide to customers that are valuable, that they pay for usually or there's some other benefit to the organization? 

Many don't really have that clear picture yet, surprisingly, even trying to understand, okay, what are your value streams? Things get quickly kind of blurry because maybe they've built this big product that does a lot of things. It's not super easy. So that's one part of if you want fast flow, you need to have this clarity on your value streams.

Then the other part is once we have more clarity and we can align teams to these different flows of value to the customer, then we would expect those teams to work mostly in parallel, right? They're delivering to a certain set of customers or they're delivering on a specific user journey or whatever kind of the split might be.

If teams are working mostly in parallel, delivering in parallel, so we have less synchronization needs, we have less coordination needs, so we're more customer-focused and less project-focused, then there's also expectation there will be some level of duplication on the things that teams are doing, right, because we're not trying to coordinate everything and release things in big blocks. We're allowing flow and we're allowing teams to work more in parallel. So there are some important kinds of consequences or realizations we need to have. If we want fast flow, then we need to accept some level of duplication.

I was talking recently with someone who is in senior leadership at AWS and probably familiar to you. According to him, that's something that is expected in AWS. There is some level of duplication, and then at certain points we sort of converge and figure out, okay, what are the things that maybe we need to stop doing because now it doesn't make sense. But to go fast and to be able to innovate fast, we need to allow some level of duplication. So things like that are maybe not super familiar for many people in leadership positions.

Then the aspect of team cognitive load, like you said, I think it's a good way to see it. If we don't pay attention to team cognitive load, it's going to probably start slowing down our delivery of value and putting a lot of weight on teams if they have too many things that they need to worry about. Yes, sometimes we need to reduce cognitive load. Today there's a lot of obvious interest in platform engineering and platform as a product, also partially due to team topologies, but all the kind of platform engineering movement as well.

That's one of the main purposes from team topologies perspective, is the platform should reduce cognitive load for the product teams or streamline teams, as we call them, especially on things that are not differentiators for what those teams are delivering, right? So tends to be or at least start with a kind of infrastructure and software lifecycle type of services that it doesn't make sense that every team would have to worry about doing their own...using their own tools, setting up all these different services for themselves usually.

But then there are some nuances or important nuances about cognitive load, which is that we're not always reducing cognitive load on teams. We're trying to have them focus on the right things. Sometimes we increase cognitive load, especially if you have teams, for example, that lack some skills or competencies.

If you think like more traditional development teams and if you want them to be more product teams, they're going to need to have more kind of product management skills and at least some understanding of how you do that, even like going from being a development team to a build-and-run team, so kind of team that supports their own service, and also some new skills.

So we often are increasing cognitive load on teams or maybe their responsibilities are changing or they're moving to a new domain of the business. Yes, cognitive load is going to increase at those points, but that sort of should be... If it's an intentional decision, yes, we understand for a period of time, the team is going to be more loaded because…

Recommended talk: Team Topologies, Software Architecture & Complexity • James Lewis • GOTO 2022

Julian Wood: So it's an intentional learning experience to take on something new to improve flow in the future.

Manuel Pais: I like to say you put on cognitive load sometimes and then you look at how you take off some of that cognitive load on the things that actually you shouldn't be spending your sort of capacity on those things.

Julian Wood: So it's evolving. 

The Role of Full-Stack Developers in High-Performing Teams

Julian Wood: Sometimes we love to load the sort of full stack engineer or the full stack developer who looks at sort of everything from the application all the way down, maybe to the infrastructure. And I always sometimes struggle with that because I think that's a lot of cognitive load to take on when a developer is doing front-end, back-end data processing, authentication, all these kinds of things.

In an organization, is a full stack developer a desirable thing or something which shows maybe a lack of maturity, or what do you think of full stack developers?

Manuel Pais: That's an interesting question. I mean, for sure, I agree that it's very challenging. You do have some people who have that ability to just kind of go, you know, at different levels of the stack and be able to make changes like that. But from "Team Topologies" perspective, we intentionally sort of in the book, we kind of stop at the team level in the sense of we want stream-aligned teams to be cross-functional for sure. We want them to be able to take ownership of some service or some part of a larger product that can evolve independently from end to end, right? Understand the customers, understand what they need, hopefully, be able to run experiments and see if things are helping or not. They need to get the data from the live service and obviously do all kinds of the development tasks and deployments, etc.

A lot of things already that we're asking from the team. We intentionally didn't go into the detail of should you have a full stack developer plus product manager? Because there are different configurations that are possible that make the team able to respond to that kind of end-to-end ownership and have that cross-functional, those skills.

Different organizations use different approaches. It probably will be difficult to make that work if you have very strict roles, right? If you have, oh, this person only does product management, this person only does front-end, the other back-end, the other testing, and so on, because then you end up with teams of 15, 20 people, right? So that's not a very feasible way.

So yes, there is some expectation that these teams will have people who are, like, usually, we talk about T-shaped or comb-shaped. They might have a specialism or two in maybe back-end and data or something like that, but they are able to know enough to make at least some kind of more common changes on front-end and other parts of the stack, right?

So there is some expectation because we don't want teams to be that large. Usually, less than 10 people is sort of the maximum for high trust. That implies, yes, people will have to be able to do multiple things and not have very strict roles, but also it doesn't necessarily mean that everyone's full stack and knows everything top to bottom and can do all changes.

Recommended talk: Effective Platform Engineering

Building Effective Platforms

Julian Wood: I suppose it's also organizational size, a nimble startup which is trying to do things. I mean, the founder may end up doing everything and then a bigger organization does things in a different way.

You did mention platform engineering, and obviously on the back of team topologies, that has obviously had a very important resurgence in terms of how infrastructure teams and platform applications teams work. And I know you have a nice concept of sort of the thinnest viable platform and you've spoken about platform as a product. So two sorts of questions. What do people get wrong, and what do people get right about platforms?

Then I also spotted on the sort of hype cycle that internal developer platforms and portals are at the absolute peak of inflated expectations and looks as though it's just about a head down the hill. So how does one square these kinds of things when people are wanting to build platforms/portals and doing platform engineering? What advice would you give people?

Manuel Pais: I think the main thing with this platform engineering movement... And I know some of the people who have been pushing this movement and you're probably familiar with the platform conference that has been happening for a few years, which I think is today still sort of the reference for platform engineering.

Obviously the technology changed drastically in the last 10, 15 years. But if we only focus on the technology, if we say platform engineering is because we have all this new technology and we need to... Yes, part of it is how we leverage and how do we use it in a proper way, and so on. That is part of it, but then it's not enough from my point of view because then we run the risk of...

When I started in the industry almost 25 years ago, we already had platforms and they were focused only on technology. How do we manage technology better, reduce costs? Things like this, which are not bad things, but today, at least from a fast-flow perspective, what you need to focus on as your starting point is, is this platform or service going to help teams reduce cognitive load and go faster and accelerate what they need to do? Right? So there's also the idea of paved roads or golden paths, whatever you prefer, like making things easy for product teams or streamline teams so they don't have to worry about all the details.

So if you don't start there, if you're just focused on technology, I think you might get to sort of the usual anti-patterns that we build stuff that is not easy to use, not easy to understand, or we've done too much internally instead of, like, what is the thinnest viable platform? Right? What is the minimum we should do that accelerates our internal teams, reduces their cognitive load, but also we're not bloating a platform with a lot of technology and building stuff that is actually not needed?

So the thinnest viable platform is obviously inspired by the minimum viable product, right? But it's really...it should help platform teams and groups make better decisions in terms of what we build or not build. So we start from you actually need to understand your internal teams, your customers that are internal teams. You really need to understand their workflows, what are the things that are consuming or that are painful for them, and then figure out what is the minimum thing that can help them.

Then you iterate obviously over time, but you try to focus on the things that really make a difference. It's almost like you see the platform as a kind of startup, like how do we get internal customers to use our product? So therefore the idea of a platform as a product. So like a good startup, you should be focusing on, what is the minimum thing, the thinnest thing we can provide that helps the teams and shows value? And then we go from there.

Julian Wood: The quickest way to get feedback, and you're not building a platform for a platform's sake and hoping people will come to your platform, but building a platform as a product, as small and nimble as possible, getting feedback to be able to evolve the platform for ultimately what your developers want to delight the developer experience. And you're only going to know that when they use it and they do weird things.

So I think one of the comments I've heard before is that if people are using your platform and they're not doing things you don't expect, then your platform actually maybe isn't expensive enough or maybe isn't useful enough.

Manuel Pais: Or you're not communicating enough to find out that it's being used in all kinds of ways. I think in the past, one of the signs that the platforms were too much focused on the technology and not on the usage was that often teams, and I had that experience as well where teams being forced to use the platform and that platform increases cognitive load because now we have to understand what is the platform doing? Oh, this is not a good fit for what I need, but I need to use the platform and then I need to do other stuff, workarounds to actually do the thing that we need for our application or service. So there is a clear sign that the platform is not being thought of as kind of a product for internal customers.

I would say kind of modern platform engineering and platform as a product is not easy because we're asking from those teams that many people have come from kind of traditional more infrastructure focus and now you're asking them to, okay, you need to treat this as a product, you need to collaborate with your users, you need to understand the needs, you need to do all these things that are not super familiar to them. So there is that sort of learning path that is needed for the platform teams as well.

Julian Wood: Probably product management skills rather than just program management skills. This isn't a project that's going to come and go in six months. This is a living product.

Manuel Pais: That is definitely one of the big challenges, the product management side. There are some good examples. I remember for one of the courses we have in the Academy, which is called Platform as a Product, one of the case studies from a company called HelloFresh, I think they're quite known in Germany and some other countries, but they had a really strong product management inside the platform.

I really believe you need people with product management experience because you need to have lived it and gone through the learnings of that type of work, and how do you prioritize, how do you communicate with users? Because you need to be very consistent as well, right? If the platform is successful, you're going to get more requests, people are going to be like, "Okay, can you do this? Can you do that for us?" So you're going to get more...you're going to need to have even better prioritization and consistency and communication, right? And those are things that a good product manager with experience will help you with.

But it's still a bit of a struggle. Many organizations I talk to, kind of the platform leadership who are technical, they say, "Yes, we really want... We know we need a good product manager, but the organization is not investing in that." And I think, yes, you can have someone who has a technical background, work, take kind of this product management role, but if they don't have the experience, then it's going to be difficult for them.

I think it's easier for someone coming from the product world, if you like, to understand enough of the technical side of the platform because they really just need to understand what it's doing, what value it's providing. They don't necessarily need to work on the technical side. So I think that's a better approach than having someone who's very technical try to do product management work when they don't have the experience.

Julian Wood: That's an interesting observation. I think products have more than just the technical part, it's the leadership part, but also products need marketing, they need sales, they need metrics, they need all these kinds of things rather than just the awesome developers on the keyboard.

Recommended talk: Expert Talk: Five Lines of Code • Christian Clausen & Julian Wood • GOTO 2022

Starting Small for Sustainable Organizational Change

Julian Wood: Just switching a bit over to organization. In a way, the question is sort of where do people start? Because it's obviously very easy when your organization isn't delivering and you don't have fast flow and things are going wrong. We will do a reorg and that will sort out everything. And "Team Topologies" has some great formulas and ideas for reorganizing things, but where do people start? What should they be understanding before they're even thinking about reorging? Because recordings can leave teams clueless and even more overwhelmed and more understood.

Manuel Pais: We suggest trying to avoid big reorgs and actual focus, which is again something that you should expect if you want to be a fast-flow organization if you do a lot more frequent small changes to the organization itself. Well, we need this new team or we need to change, kind of adjust the responsibilities between these streamline teams because right now they are too dependent on each other perhaps.

For fast flow, you would expect the organization to get to a point where these smaller decisions that have to do also with how we organize can happen based on actual challenges, of course, but can happen much more frequently, almost like continuous evolution of the organization.

That said, obviously there are situations where the organization is very far behind and they believe they need to do a bigger reorganization. But even in that case, I would try to start with a small number of teams that... Because as I said, it's also not about individual teams, it's the team of teams.

If you're in that kind of position where we really need to change a lot because everything is slow and we don't have kind of product focus, etc., and customer focus, I would look at what is one area of the business typically, depending on what you call it, a business unit or business domain, where maybe we have five, six teams or maybe a few more or a few less, but something that can help us figure out, okay, if we have more traditional development teams and infrastructure, we want to take this approach, what would we need to do? Well, we need this team, maybe we need to include someone with these other skills in the team to be more streamlined. Let's start up some platform service to help with some of the cognitive load issues.

I believe with that smaller group of, I would say probably between 5 and 10 teams, that you can actually take that smaller step of understanding the new dynamics because a lot is about, like you were saying in the beginning about communication, interactions between teams. So it's more as a kind of pilot or whatever you want to call it. Let's learn from this smaller group of teams who are trying to get them to be more focused on flow on customers while controlling cognitive load. So let's try to make that work. Learn from that. And then it might be a better moment to start scaling to the rest of the organization.

For example, just recently I did some workshops in Brazil, and the scale there is very large. I was doing some workshops for some banks where they have...one bank had like 13,000 people in engineering and they're trying to do this digital transformation, including things like Team Topologies, but DevOps and other things and they have to do it in phases, right? They do sort of this pilot approach first and then they take a larger group of teams and then they make sure they get the learnings from that. What worked with this larger group of teams? What are some of the things we learned that are a bit more challenging? And then they go and apply to an even larger number of teams. So definitely depends on the scale, but starting small is always a good idea.

Common Pitfalls in Implementing "Team Topologies"

Julian Wood: People read "Team Topologies" and they rub their hands and they go, "That is great." What do people do wrong when they try to implement or do some things from "Team Topologies?" If there was maybe a slight, you know, addendum to the book where people go, "Yes, excellent," what's the thing when you'd speak to people that they mess up or misunderstand?

Manuel Pais: I think one of the main things, and we saw this kind of, like I said, with the early adopters. Some of those organizations made good progress. So the ideas in "Team Topologies" helped them and they reorganized with this idea of streamline teams, platform-enabling teams. But then at some point, they sort of hit the wall where they said, "But we expected maybe to even go faster and be able to deliver more value faster."

Turns out some of those organizations didn't have that clarity on the value streams that I was talking about earlier. So I think that's one big takeaway you might... And you can start things in parallel. Obviously, you can try teams to be more cross-functional, streamlined, but you need to do the work also of understanding better your value streams.

I often reference the book "Sooner Safer Happier" from John Smart, also from IT Revolution, because he shows some of the patterns he used at Barclays Bank in the UK, like breaking down the value streams into what he calls nested value streams. So whatever approach you use, just having this clear understanding, okay, what are the things of value to the customers? Because if we don't do that, if everything is sort of tangled together from a business side, how are you going to align teams to smaller flows of value if you can't identify them?

The other thing that...maybe two more things that we would have at least highlighted more in the book if we had to rewrite it is when we talk about fast flow, is fast flow of value to the customer is not just making changes faster. Because if you're doing the wrong thing, you're just doing the wrong thing faster. So it implies, and I think that was, like I said, strongly influenced by DevOps, this idea of having a very fast feedback loop.

That means ideally that feedback loop is inside the team and you need to be able to look and see what's happening when you actually are delivering these changes to your customers or audience. Are they using it? Is it being used in the way that you expected or not? Is this actually helping whatever business metrics we're looking at, whether it's retention or more sales or whatever it might be?

When we talk about fast flow of value, implicitly there's this, yes, kind of forward...increase the speed of delivery, but then also accelerate the feedback loop back to the team. Some people sort of understand it more as just let's go faster, let's deliver features faster, right? So that's definitely not the point.

Julian Wood: I was going to ask the exact same question. If you had to rewrite "Team Topologies" today, what would you change? So it's interesting that you picked up on that.

Manuel Pais: The other thing I would say is also part three of the book is around the evolution part, like we were discussing, where do you start? Do you make big reorgs or not? And that part sometimes seems to be overlooked because people get to the team types and the interaction modes. Okay, this is all we need. But actually, part three is quite important. So maybe we should have put that earlier in the book or stress it more somehow. That would be the other thing.

Julian Wood: Right. Interesting. So I mean, the sort of negative of it, I suppose, is you need to be very clear on your North Star, who your customer is from the very beginning and from the very top. Even if you're a lower-level platform team, you still ultimately need to know what the end customers are wanting from the streamline teams and how that flows all the way down. And then seeing how somewhere, even your work can flow all the way back up to the very top, that you're sort of delighting your customers in a quicker way. I suppose that's the communication challenge we're all trying to solve.

Manuel Pais: Absolutely.

The Impact of AI on Software Development and Team Topologies

Julian Wood: Now, obviously, it's nearly 2025. In fact, when this recording comes out, it may be 2025 already. AI is obviously huge everywhere. What are your thoughts on how AI affects software development and team topologies and the industry that we're in and the work that you do?

Manuel Pais: It's already having a strong impact and we're still... If we look at it from what is usually the life cycle of these big innovations, probably we still have some more years of more innovation and things coming out that we don't even know today. So definitely, it's going to change some things. We're going to have more obviously AI agents helping teams and teams using more of the tools for generating not just code, but actually, we could come to a point, I think we're not exactly there yet, but we could get to a point where, let's say, a team could create a whole new product that didn't exist yesterday in a few hours.

But those teams still need to have the ownership or the stewardship of that value stream. Again, going back to the same conversation, because the risk I see, and again, it's early days, but I kind of see the risk that we start to rely more and more on what AI provides, and we don't have really anyone or teams that actually are kind of guiding this value stream and whatever products that maybe become perhaps more disposable in the sense of we can try things faster at the larger scale, like let's try a new product. Let's see what happens for a few days, and we might just say it's not worth it and stop it.

What is the value stream on top of that product? Right? What are the actual customers you're trying to help and the problems they have so that you can then have this faster solution through AI? But who is kind of guiding that work? And I believe that it's going to be even more important to focus on fast flow because the organizations that don't, in that scenario, they're going to be very quickly behind, right, if now we're talking about not weeks, months, but we're talking about hours to deliver a whole new product, assuming we get to that point.

If you're behind and you're still working in weeks, which maybe is fast now to get a new product out, but at that point, it might be way too slow, right? So it's new...obviously, going to have a strong impact. It's early days, but it's interesting to think about some of these aspects.

Julian Wood: Yeah. In fact, that's an interesting point where the idea of reducing cognitive load and fast flow is often about teams being unable to write software really quickly, and that whole process just takes a huge amount of time. But with AI, that process can actually take a really short amount of time, but that means that if you're not doing the right thing, if you don't know your North Star, you don't know where you're going to, in fact, you're doing the wrong thing far quicker and at a far bigger scale.

In a way, going back to the fundamentals of understanding the reasons, your value stream mapping, where everybody fits in the organization, where everyone's aligned to, not from necessarily a team alignment, but from a customer alignment, and your organization can be very agile in the way it works, then AI would be even more of an accelerant of the right things rather than the wrong things.

Manuel Pais: Absolutely. It will be interesting to follow and see what happens.

Julian Wood: I mean, even a controversial take when people say, "Oh, well, software engineering is going to die because AI is going to take over everything."

Manuel Pais: I don't think that's going to happen. There's also some arguments that, well, we're going to have teams of one. One person can do everything. Maybe we'll have kind of smaller teams than what you see typically today because there's more things that AI can help us with and that reduces cognitive load. Obviously, it needs to be in a way that makes sense that what we're doing is sustainable in the long term. It's not just that we can build stuff very quickly for the next few weeks but then we don't know how to evolve it.

So there are some interesting aspects there, but we're still going to need software engineering. We're still going to need people to understand what makes a good product, what are the right kind of practices to evolve the product in the long run and to run it properly, even if we have a lot more help perhaps from AI. But we still need someone who's sort of at the helm, right? And so those might be smaller teams perhaps, but I don't think we'll get to one person who can do everything by themselves.

Julian Wood: Back to the full stack engineer, augmented by AI, and maybe the X as a service team now becomes an AI agent. They can certainly be helpful with this. Ultimately, the AI hasn't quite figured out exactly what your customers need yet, so we need humans in the loop still.

Manuel Pais: Yes.

Building Organizational Capability for AI in Software Development

Julian Wood: Is there anything today that's top of mind that we haven't covered that you would like to mention or think about? What's top of Manuel's mind at the moment?

Manuel Pais: Well, since we're talking about AI, if you think even other kind of approaches like machine learning some years ago and other kind of novelty approaches or ways of doing things, what I'm trying to help organizations today is to understand AI, even if we've seen already a lot of huge progress, it's still serving, you could probably say it's sort of infant days. So there's more that's going to come, and probably as an organization, you need to start building.

Yes, of course, many organizations are using Copilot or using some tooling, but I think a more strategic way to look at it is we need to have some... We're going to need this organizational capability of leveraging AI like we did with machine learning, for example, some years ago. So from an organizational perspective, I think you need to start thinking about, okay, maybe we need some kind of what we started calling structural enabling teams or groups, people who are going to be able to keep up to date with what's coming, how does this make sense in your organization? Which teams in your organization would benefit from using these practices or tooling or approaches? So you actually can leverage this and evolve over the next, whatever, 5, 10 years.

We actually have an interesting case study from a company called Bol.com, where they did that for machine learning, data science, starting 2014, '15. What started more as a kind of functional area where you had a few teams responsible for doing the machine learning, data science models, etc., they realized, well, now more and more product teams should be using this, so it needs to become more of an organizational capability how we do that. And they started this department which had effectively this enabling role of identifying what are the needs of the different teams. How do we help them upscale, how do we help them also with some kind of platform that reduces some of the cognitive load around machine learning and stuff like that? I think the same for AI makes a lot of sense.

Julian Wood: Excellent. Well, Manuel, thanks so much for your time today. I really appreciate you spending time with "GOTO Unscripted" where we hear from some of the best people in the industry, and "Team Topologies" with Matthew Skelton has, I think, been a groundbreaking book to make people think bigger than themselves and work within their organizations and just understand customers and understand our weird and wonderful software industry. So thank you for spending the time with us today.

Manuel Pais: Thank you so much. It was my pleasure.