Team Topologies approach to platform teams vs. enabling teams

‍Abi: Manuel, thanks so much for coming on the show. Super excited to have you. Excited to chat today.

Manuel: Thanks for having me. I quite enjoy the podcast.

Abi: Glad you’re enjoying it. Well, I reread your book last week ahead of this show, and first one is to just pay you my compliments here personally because it’s such a fascinating book, particularly relevant to my work. And I think listeners of this show who as you know are involved in platform and enablement work. So today I want to start with some of the fundamental topics, namely around the definitions around platform teams and enabling teams. And a way to set the discussion might be, there’s been a few comments recently from notable people such as Sam Newman. He wrote an article recently called Don’t Call it Platform, Call It Enablement.

And a few weeks ago on this podcast I spoke with Mike Fisher, former CTO of Etsy, who also mentioned that they explicitly decided to not call their teams platform-teams. Instead, enablement teams. And when I was reading your book again, I realized that you actually define these two distinct types of teams, enabling teams and platform teams. So I want to kind of dive into those two different types of teams and start by asking you what’s your opinion on what Sam Newman shared around the naming problem?

Manuel: Sure. I think you got the main point is that it’s a naming problem and it’s a behavioral problem. And so I can first tell you quickly from the point of view of the Team Topologies’ book, what we try to do is exactly define more precisely what is platform team, what is an enabling team so that we have a better shared understanding of if we say a team is a platform team, what should they be aiming for? And if we say a team is an enabling team, what should they be aiming for?

And so for us, we took the definition of a digital platform as being a set of tools, APIs, can be just a wiki page, something that allows other teams to self-serve, first of all, and to basically accelerate their own work. So usually we’re talking about product teams that consume the platform services. And so platform team essentially ends up being an internal product team, a team that creates services and tools and products if you want to call it that for internal use in the organization.

And then we talk about expected behaviors and so on. This actually helps bring closer together platform teams and product teams because you can actually adopt similar ways of working. You can adopt similar techniques to understand your customers. The difference that platform teams have, internal customers and product teams or stream aligned teams as we call them in the book for specific reasons, have external customers, customers that are outside the organization. And so they’re pretty close, but there’s some important differences. First, usually the type of services are more technical in the platform. They might have less of an actual user interface, but they still need to have a good user experience.

And finally, the customers are internal. They’re not external, which has pros and cons. It means we should have more direct access to our customers because they’re our peers at the end of the day. And if that’s not the case, then there’s probably other issues going on in the organization, but they’re also because they’re our peers, they might be more demanding or we might assume we know what they want from the platform. And that’s not always the case if we don’t actually do the customer research work. And so that’s why fundamentally platform teams end up being very similar to what a lot of people call product teams, but there are some fundamental differences that it’s important to keep in mind.

Enabling teams in Team Topologies have a specific focus which is helping the product teams bridge some capability gaps, whatever that might be. It might be something more technical around whatever, test automation or observability or SRE, or it can be something more around product design or even kind of more business aspects or legal aspects. It can be anything where there’s a need from usually several teams to be helped by an enabling team of experts. So these are two of the fundamental types of teams we talk about in the book.

We made this differentiation because if you understand well, what is your mission? Is it to bridge capability gaps and how should we do that? Or is it to end up providing services that help teams accelerate their work and how should we do that? Now in reality, what tends to happen often, a pattern we’ve seen is that you combine this into … the same team might be doing platform work and enabling work, and that’s okay as long as this is very clear for the team itself and for the people outside the team for their customers. What you don’t want to do is say you have a team that is doing some enabling work trying to … maybe they’re pairing with another team explaining how you automate some tests or how you do certain things?

They don’t really have the experience, and then that person gets called because there’s a problem in the platform and they have to leave, for example. That’s the kind of thing you don’t want to happen because that breaks the trust from that other team that was being helped or being enabled.

What we also have heard many times since the book came out is that it provides a shared language. And again, the naming is maybe not most important. We could have called avocado’s team instead of platform team, but that from a naming perspective would be weird. But effectively what’s more important is the behaviors and what is the mission of this type of team so that the teams who self-identify as platform team, as we described in the book know, “Okay, we need to be doing this, this and that, and we need to be looking at are we helping the teams actually go faster or we becoming a bottleneck? Then we’re not being a real platform team in the sense of Team Topologies.”

Now, if organizations feel that it’s important to give other names to these teams or Sam Newman who I highly respect and we know each other and we’ve done some presentations together as well, I fully understand where he’s coming from and I think it’s fair. What I would recommend is for any organization to define internally and have a shared language, because especially in large organizations, you see even different parts of organization, what you call a platform team might be behaving a totally different way from what is called also platform team in other parts of the organization. So that’s where Team Topologies, a lot of people have said helped have a shared language and we can reference the ideas in the book, and it’s not so much about, did we get the right name? It’s about whether this helps us understand what kind of work and what kind of behaviors this type of team should have.

Abi: Well, thanks so much for explaining that. I know your book obviously covers this, but I just thought it’s such an important topic to highlight for listeners. I want to sort of recap. You said so many interesting things there. One thing that struck me was that, to summarize, platform is really about internal product, whereas enabling teams are almost more of internal consulting. Is that an okay mental model in your view to think about it that way?

Manuel: Yeah, definitely. If the consultants are doing a good work, then yes, internal consulting would be a good way to describe it. For me, obviously in this fundamental aspect of enabling teams is that they shouldn’t become a dependency. So the, let’s say between quotes here, if you can’t see the video right now, is that if the enabling team is becoming a dependency, where do you say, well, now this product team cannot never do X, Y, Z without asking for help from the enabling team. That’s an antipattern in terms of fast flow. It means you’re not actually capacitating this team to do those things by themselves. You just introduce the blocking dependency with this other team internally.

And well, some consultancies, that’s their business model where you put people in your organization and then the organization becomes dependent on them. That’s not what we’re talking about. So if it’s consulting in that sense that we come to help you learn and to help you capacitate you to do things more autonomously, then yeah, totally makes sense.

Just a note, I think, again, it’s a matter of terminology, and I’m not a native English speaker, but enablement is a noun. So I think it’s something that we try to achieve, and the way that we achieve it is maybe with enabling teams and platform teams. That’s kind of how I see it in my mental model, the way I look at the terminology. But of course you can use, and we see a lot of organizations that call enablement teams, and that’s okay as well. Again, what does the enablement team do? How do you know if they’re helping or if they’re becoming a bottleneck or a blocker to other teams? That’s the key thing to consider.

Abi: You mentioned earlier that you see a lot of examples where a team is both a platform team and enabling team and to move out of labels, we just mean they sort of take upon them the responsibilities and characteristics of both of those types of teams. I see a lot of examples of that too. For example, a lot of developer experience teams I meet with, talk about wanting to promote best practices and guide and coach teams at the same time as they’re building internal infrastructure shared services.

I see a lot of these leaders getting a little bit stuck on the first part, the enabling part. The consulting part, if you will. So I want to ask you, I mean, first of all, does it actually work well in your view to do both? And then what are some examples you’ve seen where this is actually being done in practice?

Manuel: That’s super interesting and there are multiple aspects here. We actually, interestingly, we’ve been working on a new video-based training for our academy, which is about effective enabling teams where we talk a lot about some patterns, antipatterns. So one key thing that we’ve observed in organizations is that creating enabling teams is hard because typically leadership doesn’t necessarily see what is going to be the value of this enabling team? Because we can see the cost. We have these experts which tend to be costly working with other teams and we can sense that’s good, but we can’t measure it directly. So that’s one key problem.

To address that, it can actually, and that’s what I recommend to clients is, okay, start small. You don’t need to go ahead and create 2, 3, 5 enabling teams. Just, you probably already have the expertise. So if you have, maybe it can be a platform team that has expertise around SRE for example, and that’s something that product teams need help with.

But it could also be that you have maybe a team of let’s say UX experts. And that’s again, something that is a bottleneck today because this centralized team does all the UX-ing, if that’s a word. And we want the product teams to have more skills around that, then why don’t you ask those teams to start dedicating a bit of time, whatever that might be, 20%, 30% or less of their time, let’s just do some enabling work. Just actually get started and see on the ground, what is this providing? Is this helping or not? What are the things we’re discovering that well actually … and that’s where you get a lot of new insights that you’d never even realize that, well, team A and team B actually already know about that, or they don’t know about this other thing that we thought everyone knew about because that’s also something we talk about in the book.

You never have two teams that are exactly the same. Every team is different. They have different experience, different backgrounds inside and outside of the organization. So you need to meet those teams where they are. And so without doing that, enabling work is going to be difficult. This is some sort of pattern to get started with enabling work, which tends to be hard for organizations to buy into more fully until they see some value. So having teams doing a bit of enabling work, of course you need to have some control that it doesn’t go suddenly, like you were saying, you’re spending all your time doing enabling work and you don’t have time for the other stuff that you had in your roadmap. So you have to be careful and you have to say no to other teams when they’re asking too many things, which is a good sign. Means you’re helping them, but you need to be careful.

And then show the value, show that, well, we were able to help this other team and now they can do, let’s say they are able to manage their error budgets by themselves if we’re talking about SRE for example. Now they understand that they’re able to manage that and we don’t have to be telling them, “Well, stop developing new features because your reliability is suffering.” And so you’ll start seeing the value. And then you might have a better case to, okay, maybe we should have … maybe it’s just a couple of people who are SRE enabling team because we know there there’s enough need in the organization across our product teams or streamline teams that we know we need this enabling team around SRE is going to have work for a while.

And one example that works quite well is from a company, well, one example where they apply this idea quite well, I think is from a company called Uswitch in the UK. So they provide services to compare and switch between internet providers, mobile providers, et cetera. And so they introduced a very small SRE team, enabling team that does exactly this. They are on the ground with the product teams helping them learn this stuff, helping them adopt the right tools to help them, et cetera. And they are at the same time sensors, they’re bringing what they see on the ground to the platform teams that provide services around SRE.

And so that’s a quite nice model where, and I do believe, if you can, it’s better to separate the two teams because especially for platform teams, you already have so much on your plate between developing, between operating your services, understanding your customers, doing product management inside the platform, asking them to do enabling work is yet another thing. They might be able to do it, but if you can have a separation between here’s a small team doing enabling work and here’s the platform team and have the flexibility for these things to change over time, where you might have people who are doing enabling work who are in the enabling team, now they want to come to the platform team or vice versa. That’s a good approach that has fluidity between these teams as well in terms of their composition.

But that’s again a sort of antipattern we see where teams have to be fixed and it’s very difficult for people to move between teams. And so then it becomes more of a need to try to do the org design upfront and assume we get the right model. And that’s usually a bigger antipattern that we see.

Abi: Well, I really appreciate the advice earlier around starting small and demonstrating the value gradually. That’s something we want to talk about later in this conversation around just how to get buy-in for platform teams and enabling teams in general. I want to stay on the topic of enabling teams for a little bit longer because as I mentioned, I think it’s an area where so many leaders I talk to get a little bit stuck. So I want to ask you, what are the ways of actually delivering the enabling work within an organization?

So let’s say you’re a person or a team that sees this opportunity for helping other teams, let’s say improve code review processes, just as an example, what do you actually do? I mean, do you create content and just educate people through guides? Do you conduct and advertise live workshops? Do you just go plug yourself into teams and show up, knock on their door and say, “Hey, can I help your team?” How do you actually build the practice of an enabling team?

Manuel: Yeah, I think all the above, all the things you mentioned can help, and that’s part of the work of the enabling team is figure out what are the more effective ways to help these teams. And you might even have the case where for different teams and you’re trying to help them in with the same things, you might take different approaches where one team actually prefers to get, let’s imagine they want to have a bit more classical training or a workshop, and then they’ll do it, they’ll try it out by themselves, and then you come back and help them kind of course correct. And maybe you have other teams where they just want to get started, let’s start doing this in practice and we’ll figure it out, and then maybe you do more of a pairing or even mobbing between enabling some people from the enabling team and the actual product team.

Creating content, in a way you can see an enabling team is almost like a curator, right? So this idea of a curator is quite used in arts and where you have essentially someone or a team because they have more experience, they’re able to bring the knowledge in a much more consumable way to the other teams. And so that can even be just curating some content, which is I think a misconception in general in IT is assuming, oh, people just learn by themselves and teams can just pick up new technologies and tools, and yes they can, but it has a cost that is often not really visible and teams have to take a lot of shortcuts. So then the end result is not as great.

That’s partially where the value of an enabling team might be, in that curation of helping the teams go adopt some new approaches or adopt some new practices very quickly and with the right direction, the right guidance. But yeah, the way that enabling teams can do that is anything that helps the other teams learn, improve, bridge the gaps that they have without creating a dependency.

The other quite important aspect of doing enabling work is, like I said earlier, you have to meet the teams that you’re helping where they are today. You have to first understand that. And secondly, think about what is the smallest step that they can take, that we as enabling team can help them achieve? Because that’s another problem that I see is that okay, we’re trying to teach everything we know in two weeks or even two months. And that’s how people learn in general. You need to take small steps. And so we talk about in the book about the enabling team sort of orbiting around the product teams, meaning if you’ve never done test automation, we’re going to help you. Or if you’ve never done code reviews that you mentioned, we’re going to help you understand what makes a good code review, what are the antipatterns, antipatterns in a code review.

And then we’ll come back maybe in a couple months and see how you’re doing, what help do you need next? Maybe you need help figuring out … now you’ve done some code reviews, you understand better how helpful they might be. Now maybe you need some helpful tools maybe to help you do some things more effectively, some aspects of the code review, et cetera. So just this idea of helping those teams learn in a kind of step by step way, not trying to push all that we know and all that we can help them with, yes, but it has to be in a consumable way. So that’s also an important aspect.

And then there are some factors that might influence also how you provide this knowledge. In the book we talked about an example where if you have an enabling team that’s mostly composed of external consultants that you brought in because they have some expertise, in this case was around continuous delivery, testing, deployment, pipelines, et cetera, then probably you want that enabling team to create, not just that they’re helping now, but also they create content that can be consumed and they create some useful guidance and so on.

If you have an internal enabling team, then maybe you don’t need to focus as much on creating that content. You need to be more pairing and mobbing and so on. But it’s of course ends up being a balance of different activities that we need to do.

Abi: Yeah, I really love the analogy or concept of curation and the art analogy you shared. That’s something I’ve definitely seen some enabling team leaders start to do that I personally know and work with. There’s been, for example, projects where they try to curate a ton of different content and guides around a ton of different topics around developer productivity or developer experience and serve that to the rest of the organization, at least as a starting point for helping those teams adopt better practices or think about ways to improve. So thanks for your perspective on it, and I think that’s a recommendation I’ll continue to make to others as well.

Manuel: Again, on that point, you end up with this kind of let’s say joint work or work between enabling and platform because some of that content might be, let’s say it’s part of the platform because it helps people onboard, helps people understand how do I use this monitoring service, for example. And other times it doesn’t end up in the platform, it’s just some content and guidance that the enabling team provides to the teams they work with.

Abi: Yeah, absolutely. I’ve seen that example as well. Shifting topics a little bit, we’ve talked about the differences between enabling teams and platform teams. It’s my observation that there are definitely a good amount of enabling teams, so whatever they’re called, but they primarily are enabling teams and they’re long-lived. And in the book, one thing that stuck out to me was that you guys talked about how enabling teams should be short-lived, that they should only last for as long as they’re really needed. So I’m curious, do you see long-lived enabling teams as an antipattern? Do you see examples of that and how should organizations try to break out of that?

Manuel: Yeah, I would say yes and no. It’s an interesting question. Also, our thinking has evolved in the last three years since we published the book. Again, it’s something we’ve covered in this new video course about effective enabling teams, and there’s a really good case study that we’re going to publish and will become available to everyone. In this case study, because I think it’s easier to explain if we look at an example in this case, what this organization was doing was adopting data science and machine learning, et cetera. This is an online retail company. And so their journey started quite a while back, I think almost 10 years ago. And what was initially, okay, we’re hiring some people who know about data science and they create models and they help other teams integrate models in their applications, et cetera.

And then over time, because more and more teams needed help with data science, this model was not working anymore because this central team was a total bottleneck or became a bottleneck. And so they couldn’t keep up with the pace of demand. And so without actually calling them enabling teams, the book wasn’t out yet at that time even, they started having a few teams in a sort of centralized department, but part of what they were doing was helping grow this capability around data science for all the teams.

For example, something they would do, which is very much what we would expect from an enabling team, is to understand what our do teams need, what are the problems they have? Around data science in this case. And so besides talking to teams, but this is a medium size organization, they also had for example, a chat channel where people could just talk about their issues they’re facing. And so they were basically identifying different problems across the organization in terms of their data science capabilities and then trying to help, whether that was with short-lived enabling teams where they could kick off a team to say, “Okay, we’ve identified there’s a common problem, understanding, whatever. Some technology that we need that teams are trying to use. We have a short-lived enabling team that goes and helps those teams. And maybe we expect that to last maybe three months or up to six months,” something like that.

We have an expectation of when this short-lived enabling team won’t be needed anymore. And so those people might end up going to another short-lived enabling team. Sometimes people might end up moving to the product team because the team maybe have a higher demand for data science. They actually need an expert inside the team. And so what was happening, and of course this looking in hindsight is that some people who were more kind of the data leads were acting as a long-lived enabling team effectively. And their goal was more to identify the gaps across the organization, help grow the data science capability across the organization. And so they were not as much on the day-to-day helping address specific gaps of teams. They were kind of looking at the organization level.

That’s why I think you end up, for certain capabilities at least, needing combination of long-lived that now we started calling sometimes structural enabling teams that have a more strategic view on what do we need to do about this capability to grow across the organization versus the short-lived enabling teams that are typically tackling a more specific problem that maybe multiple teams have that we might need for a period of time, but we don’t expect that this team needs to live forever basically or for a long time.

When you look at it, at the end of the day, it is about understanding do these teams have a purpose that is valuable for the organization? And if in that example that structural data science enabling team had a continuous purpose, maybe one day they will say, "Well, now we have generative AI, we don’t even need this anymore.

Who knows? But it’s sort of for that organization, this made sense that this ongoing team that was looking at more structural and strategic aspects of growing the capability together with the short-lived enabling teams. So yes, in the book we started saying they should be short-lived because that also helps with the focus on this shouldn’t become a dependency or a blocking dependency that teams say, “Oh, can you come help us because we need to have a new data science model?” Or, “Can you help us because we’re not able to extract or compose the right data,” or whatever. The enabling team is there to help those teams gain the skills and gain the capability that they’re lacking, not to help them with a specific, let’s say, execution problem without helping them learn.

Abi: Yeah. Well I really love that last point. The clarification and the importance of that enabling work is to help the internal customer gain the capability not to do the work for them, not to be the outsource staff augmentation arm of a product team. And also love the approach you shared before that around this combination of having the long-lived strategic portion of thinking about, okay, what are the right types of enabling work that we should be doing combined with the short-lived more tactical teams that are delivering that capability to other teams. So I really like those concepts.

I want to go back a little bit full circle to the Sam Newman article because another I think takeaway from that article is that he’s been critical of the over obsession or the fad, if you will, of building platforms. And I think we would probably both agree that there is a bit of a fad around this right now. What’s your take on this problem and what’s your advice to leaders to avoid the trap of just thinking of platform teams as developer platform builders and forgetting about the rest?

Manuel: Yeah, that’s a good question and I don’t have an ideal answer, but I think multiple things. One is I think platform engineering in a way that I think gets kind of the movement or the approach that has been gaining a lot of traction that also got a lot of resistance when there was the meme about DevOps is that or something like that. I think it’s helpful that we gain more visibility on that we need platforms, we need platform engineering.

But there are some dangers I think, and that’s I believe what Sam is also referring to, which is to over focus on the technology and platform for the sake of a platform. And in Team Topologies we clearly say that platform teams have a specific goal, which is to reduce cognitive load of the product teams, which means in other words, to help accelerate them, help them do the work that they need to do in a way that is more efficient, faster without having to know a lot of the details that maybe are not as relevant for a product team.

Product team should be focused on the business and the customers and a lot of the underlying technology details and sometimes the practices if possible should be sort of abstracted so that they don’t have to spend as much of their cognitive capacity on those things.

And again, the Uswitch example I mentioned before, and I should say there’s a case study on our website on TeamTopologies.com/examples, you will find the Uswitch case study because that’s really where they didn’t have a platform and they introduced it because they felt our product teams, which were quite successful until now or for a good while, know our suffering and they don’t have time to focus on what customers need anymore. They’re spending all their time focusing on infrastructure and tooling and et cetera.

So I think platforms are needed and internal developer platforms and all these kind of more infrastructure and technical aspects are needed. But we should always keep in mind what is the value we’re providing to the other teams and to the organization. Cause there’s a very real risk of the platform actually blocking those teams. Because if we put too much inside the platform and we say … and this is something I’ve seen, and it’s an antipattern that goes both ways to the platform teams and product teams. Platform teams become sort of quite attached to their domain. They say, “No, this is part of our domain, this belongs to the infrastructure platform.”

And the product teams also, I think almost as a reaction to that, tend to say, “Oh, we need to use some new service,” for example “From AWS. Oh no, we’re going to wait for the platform team to implement them,” but because that’s not a priority for the platform team, we’re going to stand still and there’s a little bit of blaming that starts happening and that’s not good for anyone. So that’s one of the antipatterns. It’s not realizing the boundaries of the platform need to be more flexible.

I love a quote from Ruth Mallon who wrote the preface for our book as well, where she says architecture is a lot about what’s in and out of the different services and how they move over time. So this idea that it should be more fluid. And so if your platform is responsible for some services and is becoming a blocker to other teams who need to do different stuff, then you need to figure that out. Maybe some teams who are more product teams should be allowed to go off track a little bit because they have specific needs and they’re sort of more pioneers and they’re going to try this stuff out and eventually it might come back to the platform.

Or even you realize that your platform boundaries that you defined in the beginning or earlier were not correct, you were putting too many things in the platform. This tends to happen more for kind of core business functionality type of platforms. Or say we have for example, the services around our shopping cart or we have services around payment in a kind of business services platform and sometimes we put too much in there and so we’re reducing flexibility of product teams.

So yes, those are some antipatterns. And then there’s almost like a whole other world of platforms that we could think about and that we’re starting to see, which are not even technical at all. You can think about design platforms, which many organizations already think about that, I wouldn’t say the majority but many do, where it is a platform. Even if what we provide is self-service artifacts and branding and guidelines, teams can consume that in a self-service way and they have support from a sort of design platform team. So that fits the same pattern. It’s helping accelerate the product teams by providing this helpful artifact even if they’re not running services.

And then we can go to other areas. You can have data platforms, which are also becoming more popular, and we have the great book Data Mesh as well to look into that. But even other platforms, we’re starting to see a small number, but we’re starting to see organizations where the legal team, for example, is looking at themselves as a platform. So they’re trying to help at least for common kind of simpler cases, for example, provide services. Again, might be artifacts or even actual services that teams can use, for example, to sign NDAs or to sign kind of common contracts that you need to sign with partners or what have you.

We’re starting to see also, there’s a really interesting example from a company called Capra Consulting, they’re based in Norway, where they actually tried to apply Team Topologies’ approach to the whole organization. And so leadership starts seeing themselves as a sort of platform plus enabling team like we were talking about before. But it’s nothing to do with building technical platforms. They actually provide some artifacts to the teams, for example, Miro boards to help the teams think about their own strategy to help teams realize where the company is trying to go and what’s going to move the needle. And so that they align their own product or their own initiatives as a team to those goals, but they consume that kind of artifact that is created by the leadership team in a sort of platform-ish way, if I can say that.

We even have other examples that we hope will become case studies where you have actually a business group that has multiple companies, and one of the companies acts as a platform to the others, and they provide both technical services as well as HR as a service, legal as a service. And so that’s almost kind of a little bit mind-blowing. There are some traps in there as well in terms of if you have a separate company, how does this company interact with our company? What are the good patterns and how to avoid problems with lack of trust between different companies, lack of communication.

But it’s an interesting model, and so there’s, I think so much potential to look at platforms beyond just the current focus I would say or fad according to Sam, in terms of the focus on technical platforms alone. There’s so much more where if we adopt this idea of how can we make this easy for others to consume and to do a lot of stuff by themselves in a self-service way versus depending on us as the experts on any area, legal, marketing, HR, not just technical areas.

Abi: Yeah. This last description example around the broader ways in which the platform teams can be applied to all kinds of domains is really interesting. And the last thing you said around self-service, again brings me back to that concept of productization is at the core of what platform teams are focused on.

One thing you said that was really interesting was that the north star for a platform team is to reduce cognitive load for others. As you were saying that, a thought popped into my head, what if the biggest factor causing cognitive load isn’t self-service infrastructure? Which is what, as we know, a lot of organizations are focused on. So I’m going to hold that thought though for a moment and kind of bridge into something else.

Recently on this show I had Mike Fisher, former CTO of Etsy, and Jean-Michel Lemieux, former CTO of Atlassian, and both of them talked about failures to get platform teams off the ground and ultimately leaning towards the preference of having this type of work, reducing cognitive load work, not fanned out to dedicated teams, but rather owned by the product teams themselves.

I want to ask you, first of all, do you think in general people are creating too many platform teams? In the same way that microservices was sort of a fad. People created them and then later realized, oh, maybe we went a little overkill. Do you sense that the same thing is happening with platform teams or not?

Manuel: That’s a good question. And by the way, I saw a bit of the podcast with Mike Fisher. I thought there were some great points there. I think it’s possible that some organizations are creating too many platform teams. In fact, just recently I did a short engagement with a really large fashion retailer, and that was exactly what they were trying to do. So they wanted a bit of review of their approach, and they had already all these platform teams and we’re going to create all these services and we’re like, “Wait a second, how do you avoid that they go into a hole where we’re building all this stuff and then we come out of the hole and actually no one really wants to use that or they don’t feel like it’s helpful?”

And so that was our recommendation. It was like start by doing enabling work, which ties into what we were saying before. That enabling work is going to, first, provide value to the teams because you’re on the ground with them. It’s going to provide value to them, improve their skills, even if it’s just improving awareness around things like security, improving your awareness around observability and other things that they want to improve as an organization.

But just start with that groundwork with the teams and it’s going to build trust actually, which is often underestimated how important that is in an organization, trust between what will be possibly platform teams and the product teams before you even build any technology, before you build any service, get people to know each other and to trust. It’s totally different when you have, there’s some platform team in the organization and sometimes you hear about some new service or you’re told you have to adopt some new service and you have no direct connection, no link to those people on that team versus, “Oh yeah, that’s the team where Mike works and yeah, I remember he helped us figure out this stuff a couple months ago.”

It’s totally different and very underestimated. And so I think possibly part of those kind of failed attempts to create platform teams also has to do with this, this social aspects that we don’t effectively take the time to consider and to focus on. And so in that case of that client, that’s basically what we recommend. Yes, you can get to platform teams and we can see, like you’re seeing how helpful this could be, but it could also, you could have the right services, you could have the right tools, which by itself is difficult if you don’t communicate a lot with your customers. But let’s assume you exactly what they need and you build that and you still might not get the adoption that you should be looking at.

So do some enabling work that’s going to bring a lot of benefits and especially that’s going to allow you to understand your actual customer needs much better. And time and time again, I haven’t seen a case where organization and teams started doing enabling work that didn’t come up with new insights that they never thought about, “Oh, I never thought about that, that team does this and that, or they have this need or that they already do some really cool stuff and I never knew about it, even if I’m the expert in that domain.”

And then build platforms slowly, but that’s partially a leadership problem where we want results immediately and we want to whatever, improve lead time by X percent in six months. Well, you need to discover a lot of this stuff. And so like with agile, you need to be learning and doing stuff and learn, and then you’ll at some point be able to have better kind of metrics and you will see the results and you’ll be able to measure that more precisely. But you cannot want and assume you can do that from the beginning.

So that’s in my experience, where I see a lot of problems with platform teams is just, okay, we’ve created the teams and now they’re going to go off and build all this cool stuff. And the intention is good. No one’s trying to do the wrong thing, but the approach is not conducive to be that bidirectional understanding and trust. That’s where, in my opinion, things often go wrong. And that’s where people start say, “Oh, platform teams don’t work,” and, “It was with cost sync where we spent all this money on these teams and now we don’t see the value for the product teams,” et cetera. And so that’s one aspect.

I think the other aspect that you were talking about, and especially what Mike Fisher said that I agree to me is more about the boundaries of platform, as I was saying before. Sometimes the product teams need to … this model of a platform that provides services doesn’t always work when there are things that actually need a product team to do the discovery. And so I don’t have a better advice than just be open to discuss what are the boundaries and be open to say, “Well, this is discovery work that the product team needs to do.”

Eventually we might realize it makes sense in the platform, but sometimes we need to take a step back and say, “Well, we thought this was more straightforward and part of our platform service, but actually should be in the streamline teams hands.” And often what happens, well-related to that is just this idea that we must avoid duplication at all costs, but sometimes duplicating to some extent, maybe some functionality that two or three teams are implementing product teams, which is sort of similar, but turns out they actually have different needs because they have different markets or user personas they’re targeting.

Or when you have a good product development approach, it might make sense that something that seemed the same is actually at least for a while should evolve separately with some degree of duplication. And we accept that because we want to go faster in the discovery for each of these teams. And at some point we can always reconcile and say, we know enough by now to realize what is common and could go in the platform. And that’s going to help reduce a bit of the cognitive load of these multiple teams. But there’s often premature decisions about what should be in the platform and not enough flexibility to evolve the boundaries of platform, which that’s how I interpret what Mike Fisher said as well to some extent.

Abi: Yeah. Well, I really appreciate your interpretation of that, and I loved your advice for maybe starting with enabling work before platform work. And to go back to that analogy from earlier in the show of thinking of enabling work as services and platform work as product, it made me think of software as a service companies. I’ve started a few software as a service companies and a lot of them made a lot of sense to start off by providing a service and then eventually learning enough about the needs and customers to turn it into a product. And it sounds very similar to the advice you shared, so.

Manuel: I think so. And I’ve seen examples where even it ends up that they realize the business model is not on creating a product, it’s providing this service or this consulting in a way that is new or is different from others, and that’s what actually helps the customers. That’s of course a different business model from SaaS, but I’ve seen examples where they actually realized the value that we can provide to customers is around the enabling sort of aspects and the consulting and helping customers learn about this stuff versus the actual product.

You touched on the topic of measurement. You half jokingly mentioned executives wanting to have leap time in six months. We talked earlier about how the north star of platform work is to reduce cognitive load. So what have you seen as far, like how do you measure cognitive load? What are good and bad ways you’ve seen of measuring or proxying that?

Manuel:

Yeah, that’s a great question. So many organizations don’t measure cognitive load. I’m happy that the term cognitive load has been adopted quite widely because I think that’s something we need to talk about at least. But then organizations don’t actually try to assess cognitive load. And to be frank, it’s not easy. And as a side note, that’s actually part of the work we’ve been doing is around helping organizations measure team cognitive load.

So there will be, I can give the sneak preview or the news that there will be a team cognitive load assessment tool that we’re working on to help organizations. But I’ve seen examples where they actually, when they talk to the teams and they use some simple surveys, which is something any organization can do, asking some questions from the teams, try to see where are the areas that are causing more pain to teams that we might look at it and say, “Actually they shouldn’t be focusing on it,” or, “This shouldn’t be as painful as it is today.”

And there was one example where in this, it’s someone I know called Alex Morgadas, and he was working at the company and they were doing this assessment, they realized actually the platform was focused on things that, while they were helpful, were not where the pain was for the product teams. And so just doing that sort of simple assessment allowed them to understand that actually we need to shift, at least for now, into other areas that the platform can help with.

But yeah, it’s not straightforward to measure team cognitive load. What should be visible is when you actually have the platforms and you have the enabling teams that you need doing the work with the customers, with the other teams in mind. Those teams should see improvements in, for example, if you look at the DORA metrics, if you reduce cognitive load of the team, it should be able to improve lead time, improve the reliability of our service as well, improve the quality or reduce failures because we now have more capacity to focus on our service, to focus on our product, to focus on our business, our customers, et cetera. Because a lot of stuff that was consuming our capacity has been provided by platform.

That is sort of the ideal way. But as you said, it’s not a clear cut kind of way to measure the value of platform or enabling teams. And that’s where many organizations struggle. And to be frank, especially for enabling teams, there is a bit of a leap of faith you have to do.

Abi: You’ve mentioned that you’re working on a new talk now about the future of platform engineering and why platform engineering needs to be more than just about internal developer platforms. Can you share more about what your thinking is around this and how it’s evolving?

Manuel: Sure. As I said earlier, I think there’s a lot of potential beyond what your current focus is on platform engineering and more technical platforms. And we start to see some examples where I think, I like to think about what is platform engineering, 10 years from now? I mentioned some examples where we’re thinking about applying this platform thinking to other areas, and we might have leadership as a platform. We might have company as a platform, and we might have HR or legal as a platform.

So I think it’s quite interesting. The naming, who knows? Maybe we’ll call it something else, but it’s to move away from the platform term. But if we have more of a shared understanding of platform as this, how do we provide something to others that they can consume easily, that can help them do their work more effectively without depending on us to do the work for them. I think that that’s a good goal and can be applicable much more broadly than just developer platforms.

I hope in the coming years we’ll see an expansion of this idea of both platform as well as enabling work. And figuring out that we have a lot of internal customers in organizations, so if we treat them more as customers. That can be actually quite helpful for the organization itself. For efficiency, but also for people. I think no one likes to be blocked and to have dependencies that they don’t control and that are impacting their work and they’re not able to do things in a more effective way.

So it’s exciting to think about that, and maybe we’ll do this podcast again in 10 years and see where we are.

Abi: Hopefully sooner than 10 years. And on that note, I want to say I’m so excited to follow all the upcoming work you’ve mentioned on the show today. And I’m so grateful to you for coming on the show, I think this will be really valuable to our listeners. Really enjoyed it myself. Thanks so much for your time today.

Manuel: Thank you so much. It was a pleasure.

‍