This episode has been transcribed by artificial intelligence, errors may occur.

00:00 --> 00:55

Hi, and welcome to this special episode of the PlatformPodcast. As you might have noticed, this episode is in English, and that is because we have a very special guest with us today. Matthew Skelton is the co-author of the famous Team Topologies book and CEO and principal at Conflux. I first became familiar with the DevOps movement through the DevOps Days conferences, and later learned about the different DevOps topologies and how not to do DevOps with the DevOps antitypes through the work of Matthew. This work led to the book that many of our listeners, including Odin and myself, know as the Team Topologies book, which describes the four fundamental team types, Stream Aligned,

00:55 --> 01:26

Modeling, Complicated Subsystem, and the Platform Team, and their interaction modes, Collaboration, and As-a-Service, and/or Facilitating. So to kick us off, Matthew, can you tell our listeners how all of this got started from the DevOps topologies? Sure. And thanks for inviting me. I'd just like to say it's great to be here. And hello to all your listeners. Yes. So DevOps topologies.

01:26 --> 02:07

Let's take a journey back in time, climb into our DeLorean and press some buttons. So back in 2013, so this is now more than 10 years ago, because we're recording this in 2024. What is it now? Middle of January, 2024. So more than 10 years ago, 2013, I was working in an organization in London, and it's a big retailer. And the sales volumes are quite substantial. But there's about, I think it was about 300 people working in this organization at the time.

02:07 --> 02:48

So not huge, but also not absolutely tiny. And the organization was on the start of a journey towards cloud. At the time I joined, they still had everything in physical data centers that they managed. Well, I think they probably managed four of them. But anyway, there was a sense in which there was certainly no cloud, very little use of cloud at the time. Anyway, the two main groups in technology being kind of development and operations. We were on the same floor of the building, but we were physically separated. One operations at one end and development at the other. So there's a kind of dev and ops divide.

02:48 --> 03:27

And that was reflected in the kind of ways of working and different incentives and all of the stuff that we now know about from the whole DevOps movement that's been around since what, 2008 or so. And looking at the different kind of interactions and possibilities for working better together kind of prompted me to think through, well, are there some patterns that we can try and establish here? Because, hey, we could try and work really well together by effectively blending all of our activities. Let's work on everything together. Well, that could work.

03:27 --> 04:08

What about if we just worked on certain things together, maybe like logging or deployment or something like this? That could also work. It would have a different feeling, different trade-offs, but it could also work. What happens if in actual fact, the development was kind of responsible for all of the runtime success of the services that development's building and operations sort of provided some underlying set of techniques and tools and services instead that we could use? That could also work. And so on and so on. So there's lots of different kind of ways of working in these two different complementary

04:08 --> 04:46

skills groups. And that led to me writing a blog post. It was October 2013 I wrote this on my personal blog. It still gets like a thousand page views a month, which for my little blog is great. And I used Venn diagrams. We used Venn diagrams to try and articulate some of these possibilities. Some of the ideas actually came together through a couple of people that I was working with at the time. We did some workshops, early kind of DevOps focused workshops in and around London. One guy was called John, another was called James.

04:46 --> 05:17

We did some really interesting stuff together. It's kind of in-person workshops, exploring different ways of thinking about collaboration and this sort of thing. Some of the ideas came from there too. Anyway, I ended up with some Venn diagrams. So overlapping circles or perhaps circles that don't overlap. So Hans, you mentioned the kind of anti-types. So that's where we don't have any overlap or relationship between say development and operations. And the two groups are really quite separate and don't interact at all.

05:17 --> 06:08

And that's quite clearly an anti-type because we need some connectivity between them. Otherwise things fall down the gap. Anyway, so I put this blog post, I published a blog post back in October 2013. And it was picked up by quite a few different places. It went a bit viral and generated lots of discussion and led to lots of additional kind of language and terminology and so on and so on. Through that work on those DevOps topologies, so a series of patterns that focused on development and operations working together. Through that work, I met a person called Manuel Parish, who is now my co-author on the Team Supportees book.

06:08 --> 06:56

At the time he was, amongst other things, he was an editor at InfoQ. InfoQ being the organization that runs the QCon events. Odin, where you spoke on the track that we were together in 2022, right, in London with trolls. And anyway, I met Manuel back in like 2015 and we worked together on some stuff and he included some of the DevOps topologies patterns in, I think, an InfoQ ebook. And then we actually started working together on customer work because our kind of perspectives were really closely aligned. We started kind of trying to work through these DevOps topologies patterns with customers we were working with at the time.

06:56 --> 07:48

And we actually were commissioned by a huge Chinese technology company. I think they had 70,000 people worldwide to kind of expand on the DevOps topologies patterns and think through, well, how does this work at kind of global scale? So we did quite a lot of research. We found loads more patterns. We looked at alternatives around less and scrum and different flavors of Agile and blah, blah, blah, all kinds of stuff like this. In the meantime, organizations like Conde Nast International, big publishing house, organizations like Netflix had picked up on the DevOps topologies and publicly said, "Thank you for publishing these because it really helped us to think through how we want to

07:48 --> 08:41

operate at scale." Other organizations as well use the DevOps topologies like Accenture in their consulting work and so on and so on. So the DevOps topologies started to get more and more kind of traction and usage and commentary and people thinking about them and all this kind of stuff. And it caused us to think, well, fine, there's like, I can't remember how many there are, there are about eight patterns and perhaps 10 anti-patterns. But is there some way of really kind of condensing this or refocusing the intent behind that to help organizations become more effective? And the more work we did, the more we realized that actually, if you want to move quickly

08:41 --> 09:28

at scale or any sensible scale beyond just a few people, if you want to move quickly, safely, effectively, if you want to do DevOps effectively, then in today's world where technology is changing all the time, where regulations are changing all the time, where trading relationships are changing all the time, then you've got to take into account team cognitive load. You cannot just arrange your organization without thinking about the cognitive load on the people that are building and running these kind of services. So that needs to be a factor. We realized that a few of the fundamentals, like you really need to think about avoiding handoffs. I mean, that's kind of a fundamental DevOps principle, really, but I need to avoid the

09:28 --> 10:19

handoffs so then your teams look a certain kind of shape. You need to take into account the alignment to kind of business objectives or to business terminology, so kind of domain-driven design type thinking, and a bunch of other things as well. We can't have groups manually inspecting software changes before they go out the door. So the way that organizations used to do compliance and security and a bunch of these kind of things couldn't be sustained. So anyway, all this stuff, put this in the mix, put it in a big pot, stirred it up, and the Team Topologies book came out of that effectively. So the original DevOps topologies with the Venn diagrams or circles were kind of like

10:19 --> 11:01

an inspiration, I guess, for Team Topologies work, but really Team Topologies is a huge step way, way, way beyond those original Team Topologies patterns, which are quite static, whereas Team Topologies is very much like a dynamic thing. We're talking about, as you mentioned, Team Interaction Modes, the ways in which effectively we should think about teams interacting, and that changes over time. That's dynamic. This week we're interacting in one way, next week we're not. We're acting in a different way and so on. But I think it's fair to say that the... It's fair to say that the 2019 book has a focus on technology teams primarily, and business

11:01 --> 11:44

teams are close to technology teams. And if you like, the proving ground or the way in which we were comfortable making the recommendations in the Team Topologies book was because we'd been using those DevOps topologies patterns for many years before that. Five, six, five and a half, six years before the book was published. So we'd already had plenty of time to kind of test them out, understand the pros and cons, which contexts were suitable for one pattern, which contexts were not suitable for another pattern. In the Team Topologies book, though, effectively, so if you look at the subtitle of the Team Topologies book, it's Organizing Business and Technology Teams for Fast Flow.

11:44 --> 12:24

So it's specifically about we're making changes. We've got fast flow value. We're making changes to our software systems or to our other services on a regular basis. We've got many tens or hundreds of those changes going live every day. In that context, certain things need to take a particular shape. And so that's what pops out in the Team Topologies book. Yeah, so I think I would maybe say it's a bit of an understatement, said this went a little viral. Imagine if the blog post had gone a lot, really viral. But just the fact that when you write something and then Netflix says, thank you, that's a

12:24 --> 13:14

good thing, especially at that time when Netflix was when everyone wanted to copy. But I really like the approach Team Topologies has to the platform team. But I think for us to have a really good discussion about that, I think it's good if you can give a really short introduction to all the different types of teams and interaction modes, because they kind of pop up when you talk about platforms after a while anyway. Can you just do a short outline of those? Yeah, for sure. So what we wanted to do with Team Topologies is provide a bit of a language for people to talk about teams and interactions between them. And we wanted to have the smallest set of things that was still rich enough to capture

13:14 --> 13:54

a decent amount of organizational need, organizational behavior, that kind of thing. Our starting point in Team Topologies in terms of types of team is the Stream Alliance team. So a team that has end-to-end responsibility for an ongoing service or user journey or something like this, meeting a set of user needs on an ongoing basis. Mixture of skills, quite small, the team is about eight people. The reason it's small is because that's how we get maximum trust. And if we have maximum trust, then we can move very quickly. We can make decisions together as a team very, very quickly. We don't need to check each person's opinion. We know that we're going to make the same decision as a team because we've taken the

13:54 --> 14:40

time to build that team as a team, not just a collection of people. Because we've got end-to-end responsibility for that service, there's no handoffs. So then theoretically, that's the quickest way we can get stuff into production and the quickest way in which we're going to get information back from production. So telemetry, logs, metrics, observability, all of that stuff. When there's an incident, we get that information back into our team as quickly as possible, which is what we need because 24/7 software services now, this is starting to get... In some cases, it's life and death. Whether it's medical or if it's a case of someone receiving a benefit payment, and if they're freezing cold because their benefit payment didn't come through, are they going

14:40 --> 15:30

to die? It starts to get literally life and death with some of these services. So it becomes really important to think about this kind of stuff. So let's say to some extent in an ideal world, we might have lots of stream-aligned teams all working on services that are nicely separated with aligned autonomy. They're looking after their service and it's all fine. However, in reality, we can't have that degree of autonomy with teams looking after everything because the amount of cognitive load is too high. So if you've got a team that's looking after that benefits payment service, what do they think about?

15:30 --> 15:58

Do they think about all the security? Do they think about all the cloud infrastructure? Ooh, that's getting quite big now, particularly if we're using some of the public cloud. Do they think, or if we're not using public cloud, do they think about the data center? Do they think about the diesel generator or the solar power generator that goes behind it? Where does it stop? So their cognitive load has to be limited, otherwise they're not going to be able to deliver on the actual benefits payment service. And this is a fact, anyway.

15:58 --> 16:32

This happens all the time. So you can treat, you would not dream of having to build your own operating system or build your own silicon chip in order to write some code to build a website. That doesn't make any sense. But then, so people deal with this stuff all the time intuitively, but we wanted to actually make it much more explicit. So we need to deal with cognitive load in some form, and that's where the other three team types come in. So we've got an enabling team, which is a group of experts. They don't actually build anything themselves.

16:32 --> 17:12

They help streamline teams to increase their capabilities, increase their knowledge, increase their expertise with a particular way of working, a new technology, new service, new technique. And enabling teams are also what's called boundary spanning. So they span across different organizational boundaries. They can detect common problems across multiple different teams, and then bring that knowledge, bring that awareness back kind of into the center, if you like. And then we can do something useful with that knowledge. So let's say 17 out of 20 teams have the same problem with this particular, I don't know, data validation thing. I don't know, something.

17:12 --> 17:36

Right. What do we need to do? Well, there's a clear need for some kind of data validation thing, but it's really complicated. Are we really going to push that data validation activity into every single stream-aligned team? Really? No. Let's take that out. Let's take the cognitive load out into what we call a complicated subsystem team, because it needs really specialist knowledge.

17:36 --> 18:09

The people who do that data validation have probably got doctorates or PhDs in mathematics and some other bits and pieces like this, or geospatial data or something. Fine. So we're taking away the cognitive load and putting it into that complicated subsystem. But the way in which that subsystem then presents that capability back enables those stream-aligned teams just to consume it as a service. So friction-free, it allows those stream-aligned teams just to use that component. There's no messing about. The user experience or developer experience is great. They can use it.

18:09 --> 18:50

It helps them with their flow and it helps the stream-aligned teams to own their service. Good. Fine. At some point, though, we might need multiple services, multiple of these services. Things for managing stuff like cloud infrastructure, managing things like machine learning, could be having to deal with consistent user experience or consistent design. And when we've got a need to provide multiple services like that, that's what we ended up calling a platform in team deployment. I personally now don't really like that phrase, platform. It's not ideal.

18:50 --> 19:22

We are on the Platform Pod and Podcast, so we have to be true to this. I think it's fine. I think it's fine. But it just means so many different things to different people. But a platform effectively is doing the same thing. It's improving flow in stream-aligned teams by reducing the extraneous team cognitive load. That's how we see it. Its purpose is around flow and cognitive load reduction, not about shared services, not about saving money, not about a bunch of other things like this, which traditional platforms

19:22 --> 20:05

were focused on. And I think what we've seen is that using a different lens, a different pair of glasses to think about the purpose of a platform really helps. The purpose of the platform there is to improve flow in stream-aligned teams that use it by reducing their extraneous cognitive load. It gives it a mission effectively, that that platform then has internal customers, which are the stream-aligned teams. But the platform crucially works with those enabling teams to detect missing capabilities. The platform also should be reaching out to those internal customers effectively and asking them what they need, detecting what they need, having conversations, running prototypes with

20:05 --> 20:51

various different teams to work out the best way in which to provide some of these services, or even perhaps to realize that the platform is not going to provide those services, and those some capabilities are actually best placed inside stream-aligned teams. The platform is not there to take orders from stream-aligned teams to build whatever the stream-aligned teams want. That is absolutely not the purpose of a platform. I've certainly started to use the phrase flow platform instead of just platform because it emphasizes that this is not a lump of technology, it's actually its purpose is around flow really. In the next Teams for Teams book, I think we'll probably end up calling it something like flow platform instead of just platform.

20:51 --> 21:48

That's very interesting and resonates so much with my own opinions about platforms as well. But what I think many of our listeners might really be very interested in is how to get started. Most of them, myself included, have encountered, "Oh, we're going to make this platform and we are going to take 24 months before anyone can start using it at all," and very upfront and trying to solve all the things at once. How would Team Topology book advocate towards getting started with a platform? That particular approach to platform sounds like it's failed already, so I don't do that. I would pose a question like this. I would pose a question like, "How far could you get without writing a single line of code?"

21:48 --> 22:25

My background is as a software developer. This is how I started. I started building... I started my career writing software for brain imaging machines and oil and gas industry, and then local government, and then financial services, and a bunch of other things. It's not that I don't like software and code. Getting in the zone is amazing, but you pose a question, "How far can you get without writing a single line of code?" Because you can actually get quite far, because the starting point can actually just be a wiki page that says, "Hmm, well, here's a nice way to configure this particular thing,"

22:25 --> 23:07

or "Here are some principles to think about when writing code," in our context. That already is reducing cognitive load by helping people to think about things in a particular way, or by reducing the options that they've got. I don't know how many services exist in AWS, in Amazon Web Services now, but it's thousands, thousands of different products and things you can use. Where on earth does a development team get started with that stuff? A platform can be, in team's policy terms, a platform can actually literally be a wiki page that says, "For the kind of services we are building here at our organization, just use these nine Amazon Web Services. Just use these nine things.

23:07 --> 23:37

Don't use anything else. We've done the research. Constrain yourself to these things. If you use these nine things, we as a platform group will support you." That is, and you've not written any code yet. Heavy lifting is done elsewhere, but what you're doing is curating an experience for those engineers who are using that platform. Only at the point where you really, really need to write some code do you do it. To be honest, that should be true anyway. It should be true of anything, because code is a liability.

23:37 --> 24:28

It's not an asset. It's not a liability. Really start with a minimalist mentality. That's why in the Team's Policy book, why we call it minimum viable platform. Because we're trying to make it as ... Sorry, it's actually not minimum viable platform. It's TVP, it's thinnest viable platform. We're trying to create a platform that is as thin as possible. In the sense of the things that we're building in our organization. We're definitely, we're almost certainly, in most organizations, we're almost certainly using a kind of ... We're composing that platform of services from outside, or from tools that

24:28 --> 25:02

third party vendors are providing, and that's fine. The platform can be that curated experience around how to pull those different tools together, and how they can work really well effectively together. I guess that would be my starting point, is how much can we get away with about writing a code? What does the wiki look like? What does that curated experience look like to start with? Keep challenging yourselves around that to keep that platform as thin as possible. In reality, if you're inside an organization of a reasonable size, you'll end up writing some code.

25:02 --> 25:32

It's fine. You will get to write, if that's what you like. Yay. Exactly. The goal is not to try and build something really fancy. The goal is laser focus on improving flow in the streamlined teams with a really good user experience. Basically using your own language, we should start as an enabling team, not as a platform team. Because you should try to, and using the facilitating mode when you talk to your teams, and then

25:32 --> 26:04

only when you see you need to scale this out and you need to operationalize it, then you can start thinking about making a platform as such. Exactly. That's exactly what some forward-thinking organizations have done in exactly this space. You might have multiple independent stream-aligned teams. Start with an enabling team. Work across those streamlined teams. Try to understand what the common problems are, and then go, "Well, it looks like there's a specific problem around, I don't know, configuring this thing." Right.

26:04 --> 26:29

Let's work out what that looks like. Let's try and provide that. Let's try and meet that need. Work with the teams, prototype it, get it rolled out, and then iterate from there. But we're not trying to build all the things. Because to be honest, by the time you've built all the things this year, half of them will be available in AWS or Google Cloud or Microsoft Azure next year. What's the point? It's a massive waste of money. Massive waste of time when you can be focused on things that are more central to the organization's

26:29 --> 27:06

mission. And that's a fairly good point. I've encountered organizations that have taken, "Don't write any code to heart," because they built up this cloud center of excellence, and we're going to write thousand upon thousand of Wiki pages. We're in, "This is how you set up everything from scratch, everything under the sun," trying to cover all of the AWS services that can exist. But that makes no sense, because there needs to be a curation there. There needs to be an opinionated approach to it. And if it's just extra layers of documentation or even extra layers of code, wrapper code

27:06 --> 27:52

around someone else's cloud, what's the point? Just let people get access to the real stuff, but help them by maybe better onboarding or better configuration files or something that basically smooths their experience and allows them to use their existing experience with AWS. If you're hiring an Azure developer or someone, they've already got previous experience. Help them use it, but use it in a focused way. Use a platform as a focusing lens to help zoom into what we're trying to do inside the organization. But then when you've gone a further bit down the road and you have this platform team or this group of platform teams, it seems like the platform team should try to organize using

27:52 --> 28:20

team topologies, building projects, focusing on flow and having stream-aligned teams and having enabling teams and having different kinds of interaction modes as well. Exactly. Now, at this point, I need to hold my hand up. I'll do it on the podcast. I'll do it for you on the podcast. You can see I hold my hand up here. For those of you who are listening on the podcast, I did actually hold my hand up on the video. I can confirm this.

28:20 --> 28:58

We made, effectively, we made one mistake in the team topologies book, which was that we listed the platform as one of the four team types. What we've realized is not really the same kind of thing. Platform is more like a grouping. And certainly, so this year, 2024, we're going to start some work on some new materials around this. So it's effectively, instead of four team types, it's really three team types and a special grouping called the platform grouping. That kind of breaks the system, though. Yeah, that's quite a mistake.

28:58 --> 29:37

But we'll do what we can to correct you, basically. But it's still useful to identify the platform as a special kind of grouping, because there'll probably be other kinds of groupings, too. There might be groupings of streamlined teams if they're working on similar things and so on. But the platform has a specific purpose, because it's, like I said before, its purpose is to improve flow and reduce cognitive load. Whereas other kinds of groupings might not have the same kind of purpose in the same way. So it's still worth calling out as a separate kind of entity.

29:37 --> 30:24

But it's a grouping in the sense that it's like a container for other types of teams. Container for other types of teams and other types of groupings, including other platform groupings. So yeah, I mean, that's actually the way that we've already seen it. And in the Teams bodies book, there are some diagrams that show other types of teams inside a platform. But some people don't read past the first two chapters or three chapters of the book, so they don't see it. So yeah, a platform is a kind of container, or you can zoom into a platform and see the same types of teams and activities as you would see outside the platform.

30:24 --> 31:06

So you'll see streamlined teams inside a platform. You'll see enabling teams. You might see a complicated subsystem or two if there's something really awkward in there. Like I don't know, if you're writing your own authentication or you're writing your own encryption for some reason, maybe, then you might have like a complicated subsystem in there because you need people who really, really, really understand that stuff. But you might also identify some additional platforms inside that platform because kind of the lower level platforms are things like the cloud providers, or if you're running your own data center, you treat the data center as a platform. So that's sitting inside.

31:06 --> 31:50

You can zoom into and zoom out of the view of that platform area. And that's actually really important. So it's a fractal way of approaching organization design. We're using the same principles and patterns at all levels of the organization effectively, and the same language. So then, whichever, certainly inside IT or technology, but to be honest, outside of IT and technology too, you can use the same language and terminology to talk about the kind of things we're doing. And in fact, we're doing some work with, we're doing some amazing work actually at the moment with a green energy company in North America.

31:50 --> 32:28

They're rolling out solar farms and helping citizens to get access to renewable energy. We're starting to look at how TeamSport applies to their legal department, to their marketing department, to their finance department, but also to their department that is rolling out solar farms. Now this is all a little bit experimental. We're pretty confident it applies to knowledge work. So the finance and marketing and accounting, legal side. It may also apply in some ways to more physical things like rolling out solar panels in a solar farm and testing and that kind of thing. We're investigating it.

32:28 --> 33:06

And being able to have a similar language across the whole organization when thinking about cognitive load, flow, team responsibilities, trust, all of this kind of stuff is proving really interesting and for some organizations proving really valuable. But yeah, certainly to go back to that platform thing, expecting to zoom into the platform. If you zoom into the platform area, you'll see similar kinds of teams like streamlined teams. We need to identify our customers. We need to manage cognitive load. We need to think about what our supporting platforms are for those teams inside the platform and so on and so on.

33:06 --> 33:52

It's a bit like platforms all the way down. There's a bit like you're stacked on top of a set of other platforms because at some point the cognitive load is too high. You want to fix, you need to fix some aspects of either technology or services that are provided so that you can do other things because otherwise the depth of the stack is too tall and you have to think about everything. You have to rework everything. Every time something changes and it just becomes impossible. It makes absolute sense. It makes absolutely sense, Matthew, because at Nav we do have multiple platforms.

33:52 --> 34:46

We have the application platform, we have a data platform, we have a design system, we have a CRM based platform, we have more infrastructure. So platform is multiple platforms and being in one of these platform teams, I know for a fact that what you're saying that we do have a separate authentication subsystem that is complicated in its own way and there are really high skilled people involved in making that actually work as a service more or less. There is a fair amount of enabling work that goes into especially when onboarding new teams to the platform and in addition to sort of providing a platform as a service, providing documentation, answering support. So yeah, it makes all the sense in my mind that this is a specialized grouping, absolutely.

34:46 --> 35:39

We have also seen, at least at Nav, where in the context of an application platform and migration from older legacy systems to new systems, that when you have the platform team can send some of the more specialized skilled people out to the Streamline team and basically collaborating with them and helping them do the necessary modernization to be able to move on to a new platform. I think it speeds up a lot the work, at least we have to do with migrating to a new more modern architecture when you have people that don't necessarily know everything about the domain but they know enough about the platform and the technology to help the Streamline team in that way. And as they're working there, those experts from the platform, in team support terms,

35:39 --> 36:25

we call that an enabling team because it is a temporary thing probably. But they're able to, where they're working alongside the Streamline team members and they'll discover some things which are completely surprising. They'll discover a mindset. They'll realize that some people in that Streamline team have a very different way of thinking about something like databases or data or cloud provisioning or something. And they go, "Oh, wow, I had no idea that people would think about things that way." It's like, we need to change our documentation or our onboarding or some aspects of developer experience to account for that mindset or that way of thinking, which is hugely valuable because then it means that we're improving the platform services and that curated experience

36:25 --> 37:20

I talked about before, we're effectively continually curating it as we're working with people in Streamline teams. And we talked a bunch about the thinnest viable platform and proving the platform or that there are common capabilities here that can be the fundamentals of a platform. But what I'm very curious, any advice to how to stay up with what are the evolving and changing needs of the Streamline teams? Because what I see in certain extent, and I can see it internally at Nav as well, that we have some very well-established platform functionalities, and then we end up really, really refining those. And maybe we are missing out on what's the next thing that the platform should provide.

37:20 --> 38:01

That's a really nice question. I think there's two broad approaches to this. And these are the same approaches that you will find in a public cloud provider or any other kind of SaaS or other technology provider anyway. And the two ways that, well, let's call it three ways. The first way is telemetry. So you've got telemetry about how your internal customers are using that platform. So you're looking at the number of API calls, you're looking at the account usage, you're looking at the data egress, ingress, all of this kind of stuff, you're able to detect that automatically, which is useful.

38:01 --> 38:30

That's fine. But then you need to have actual conversations with the product people and the technical people inside the Streamline teams, like what are you doing and what do you need? What's not working? Can we just have some time together? Just as you would do with key customers, if you're a cloud provider or some other technology provider. You go and have those conversations, you go and do that discovery. You might do some joint projects together. I say, hey, we've got some experimental stuff around this.

38:30 --> 39:17

What should we do? I don't know, some machine learning thing. And you find a Streamline team that's willing to invest a bit of time in it because they see there's something in it for them and the platform knows there's something in it for the platform because there's opportunity to provide something that's really valuable. So you might just do a little bit of research and development or skunk works or something like this where you do a little bit of investigation, again, just as a cloud provider will do. But the third thing is much less technology-centric, much less product-centric. The third thing is social approaches to this, internal talks. Even things like the tech radar that you've got now there, which is just amazing.

39:17 --> 39:59

I love it. I totally love the tech radar thing. Your approach to the tech radar is just amazing. But lunchtime talks, how do you persuade people to come in from outside Oslo into the center or even from Bergen? How do you persuade people to come in and do a talk in somewhere central? Well, provide some food. Have a budget for food and make it a social thing. Figure that out so that you've got an internal conference program. Every year or every six months, you're coaching people to talk about what they're doing and

39:59 --> 40:47

you're using all of that conference approach to share information in a really compelling way with other people to help people realize what's special, help people realize that they've done something that is actually worth talking about, collect the charts, write the story, get some help in presenting skills, get some help in creating the slides in a way which is compelling. So, you know, we're not using like 12-point font and really impossible graphics. We're using something which actually is really appealing to people and tell a story and share it. So, yeah, I think there's kind of standard technology approaches, the standard product management approaches, but there's also the social approaches which are much less obvious

40:47 --> 41:27

to lots of technologists. And the social approaches can actually be the ones that trigger and encourage the most powerful change and awareness, I think. So I know we said platforms was going to be the main topic of the... I just have one question. Have you had any adoption of these patterns and this way of thinking outside of the technology space in other kinds of businesses or in other kinds of organizations? Yeah, it's been really interesting. So I mentioned we're doing this work with an energy provider and they've got several different departments looking at it, but we also know of organizations in the legal sector,

41:27 --> 42:15

so like a law firm, looking at using these team patterns to help them think through how to provide legal services in a way which is more modern and more customer-centric. But certainly in the UK, the traditional model was you had legal specialists in different areas like business law, family law, property law, blah, blah, blah. But if you had somebody coming along, let's say we've got a woman who's got two children, she's a business owner, she's going through a divorce and she needs to move house. That's at least three or four separate areas of law. And traditionally, she would be bounced from one specialist practitioner to another one inside the law firm. Like that's the worst user experience ever.

42:15 --> 42:48

Why would anyone want to do that? Why not try and arrange things so that we can meet her needs, which is to move house and deal with her shareholding in the business and make sure that the children are safeguarded altogether? It's not impossible. It just means you have to rethink how we offer those legal services from inside the organization. But then how do we use that legal expertise? Because some of this stuff is quite complicated. Do we use the expert lawyer as like an enabling team or try to codify some things as like a complicated subsystem?

42:48 --> 43:34

I don't know. But this is what this law firm is investigating. So it's interesting and it does seem to apply to knowledge work. Interestingly, so we started using the phrase team cognitive load back in 2018 as we were starting to talk about the book the year before it was published. Round about the same time, certainly in English language, this phrase team cognitive load started to be used in the medical profession completely independently. As a medical profession, it's really interesting. The more handoffs there are between different groups of medical professionals, the greater the chance that someone's going to die.

43:34 --> 44:09

This is probably life and death. I can't remember what the statistics are, but it's something like if there's four handoffs between in certain kind of emergency situations, if there's like four handoffs, then the chances of dying goes up by 50% or something like this. So they have got a real problem to solve, which is we need to avoid handoffs because if we hand off this patient to another group, their chance of dying is going to increase. Let's keep them in the same group. But then you've got all kind of different kind of medical specialisms needed and complications. And then can we really learn how to operate an X-ray machine inside this group? That feels like too much cognitive load.

44:09 --> 44:56

So they're dealing with similar kind of problems, but well outside of technology. And we had in the UK a couple of years ago, we had like a deputy director of like doctors, part of the health service in the UK, in Wales, part of the UK. And she was like, "Oh, Teens Bodies seems great for organizing like doctors' surgeries, doctors' practices. Let's apply it to the whole of the health service in the UK." And that was just like an off the cuff statement on social media. But people can see the value of using the patterns in very different contexts. And it is this year, 2024, is when we're really starting to find those cases and work with people to understand where the edges are, where the patterns don't apply, because they

44:56 --> 45:40

won't apply everywhere. And maybe we need to slightly tweak the change of terminology a bit. I don't know. But this is what we're focused on this year, is finding these situations outside of IT. It's really amazing to hear you talk, Matthew. And I wish we could go longer and dig into all the details of Team Topologies. And I guess that our listeners as well would really appreciate that. But we are nearing our end of this episode and the recording time we have booked in here. So maybe that we will save those questions and ask our listeners to come up with questions. And we'll see if we can invite you back on again and we can answer those.

45:40 --> 46:05

Sounds good. But before we end things, are there anything we have forgotten to ask you or something you want to mention, Matthew? Just a couple of things. One, we've now got a small but expanding partner program to help around the world in different countries. So please reach out if you need some local help. In local language, for example. For example, I think we've got two partners in Norway already. A Norwegian language.

46:05 --> 46:43

So interesting opportunity there. We have an online academy for learning. If you go to academy.teamtopologies.com, you'll find lots of really good video courses there. And people have really appreciated those. And we've just launched an approach to assessing team cognitive load called Team Peritja. And if you do a search for that, you'll find more details. So we're trying to make these patterns and ideas come to life and be useful for organizations of lots of different sizes around the world. That's so great to hear. And I'm really looking forward to the next edition of the book that you mentioned that

46:43 --> 47:13

you are... I've got to write it first. So this has been a special edition of Plattformpodden with Hans Christian Flotten and Audun Føykaldstrand. Our technical producer is as always Tore Græsdal. The newest episode, you will always find them on plattformpodden.no or your local podcast app. Please follow us on LinkedIn. Thank you. Bye.