This episode is hosted by Boundaryless Conversation Podcast host Simone Cicero with co-host Emanuele Quintarelli.

The following is a semi-automatically generated transcript that has not been thoroughly revised by the podcast host or by the guest. Please check with us before using any quotations from this transcript. Thank you.

Simone Cicero:
Hello, everyone. It’s Simone here. We are back at the Boundaryless Conversations Podcast. Today, I’m here with not-so-usual co-host, but somebody that you already met on the podcast, Emmanuele Quintarelli. Hello, Emmanuele.

Emanuele Quintarelli:
Hello, everybody. Happy to be here.

Simone Cicero:
Emmanuele will be co-hosting with me today with Matthew Skelton. Is it the right way to say that, Matthew?

Matthew Skelton:
Exactly right. Hi, everyone, good to be here.

Simone Cicero:
And Matthew is half of the Team Topologies team, right. And I think it will be great just to have a quick overview of your approach, more than Team Topologies, in general. I mean, a couple of highlights that can help us to maybe frame why the work that you are doing with Team Topologies framework is essential for our listeners. Some of these, you can just give us a quick overview of where you are in this adventure will be great so that we can move on into more advanced thinking about that.

Matthew Skelton:
So, Team Topologies book was published in September 2019 by IT Revolution. IT Revolution is a great publisher of books like Project to Product and DevOps Handbook, and Accelerate, and basically a whole family of books which all worked really, really well together. And we’ve been really, really pleased with the success of the book. We think, at the last count, we’ve sold something like 33,000 copies in the last year and a half, which is very, very good. But we’d be more pleased with the comments from people using the ideas to help them make the organizations more effective at building and running software systems. And that’s the real test for us is that people actually find it useful. People are going ahead and using the ideas and making positive changes in their organization. The subtitle of the book is Organizing Business and Technology Teams for Fast Flow.

So, the Team Topologies patterns are really all about a need for a fast flow of change when we’re building software systems. We do know that some organizations are starting to use the patterns outside of a software context and that is great. That’s maybe something we could chat about later on today. But our starting point was organization building software systems. That’s partly because that is the experience that Manuel, my co-author and I have working from a software context. But also because increasingly many organizations are not necessarily software organizations. But software becomes a really important part of how they maintain a distinctive voice in the market. And so being good at delivering and running software becomes a really important aspect of how successful that business or that organization can be. So, that’s sort of our starting point.

Looking for a fast flow of change, that’s partly because of technology is moving very quickly, the market’s moving very quickly, the kind of business relationships between different parts of the world are changing very rapidly. Organizations need to be able to adapt or need to adapt at speed. And that was a key kind of starting point for us. But we also wanted to make sure that we addressed many other things that relate to software development, in particular, and also make it kind of still human centric. In particular, the emphasis we place on team cognitive load as a kind of architectural and fundamental driver for decisions when building software is something that has really helped lots of organizations so far since the publication. So, you can sort of see it as a kind of, sort of humanistic approach to software development, but at the same time, takes into account some of the very real drivers, and constraints that software exhibits of when we’re building this at scale, with a view to being kind of nimble, and making sure that we’re building software in a way which is responsive, listens to signals inside the organization and outside the organization.

Simone Cicero:
Great quick introduction and brought me to a couple of questions that resonate with the point that you were raising around now seeing organizations using Team Topologies’ elements to think about their organizing beyond software. And especially the two points that came to my mind around essentially the role of software in modern organizations. That seems to be an ever-increasing role, essentially very important for organizations to master software and technologies more generally. But on the other hand, I see two trends that I would like to just have you — kind of your reflections around those. One is the trend pointing out towards faster evolutions of computing, moving to the cloud, and all these conversations that we are having around serverless and essentially, companies are increasingly relying on third party infrastructures to run their code.

And on the other hand, these large movements that are happening around the area of no code. So, with increasingly complexity of software being encapsulated by players that provide frameworks for organizations to develop their technological enabled — software enabled the products and processes, but with a no code approach, so without having to actually code but actually moving into more visual, more self-manageable, in terms of, for example, a business expert, being able to self-manage her own software developments. So, how are these two trends impacting the role of software inside an organization that seems to be so important in terms of the way that you have been framing your framework so far?

Matthew Skelton:
That’s a great question. So, software, the way it’s used in the organizations that we speak to, that we’re trying to speak to with the book, and with Team Topologies approach in general, is as organizations for whom software is kind of encoding a set of business processes, or is software as a way of providing a digital product, which significantly exceeds the capabilities you’d be able to do if you didn’t use a digital approach. So, in other words, the approach speaks to lots of different organizations, and it doesn’t assume that we’re using any particular languages. It assumes that we’ve got a flow of what we call software. And the reason we want to keep that kind of flow of software inside our organization is because that’s a business differentiator. We should be writing, defining software only in those areas, really, that are a strong business differentiator. Perhaps we might define software in areas which is kind of supporting of that core goal.

But certainly, if you use some of the ideas from the domain-driven design community, DDD, and if you combine that with techniques like Wardley mapping, it’s pretty clear that organizations that are still building their own input software infrastructure, or kind of networking infrastructure, computer infrastructure themselves, organizations are still doing that now, generally speaking, are sort of wasting time. Because all that stuff is now provided kind of as a service. Why is that a differentiator for your organization, if your organization is in banking, or retail or health care or something, it is not something that’s differentiating your business. So, you should be focusing on a higher order, on a higher level of innovation. Now, if you can do some of that innovation using what’s called a low code or no code platform, then that makes sense, up to a point. Because if that enables you to go quicker, and meet user needs in a shorter timeframe, in a way, which is more straightforward, that’s all great.

However, there’s a caveat here. I certainly have seen this kind of trend once before, at least in my life, people who are older than me have seen it at least twice before, which is that the promise of code free or low code, visual design of software systems is very alluring, is very appealing to lots of people, and has failed at least twice before in the industry. It’s failed, in the sense that the systems that — the kind of systems you can build with no code or low code start off looking quite appealing, they look quite nice. It’s like, hey, we managed to build this prototype or this fairly simple thing. The challenge is that any software is simple to build if it’s kind of small, and filling a very small niche. The challenges arise at managing software at scale. So, when you try and scale out that visually coded thing, and it becomes unmanageable, and it becomes very difficult to understand what’s happening, there’s very little observability in that low code or no code platform. Then that’s where that kind of approach will become a problem and has become a problem in the past.

So, the generation that I saw was around VB, Visual Basic, and the kind of mess that organizations got themselves into by plugging together horrendous spaghetti systems based on Visual Basic, and people having very little idea about how software really needs to work. And there were previous incarnations prior to that, in the, I think 70s and 80s. And so there’s a danger that some organizations will not really realize that software is software and still needs observability, it still is good architecture, good design. It needs good diagnosability, we need to understand how this stuff’s actually working at scale. Otherwise, the business processes will fall apart. And guess what, then we’ll need people to come in and fix it and write some proper software. So, I don’t think that the current — I think there’s somebody really amazing solutions, particularly as the — this particular generation of low code and no code stuff, a lot of it is API driven. So, using an application programming interface as the kind of starting point, which is great, because it means it’s not tied to any particular visual design.

But the idea that non-engineers or non — people with very few technical skills can design maintainable, large scale software systems is, I think, a mistake. So, whichever kind of abstraction you’re using, whether you’re using an abstraction that’s like kind of at the Java or Ruby or Node level, or whether you’re using something that’s more no code, or low code, where you can drop down into code for certain things; the important thing is to make sure that these systems are tracked properly. We understand how the specification for that system has changed. When I say specifications, I am including source code. But if your specification is in a set of configuration files in a no code system, that’s also fine. That stuff needs to be in version control, you need to be able to track the changes. You need to make sure you understand how that stuff actually works, how it’s actually running in the production, in the live systems. And when there’s a problem, you need to have enough observability in there to help you to fix it.

So, the principles in Team Topologies apply to whichever kind of, if you like, specification language you’re using. Whether you’re using assembly language, low level C, Java, .NET, Node, whatever you’re using, all the way up to low code systems is still a specification language. We understand the rules of software in terms of loose coupling, high cohesion, making sure we’re tracking changes in version control, making sure we understand we’ve got enough kind of test points or observability points into the running system, so we can actually have a chance of diagnosing something when it goes wrong. All of these things are now pretty well understood in terms of how to build and run software systems at scale. All of these things still apply to the — from a Team Topologies’ perspective. It’s just that you’re moving further up the stack. You’re taking more and more abstraction, or you’re moving to a more and more abstracted view of the kind of problem space, if you like. So, instead of having to think about still relatively low level business concept encoded into something like Java or Node, you’re thinking at a slightly higher level, but you’re still plugging — effectively, it’s still a software system.

It’s just that you’re not having to write everything from scratch. But that’s exactly the same principles that we would expect to use looking backwards at previous generations of code. No one would be writing all of their systems in assembly language these days. That would be not very sensible. But generations back, assembly language was the future after people have been programming machine code for a decade. So, you just got to be a little bit mindful that the — each abstraction on top of the previous generation, it looks like lower code than before. And that’s kind of the right way, that’s exactly how it should be. We’re evolving towards higher levels of — value, moving up the value chain using high levels of abstraction. But you cannot just throw away all of the — there’s a danger that you also throw away the key principles that make software systems actually work. Need this focus on kind of operability and ability to see what’s changed through version control, and that kind of thing.

So, all of these kind of approaches, they’re all great if you do them in the right context, if you make sure that you’ve got the configuration of the change tracking via version control, if you’ve got the observability and awareness of how these things are actually going to operate, what happens when your no code provider goes down? How is our business process going to run? Do you just wait for that provider to come back or do you have an alternative? How do you manage that failover from one provider to another? These are all the same kind of software operational discussions we’ve been having forever — for decades. It’s just that now the specific details have changed. So, in short, all of the stuff in Team Topologies applies irrespective of which kind of software you’re building and whether you’re building it all in house or whether you’re pulling in from other providers too. If you’re building software at the right level of abstraction for your business and your business is context in the market, then you’ll get value from the Team Topologies’ principles and approaches.

Simone Cicero:
Well, that was a fascinating point. I think, you know, because you kind of make this point that basically you can go for abstractions and move away from assembly towards Java for example. But still, you keep, to some extent, to some level of observability and loose coupling that you start to basically let go as you move into no code frameworks. So, basically, it’s like these low code, no code frameworks a bit like at the edge between how much abstraction you can take before actually becoming so dangerous in terms of risks and potential problems that you don’t anticipate because you cannot observe them. So, to some extent, from what I understand, and this is also a good point as I pass the floor to Emmanuele that has a question around this. But essentially, it looks like there is a relationship between the kind of language you use to describe your business processes, and the size of the organization. Because you also make this reference to — in a large organization also hinting towards the fact that the risk, to some extent, the risk of poor manageability of software kind of compounds as the size grows.

So, from what I understand as a final reflection, essentially, to some extent, the managing software base, a software base is kind of making the case for having a large organization. So, if you’re a small organization, then you can move into low code, no code and even a large organization can have maybe frameworks to have their own business units or units to build solutions on top of a shared framework. But still, if you want to have — to be a large organization that ventures out into the future, there is some certain level of abstraction in how you — the software you use to empower your processes that cannot be sacrificed. So, at some point, you cannot do everything with no code. So, you need to have ownership. It’s like code languages that we have — the most used languages that we have today, to some extent, they have ontological, I don’t know how to say, but essentially, they can have reached a level that you cannot cross. You cannot go more abstract than that, if you really want to manage things, if you really want to understand what is happening in your organization. Is it right? Does it resonate with you?

Matthew Skelton:
I think that’s a good point. Part of the thing here is that if an organization that had entirely pushed all of its business processes out to commodity low code or no code platforms, there’s a real danger that that organization just doesn’t really have any useful intellectual property. That’s the danger. I mean, it’s still possible. But the danger is that that organization, there isn’t anything that’s kind of particularly unique about it. And the danger is that someone else is going to come in and do something, perhaps a bit more bespoke, or something that the local platforms can’t do, and therefore, move into that market niche. That’s what some of these thinking from — like if you look at the core domain chart pattern from DDD, if you search for core domain charts, you’ll find that online.

An interesting way of thinking about it, in other words, the focus of effort into making software with whatever language you’re making it with, should be on the area, which is where the intellectual property lies, the kind of core business mission. And it makes a lot of sense because that’s the place where it’s worth spending your money doing stuff, which is kind of new, and where you are happy to pay trained experts in building software systems because you’ll get the competitive advantage. So, some of this is being kind of honest and realistic about which aspects of your organization are actually kind of important or unique or close to being unique. And then focusing your software development efforts around there, whichever language you’re using — whichever kind of language you’re using. And then ruthlessly expect the parts of what you need to deliver that.

So, if there’s other things you need to deliver that, like cloud infrastructure or billing system or whatever, those things, if they’re not distinctive to your organization, then you shouldn’t be building it. So, those are things you should pull in from the ecosystem from software as a service and so on. But expect a need to do some things custom because that’s kind of — that tells you that you’re operating in a space, which is — where you might have a unique advantage.

Simone Cicero:
It rings a big bell on my side on companies that are not developing software and still think that they have some IP as well, some special IP. So, if you believe that you have some special IP or you’re not coding it into software at the moment, that’s a big red flag for me, from what I read from your words. But anyways, I would like to leave it to Emmanuele to build on that because I think this connects very well with the questions that Emmanuele was thinking about.

Emanuele Quintarelli:
Yeah. I wanted to jump on it by going back to one point you raised at the beginning about software and the interfaces. And you were probably referring to APIs, so programming interfaces. But in the book, you described the connection, the intimate connection between interfaces among software modules and interfaces among teams via Conway’s Law. Could you share a bit more about that? What’s the impact on the organizational design or the connection among the organizational design, and the software and design and how to scale these, not just to the team, but to the entire organization? So, if we want to design better software, what are the constraints, the implication on the team? What are the constraints and implications among teams to the entire organization?

Matthew Skelton:
Sure. That’s a great question. So, Conway’s Law was first sort of defined in a academic paper published in 1968 by a guy called Mel Conway. He had a history of building computer systems. He was in the military at one point and then building it for large corporations. And he observed that there’s a kind of mirroring effect between the shape of communications inside the organization, and the shape of software that gets produced. And this mirroring effect happens at multiple different levels. So, it’s kind of a fractal. The same — if you zoom into the organization, zoom out, you get the same kind of effect — same kind of mirroring effect. Now, this was treated as a bit of a curiosity for actually many decades. But it very recently, sort of since about 2010, there’s been some research done into this potential mirroring effect in lots of different industries. So, software but also jet engine manufacturer, automotive manufacturer cars and trucks, and several other areas as well, where we’ve got kind of multiple suppliers, or multiple different teams, and lots of kind of different sort of interfaces and bits of the system.

And although it’s not a law of software, like we’ve got the law of physics, like gravity or something, but it’s a tendency. Conway’s Law is more like a kind of tendency or force that’s acting. And that’s because really, if you go back and read the 1968 paper by Mel Conway, really, what he’s suggesting is that the shape of the organization communication pathways restricts the kind of solutions that we can find. Effectively, I think it’s in that paper, he talks about constraints, the shape of the organization communication pathways is a constraint on the solution search space. So, the shape of the organization communications kind of constrains the kinds of solutions that we — they were likely to find, which is a massive strategic problem. If our organization is set up in a particular way, with certain kinds of communications in place, or certain kind of communications preferred, then we may just never find certain useful solutions.

And when we’re moving at speed, and when the technology is evolving at speed, like it is now particularly digital kind of cloud technologies, if we’re unable to find certain solutions or if we’re unlikely to find them, then there’s a danger that competitor is going to come along and find that solution before us — before we do. So, this has implications then for organizations that really need to sort of question their current sort of structure and particular communication paths and say in what ways is this constraining our ability to actually find better solutions.

Now, when we’re trying to optimize for a fast flow of change, as is the focus of the Team Topologies book, then this strongly implies that we want to have zero handoffs, between teams as they work on something from idea through to be live in the live environment. In the past, you’ve had different silos of teams with different kind of skills, typically, maybe like design and then development and then test and then release and then operate. And those handoffs between the teams, they really kill the flow of change. They really prevent this rapid flow. And so a key starting point is to have cross functional teams, teams with a mix of skills in them that can take an idea, that can take, yeah, an idea from kind of conception or we decide to work on it all the way through to running the idea, building the software and running the idea in the live environment.

So, again, whether we’re talking about using .NET, or Java language, or Node, or whether we’re using low code or no code environments, there’s still a group of people who are working on that problem, testing it, rolling out, making sure it operates well. They’ve got the right mix of skills for that context, for that product or that service or that part of the business domain that they’re responsible for. And they’re responsible for making sure that thing runs as well. We want them to be very close to the running system, whatever that is. They’re getting feedback from customers, they’re getting feedback in terms of telemetry from the live running system that feeds back into their team and tells them, hey, we need to change this or we need to fix this. We need to adapt how this thing is working.

And so that has a strong impact on the shape of some traditional organizations. Because traditionally, organizations were very siloed in terms of functions. You had a kind of design group, you had a development group, you had a test group, and so on. And so that really changes how organizations need to think about kind of managing and reporting lines as well. Often, these kind of cross-functional teams cut right across those traditional hierarchies. But, if we want to fast flow change in order to be able to respond quickly to the market environment, then that’s what we have to do. Otherwise, a competitor will come in and take our place. So, I definitely, at least two reasons, because we want to avoid Conway’s Law, we want to avoid the bad effects of Conway’s Law, rather. We want to make sure that our organization communication is not fighting against the kind of solutions that we want to find.

And also because if we want to fast flow change, we would need to have no handoffs between idea and it be live, then both of those things tend towards the kind of patterns that we talked about in Team Topologies, particularly the central type of team called a stream-aligned team, with end-to-end responsibility for one particular part of the kind of business domain or product or user journey or something like that. And so that can look very different compared to what organizations are familiar with. Some organizations already have something quite similar, which is fine. And some organizations, including some that we’re working with now, they might have that kind of cross-functional team for a small part of that technology landscape or a small part of the user journey or a small part of the product.

But then there’s kind of some upstream delays and other responsibilities, which means that that team doesn’t really have full end-to-end responsibility. So, in some organizations, they would also need to extend that cross-functional ownership backwards through the organization to give them true end-to-end ownership, rather than just over a small part. So, it definitely has some big, I’d say challenges for some organizations that have been optimized for different things in the past. But certainly, those organizations that are adopting a model like this and have been adopting a model like this for a while, I find that they’re able to go very, very quickly, run very, very quickly.

Simone Cicero:
Yeah. I mean, I was talking with Emmanuele in the background and we kind of have a second part of this question that if you look at your team structures, the team structure in your framework, and just also tell us, to our listeners, you talk about four main team types. One is the stream-aligned team that you also already just quickly introduced, then you spoke about the platform team that I tried to recap. But essentially, those are the teams that provide the solutions that are crops, to some extent, to many, many other teams, have this responsibility to build the technologies that serve for many others.

Then you have this complicated subsystem teams that, to me, sound like also a bit — maybe I’m wrong, but essentially, pockets of complexity in the organization related, for example, to legacy systems or things like that, that need to have their own specific managing team. And then you talk about enabling teams that, to my understanding, they are the ones that essentially help to reduce the cognitive load for the others in the organization to integrate new features — new technologies or, for example, new elements of innovation that come from the market. So, these four teams more or less make your universe. And I’m interested, really, to understand a bit more around how do these teams structure — how does this team structure connect with traditional functions of an organization, traditional elements of an organization. And the first and most striking point to hear is sales.

So, essentially market validation, how do you validate these new elements in the market? You know, because for example, how do you define the features? And then you spoke about this idea of having zero hand-offs between teams? And I’m wondering, so how is the stream-aligned team that is developing a certain feature set and so on gets market feedback in your experience, how these connects with additional elements in an organization such as Salesforce? And this conversation, it can be generalized more generally, for example, in other main features of organization that normally are, for example, the HR function or the marketing functions and so on. So, how does this software centric ways of organizing connect with the traditional, I mean, not even so traditional, but with some inner end functions of an organization, and especially, the market validating ones. How does this picture fits together?

Matthew Skelton:
First, I should just put my own words to the four different team types because quite a few people have kind of get the interpretation wrong, because they’re bringing preconceived ideas of existing kind of teams. So, there’s some really important distinctions that we’ve got for the purpose of these different teams. Our starting point is always stream-aligned teams, end-to-end responsibility, no handoffs, very close to the customer, and long term responsible for a particular part of the kind of business domain or service or product or user journey or something. So, they’re able to go very, very quickly because they’ve got a very high degree of business context for what they’re doing. And they’ve got a high degree of trust because we’ve taken the time to build the trust within that small team. When we say team in the Team Topologies’ world, we say, well, this is probably not bigger than about eight or nine people.

In some organizations, it seems like you can get up to about 15 people to have still a high degree of trust. But we’re limited as human beings, anthropologically, we’re limited in the number of people we can really have high trust with. And the high trust is part of what allows us to grow very quickly. So, you cannot keep adding people to a team, a team at the absolute upside seems to be about 15 people. And that’s validated by sports teams around the world. Almost no sport in the world has more than 15 people on the field. And a very good reason for that. And often, the teams that have 15 people have actually two sub teams, if you like or two, or three, or maybe four sub teams inside that team on the field, and that’s where you get the high trust. But our starting point is always stream-aligned team. And if you do not need another kind of team then don’t have another team. What we’re trying to optimize for in those teams is a rapid flow of change.

However, at some point, because there’s a limited number of people, that team will reach a limit, a limit of the kinds of things that it can deal with. So, for example, it might start off building the domain specific software. And it might take on all of the stuff around data and infrastructure and security and so on. And that might be great, because that helps them to go really quickly. But at some point, the amount of stuff they’re dealing with is too high for them to be able to go quickly with the domain specific things. And that’s the important point. That team should have a domain focus, typically speaking. And so at some point, the cognitive load on that team is too high. The extraneous cognitive load specifically is too high. The things they are thinking about which are not related to their main area of focus are too high so it’s slowing them down.

So, what do you do? Well, as you mentioned, you might get some help from an enabling team, which has a team of experts who can help to bridge the capability gap that might help the stream-aligned team to understand how better to use some kind of machine learning or data or infrastructure or technical practices or whatever. And that might give them a bit more capacity in terms of cognitive load, fine. But you still might end up with the same problem three months down the line. So, what other options are there? If there’s a very specific part of the system, which requires a high degree of specialization, that could be suitable for a complicated subsystem team. But the only reason to have a complicated subsystem team is to take away very highly specialized cognitive load from a stream-aligned team. That’s the only situation that we’re talking about that it’s worthwhile doing that. Because the danger is that complicated subsystem team becomes a bottleneck, a blocker.

In a similar way, a platform, what we call a platform in our context, Team Topologies’ context, this is always an internal — Well, most of the time, when we talk about platform, we’re talking about an internal platform. And again, the only reason for us really or the primary reason to have an internal platform is to reduce the cognitive load on stream-aligned teams by taking away some of the non-differentiating details of something like data, machine learning, infrastructure, deployment capabilities, you name it, that kind of stuff, which is not — If those things are not related to the main business domain, then that’s a non-differentiating, so therefore, they’re a candidate for removing from the stream-aligned teams. But a platform could be the right model to use even if you only have a single stream-aligned team. It still might be the right thing to do.

It’s not that — we don’t really — we look at this through a different lens, a platform is not — We don’t create a platform because there are many, many teams that could use a particular service. That’s not the decision criteria we use. Our decision criteria is the platform must reduce the extraneous cognitive load on the stream-aligned teams, and the stream-aligned teams must be able to choose whether or not they use the platform. It’s entirely up to the stream-aligned team. If the stream-aligned team wants to build its own database or wants to build its own machine learning engine, and that helps them go quickly in their domain, then they should be free to do it. It’s very, very important. That kind of retained that sort of perspective. It’s about making sure there’s fast flow and a limit to cognitive load in the stream-aligned teams. So, different decision criteria compared to platforms of the past. And that partly answers the second part of your question, which is how do the stream-aligned teams keep a — or how do they relate to the kind of market sensing aspects of an organization. In a passage in the book, and I think it’s part three of the book that we call a kind of service experienced team.

This came out of some work that I did in the UK Government a few years ago. And you’ve got the idea of a group of people who are thinking about their holistic user experience around a particular service. In that case, it was Citizen Services, but it can also be a consumer product-based thing as well. What’s the holistic experience around that whole — the whole end-to-end service, which might be much longer than just provided by software. Effectively, they’re thinking about the full lifecycle product experience. And part of that, of course, includes market sensing and feedback from customers. And that team is sort of sitting alongside the stream-aligned team pulling in data and insights from other places, market pricing, customer feedback, whatever, and making it available to the — making that available to the stream-aligned team or helping the stream-aligned team to work out how to detect that stuff better, and bring that information in.

Simone Cicero:
Right, right, right. It’s interesting to see how you push all the IP, all the differentiation to the stream-aligned teams. That strongly resonates with our work in the 3EO, so the entrepreneurial ecosystem enabling organization, where essentially demand for enterprises that have the same team structures that you have been mentioning, so eight to nine, maximum of 15, so this idea of the market entrepreneurial unit let’s say, they developed most of the innovations, most of the new value propositions in an entrepreneurial organization. So, we really resonate with that. And I was interested when you said platform teams, instead, they kind of scale the non-differentiating capabilities, if I understand that right. So, the idea is that a platform team runs common services that are not differentiating. Am I right?

Matthew Skelton:
Well, I think that’s what a platform for us ends up being. But the driver for that is always in the context of reducing cognitive load and increasing speed in the stream-aligned teams. That’s what’s driving — what ends up in the platform.

Simone Cicero:
Right. My reflection was a bit more towards this idea of interfaces and opening interfaces to the market. So, as soon as something becomes known differentiating, it makes a lot of sense to me to open this interface in the market so that you can integrate more differentiation. So, which is essentially what happened with, for example, this is the story about Amazon, that basically develops this interface in connections between teams. And suddenly, it doesn’t make much difference anymore, if you have a category manager from inside the Amazon, or a third-party that provides you the products to put into the marketplace. So, to some extent, as long as you platformize certain features of the organization, and you deem them not beating anymore, kind of differentiating element, but more like an enabling, like a sustaining element for more innovations to happen on top of them. It makes a lot of sense to open them to the ecosystem. So, you don’t just constrain the innovation that is going to happen to what’s happening inside the organization. And you start to integrate in Wardley terms, the future from the ecosystem, because the ecosystem becomes your future sensing engine.

So, once you create these platform features, let’s say that, then you kind of push to growing the ecosystem, the leverages on them and to try to centralize and consolidate like a cloud player would do. So, essentially this idea that, for example, our cloud intersections tend to be concentrated, at least in terms of operations. And this makes a lot of sense because it’s not differentiating, and then it’s maybe worth pushing the differentiation into the stream-aligned team. And then you — maybe there is the place where cloud systems make more sense. On the other hand, if you kind of use an external system, then you lose your possibility to capture these new patterns, maybe. So, these are maybe the frictions, the friction between keeping your platform elements inside versus keeping your — just your stream-aligned teams and your kind suits your own platform elements. What do you think about that?

Matthew Skelton:
One thing you should point out here is that, for us, platform is actually more like a grouping rather than a team. And inside a platform and inside of Team Topologies’ platform, we would expect to see primarily stream-aligned teams; it’s a self-similar fractal, kind of the same pattern at multiple zoom levels. That’s what I mean by fractal. And so you’ve got stream-aligned teams focused on things inside a platform. The platform itself is like a product. So, if it’s in let’s say, if it’s a cloud infrastructure platform that we’re building internally, then you might have a team dedicated to logging, you might have a team dedicated to automated infrastructure, a team dedicated to security, whatever, a bunch of things like this. And so you’ve got the same kind of patterns happening at multiple different levels of the organization. And you may have a platform, internal platform that itself relies on another internal platform, one that’s kind of a lower level.

And again, inside that one, you’ll expect to see multiple stream-aligned teams. We’re using the same patterns at multiple different levels of the organization. So, even inside a platform we’ve got end-to-end responsibility for a particular product or product slice, it’s just the type of product is very different compared to outside of the platform. But again, because we’ve got end-to-end responsibility in multiple stream-aligned teams, we’re very close to our customers, our customers and our internal teams. But we’ve modularized the features of the platform if you like, which is important because of the speed of technology change, particularly with cloud providers, we need to expect — if we decide to build an internal capability this year, we need to expect that within, I don’t know, within a year or 18 months or two years, that one of the cloud providers will have built that capability. And that we should be expecting and planning to stop writing more software around that thing ourselves and simply consume it from the outside. At least we should absolutely expect that to be a choice that we need to make explicitly.

So, yes, we might decide to keep it internal because that gives us more — that signals and helps us to innovate more quickly. But also, we should be completely content to — be completely happy to throw away effectively what we’ve been doing for the last two years and consume it from the outside because that lets us go much more quickly on other things. So, it’s absolutely essential that an internal platform and any platform, but an internal platform is run as a kind of product. And as an eco — with an awareness of an ecosystem around it. We’re absolutely expecting to retire things on a quite a rapid timescale, to enable us to make sure we’re always focusing on the stuff which is differentiating. So, we might build stuff in the platform that is differentiating for the platform at that level of zoom, if you like, that zoom level. We would not expect to build a relational database from scratch ourselves inside most organizations. We just consume it from a cloud provider. But we might do something custom around machine learning in 2021, because that’s not really yet commodity in Wardley Maps’ terms. So, it might be — there might be some value in doing that.

But now, look five years in the future, that’s probably a commodity. So, we’d expect to be laying the foundations to enable us to consume something as a commodity in the future. It helps us to think, and that’s why — one of the reasons why we emphasized so much APIs in the Team Topologies book, particularly API is applied to teams, was because getting that thinking in terms of boundaries and APIs and APIs that work for flow is an import — I mean, it’s important for good software, but it’s important for good organizations, because thinking like that helps us to think in terms of being able to swap things out. We’ve got a good API around a particular capability. We’re expecting to be able to swap out that capability that we’ve built ourselves for something that we can plug in later. Yes, it’s not as simple as that usually, but at least if we’ve got some loose-ish coupling inside the organization, then that kind of activity becomes easier to do in the future.

Simone Cicero:
Amazing. So, before I let Emmanuele jump in for the last on some transition related aspects, I would like to just highlight a couple of points for our listeners. Because I think these points that you raised in the last bit really — I mean, really create some exciting conversation around what is inside and what is outside an organization. Because I was listening, for example, to a talk from Shopify extension platform managers, and they were stressing the point that when they created this extension platform strategy, they had to mobilize the internal teams to develop plugins and extensions, essentially, basically using the same infrastructure as the third-parties were using. So, that’s very interesting and points out to an organization that essentially cannot really make a distinction between what’s inside and what’s outside in terms of developing capabilities, you know.

So, I think this is really, really interesting. And it’s a great starter for a conversation around the impacts of software and interfaces with what’s inside and what’s outside and organization, how organizations should look into their ecosystem, much more continuously to their internal teams. So, I think this is really, really interesting. And yeah, Emmanuele, I would like to, as we enter the last part of the conversation, maybe want to explore something related to the conversation.

Emanuele Quintarelli:
Yeah. Matthew, I just wanted to look into that. So, we discussed a number of strategies for teams to better work together and deliver value. But how can traditional organizations move closer to that? Is there any transition path, any best practices, any idea about how to infuse some of this thinking into large, traditional slow organizations? And we have so many of them in the market.

Matthew Skelton:
It’s a real struggle for lots of organizations that have, especially for organizations that have actually improved quite a bit from their original starting point. So, their original starting point might be oh, we did one software release per year. And now they’re doing one every quarter, that’s four times as quick. And they think, wow, we’re really good now. But of course, their competitors are doing 400 releases every day. So, they’re still orders of magnitude away from where they need to be if they want to survive in the long term. But they feel like they made a lot of progress, it can sometimes be a bit of a barrier. So, one approach that quite a few organizations seem to take is to have what they might call a digital division, which is really a strange name to my mind, because it’s all digital, right? All the software we’re building is based on digital computers. But anyway, what it seems to be is the so-called digital channel. In other words, the route to customers or to citizens through digital devices, so a mobile phone or laptop. And those parts of the system are sort of registration, my account, a few things that you can place in order, this kind of stuff. But often those digital, so-called digital systems don’t really touch the real back-end processes.

So, an organization can make some kind of good progress in some areas where the so-called digital part of it, adopting loads of good new practices, using lots of cloud, going really quickly. But they’re always struggling against the fact that the backend systems are extremely slow. It’s like tying like a world-class sprinter to like a cart, like an old wooden cart or something. They’re not going to be able to pull it very quickly. And what I’ve seen is inside lots of these organizations, people who are running the older slower, more comprehensive parts of the estate, are very skeptical of cloud, very skeptical of modern processes, very skeptical of things going quickly. A lot of that is through fear, because they know they don’t have the awareness and skills to work in that space. And they can often put up a lot of resistance to changes that threaten that kind of existing gatekeeping position. Now, they often think that they’re doing the right thing because they’re protecting the data and so on. But ultimately, that’s significantly working against the viability of those kind of organizations.

So, one approach that I’ve seen work, many people have seen work is a kind of very thin end-to-end slice, where we take something that has value, but is quite — kind of constrained or quite small, and map out what it would take to have a kind of full end-to-end responsibility for changes in that area. What would that actually entail? And then — and effectively a prototype and get the principles and practices in place including all of the approvals, all of the kind of compliance, sign off, all that stuff, and start to map out what that — what will be needed to put in place to enable that kind of autonomous flow of change. Or you might even — so in some places, I’ve even started with the thing that we are deploying is a text file, a text file with README instructions that says hello world, this is the first deployment that we’re doing. And it’s just a text file. In other words, it’s not even executable. It cannot do any — it can’t reach any systems because it’s not code. Effectively, it’s just a piece of text.

But what we’re doing is getting all of the kind of approval gates, all of the — or removing the gates, but making sure all the approvals are automated, getting all the kind of authorization to be able to deploy something like a text file, from our prototype stream-aligned team, all the way through into production environment. And validate that we’ve got it there, get all the observability telemetry, login, all that stuff in place as well. But also all of the decision making around the changes to something around that product, or what that product will become. So, that we don’t have a chain of 25 different people deciding — having to sign off on a change. And we’ve changed, maybe looked at how the budgeting works so that we can actually have a — we’ve got a pot of money that enables us to have a steady flow of smaller changes for that particular product area. And use that as a way to again sense and explore what the larger changes will need to be. And get that feedback and characterize the document if you like, the kinds of decisions we had to make and things we had to change in order to set things up like that. And then we take that awareness, and then that can inform the organization, the kind of changes that will need to be made at a larger scale, if the organization wants to become more nimble.

Emanuele Quintarelli:
That’s an interesting reflections and not so easy implications for many organizations. But this is the challenge that and the opportunity that we are facing. So, good with that. Thanks.

Simone Cicero:
A wonderful conversation. I think that really brought us to the — to talk about the real impact of digitalization on companies and organizations. So, it’s really about understanding that diversity technology like that, cloud productivity of software capabilities have really changed the role of organizing. So, for example, I’ve asked you about sales and I asked you how does it work that from stream-aligned teams to get in touch with the market, and you clarified that the stream-aligned team is in touch with the customer. And so I was reflecting with this idea that now when you build software, that you can distribute your software — your products and services so easily to your customers, it’s really — sometimes you don’t really need sales. And when you do need that, sales is pretty much just a growth engine. So, it’s something that you use to get in touch with more customers, to whom you communicate through the software updates that you generate, through the software that you create.

So, I think — I mean, that was an amazing reflection for me and conversation. I’m really thankful for this and for sure, we’re going to work more into integrating the Team Topologies’ elements into our entrepreneurial ecosystem enabling organization. So, Matthew, just as a final point to this conversation, I don’t know if you want to add something that you believe is really important. And for sure, and I would really love if you can point out to our listeners where do they find your latest work and what to expect from the Team Topologies duo.

Matthew Skelton:
I love the questions coming from you today. And all the stuff that you’ve been pulling together at Boundaryless. Because this way of thinking is — it’s so key to the future of software enabled or digital enabled business, this way of thinking about ecosystems, thinking — being able to use different partners in different ways, kind of concept of APIs, and translate that into slightly more abstract context. These things are all — we’re learning from how we’ve built software over the past decades and applying this into kind of organizations and businesses. And these are things at scale. So, it’s not surprising that we’re taking a software approach like this. So, we’ve got our website, TeamTopologies.com, you’ll find a whole lot of stuff there. We are in the process of starting to update the website. We’ve got loads and loads of material on there, and those changes will be coming up throughout the rest of 2021.

We’ve just launched our Team Topologies Academy. This is our online self-paced training. There’s one video there right now, Team Topologies Distilled. Manuel and I are talking about the kind of core concepts. And we’ll have coming soon a new course. I mean, by the time you listen to this, as a listener, this may already be out, a course around platforms, treating platforms as a product, mentioned some of that stuff today. And there’ll be an increasing number of courses coming out over the coming months and years. We’ll be partnering with people too, possibly also including you two, Simone and Emmanuele, so we’ll have a chat about that, see if we can do a course together. But other people as well who have got awareness around similar concepts to Team Topologies, but we’re kind of effectively growing an ecosystem around this. People have got experience in data or domain-driven design or all kinds of organizational dynamics, perhaps people who’ve got awareness of complementary areas that sit around Team Topologies. And we’re also launching our partner program soon. If you go to TeamTopologies.com/partners, you can sign up for some early information.

Simone Cicero:
Thank you so much. And our listeners, please, buy this book, read this book, because it’s a crazy good, crazy important stuff. So, do it, and catch up soon.