[Intro Music]
Clare: Hello and welcome to Making Tech Better, Made Tech’s fortnightly podcast, bringing you content from all over the world on how to improve your software delivery.
My name is Clare Sudbery. My pronouns are she and her, and I am a Lead Engineer at Made Tech.
Some time in 2020, I went to an XP Manchester session, where my ex-colleague Neil Vass was raving about the book Team Topologies. Ever since then, I’ve really wanted to find out more about it. So, on Monday 20th August 2021 I got my wish. I had a good long chat with the book’s co-author, Matthew Skelton.
Clare: Hello Matthew!
Matthew: Hi, it’s good to be here.
Clare: It’s great to have you.
Matthew Skelton is the co-author of the book Team Topologies. That’s mainly what we are going to be talking about today. As always, I’m going to start by asking who in this industry are you inspired by?
Matthew: That’s quite a nice question because there are so many good people working in software. When I thought it through, there’s people who have pursued their work through the sense of being a practitioner, actually doing the work. Or maybe through the desire to fight some kind of injustice, as well. For me that ends up being important. So, the specific people I have found inspiring are Ruth Malan, she’s basically been tireless on her work around software architecture. She ended up writing the forward to the Team Topologies book, so we were super happy about that.
People like Clare Sutcliffe MBE, because she founded Code Club ages ago. Possibly something like 15 years ago. She grew that in the UK and grew it worldwide to 120 countries or something. I know that was taken on by the Raspberry Pi Foundation. Now Clare does work in technology education. So, super-inspiring to see that kind of growth and dedication to something which doesn’t immediately have a big revenue stream.
Clare: Yes.
Matthew: But she has had a massive impact on technology education, just incredible. I’ve long admired Daniel Terhorst-North, who has been a legend in software development and thinking for decades, really. He’s so relentlessly positive, as well as being an amazing technologist. That’s super inspiring.
I think Gene Kim from IT Revolution, the publisher of the Team Topologies book, but also the people who run the DevOps Enterprise Summit. He’s got endless energy and enthusiasm for making large enterprises better, and software delivery and IT in general.
Those four specific people, but really anyone working in IT who is fighting the endemic misogyny and racism and other barriers put in place and held in place by often very mediocre people, usually men. It’s very obvious in the tech sector that there are lots of people who are doing some amazing work and being very vocal about it, and slowly making some important changes. It’s good to see, and it’s inspiring.
Clare: Yes. So, Daniel is actually an upcoming guest. We’re going to be speaking to Daniel very soon. Ruth is very much on my hitlist, Ruth is amazing. I will have to look up the other two. Fantastic, thank you.
How did you find yourself specialising in team topologies?
Matthew: I suppose it goes back to the very start of my career. There are a few threads that go back some twenty years. In my very first job, I was working in a company that was building brain scanning machines. My role there was writing what was called desktop software, to take the three dimensional image data, then allowing the person operating the machine to take virtual slices through a brain scan. So, manipulate the scan on screen in real-time.
There were four or five us of working on the software at that point. And at that point, we didn’t even have version control, so I introduced version control into the company.
Clare: Wow.
Matthew: It was clear that the way in which we were interacting was at some points causing problems for how we were doing the software development. I was interested to try and explore solutions even at that point, and that was twenty years ago. That was before modern version control systems were in place. This is before a lot of the modern agile practices were adopted.
So, I guess I can trace a bit of a thread back for decades but the recent work on team topologies really started for me in 2013, when I wrote a blog post on my blog exploring different kinds of team boundaries and relationships, in the context of what was then called DevOps. In other words, the relationship between development teams and operations teams, and how they could be more effective working together. That’s what DevOps meant at that point, it means something different now.
The patterns — I kept seeing them as a Venn diagram, basically, showing separate responsibility or some kind of overlap implying some kind of collaboration. These ended up being really useful. Companies like Netflix use this, thinking about the shape of their teams. Companies like Conde Naste International, the big publishing house. Hundreds or even thousands of other companies around the world use these DevOps team topologies as we called them then, that we published on our website back in 2014, 2015. They helped people think through different responsibility boundaries and different options for helping organisations become effective at software delivery. Also, some anti-patterns as well, some things to avoid.
Now, as we developed those ideas and the thinking and the implications around it, it became clear that something more was needed. That static responsibility boundaries were kind of a useful starting point for a conversation, but not really the only thing that you need to think about.
So we explored more and more things, I did more and more talks, brought in more and more thinking and examples from people tackling some of these things at an interesting scale and in interesting ways. Then together with Manuel, my co-author, we’d been working together for the past few years on lots of different client work, companies in different parts of the world. So, we came together and said let’s try and pitch a book.
So, we pitched the book to Gene Kim’s publishing company, and they said yes, which is great. It turns out they’ve got the ideal audience for this kind of book. It came at the right time, bringing together the right kind of ideas, the right architecture and Conway’s law, team cognitive load, things like this. Many of these ideas had been floating around, we were the ones to bring them together. We also did introduce some entirely novel concepts too. Particularly the use of the concepts around team cognitive load, which is an innovation.
We introduced things around adaptive organisations, particularly team interaction modes. So, thinking about the ways in which teams interact as a first class thing, helping organisations to have better conversations around what they want to build, and how, and when.
So, I guess it was kind of an evolutionary process. I did a master’s in neuroscience, so I am interested in how the brain works at a biological level, but also at a psychological level. It’s still a strong interest for me to look at this whole thing of software development through the lens of not just the technology but also the people, the teams and the grouping and the organisation as a whole. That’s how we got to Team Topologies, basically.
Clare: Right, okay. There were loads of things that you mentioned there that now I want to know more about. It was just an aside, but I am interested, you mentioned how the meaning of DevOps has changed. These days I find myself not actually clear what people mean when they say DevOps. How do you think those meanings have changed?
Matthew: It’s a good question. To an extent, the ship has sailed, really. We have to go with the meaning that is very vague now. Back then, lots of organisations had two separate groups. One Development, Software Development, building applications, and another called Operations running things. So, you would hand over that software to a separate teams that would run things.
Increasingly, that model of building something and then running it as two separate things is becoming less and less relevant. DevOps these days seems to mean automated infrastructure. Or for some people it means the operational side of development, which is a hugely restricted view of what DevOps really ought to be, which is more like a set of collaboration patterns or something.
Clare: Yes. I still think of it as meaning the idea of doing Dev and Ops all in one team. That DevOps comes together, and people collaborate to do Dev and Ops, rather than there being some kind of divide, some wall that things get thrown over. But I have noticed that people use it differently and I find myself getting confused. So, I think it’s interesting to draw that distinction.
The other thing that you mentioned was Conway’s Law. It’s probably worth explaining what Conway’s Law is for people if you’re able to do that. And maybe how it is relevant to your work.
Matthew: Yes. So, in 1968 Mel Conway, who had experience working in the US Military and also for some large US computing corporations wrote and published a paper. The name of the paper was How do Committee’s Invent?
He was looking at the relationship between the communication pathways inside organisations, and the likely systems that end up being built. This was a very early socio-technical view of the emerging practise of software at the time. In 1968, software was a relatively new thing, but it was clear to some people that included Mel Conway, that there were some interesting dynamics happening here.
Effectively, there was a mirroring, a mirror effect between the communication pathways in the organisation, and the likely architecture of the thing that you were going to build.
It’s actually not a mirroring between the team structure and the architecture. It’s actually about the communication pathways that exist inside the organisation. Interestingly, in the last fifteen years or so there’s been some research into lots of different disciplines including software, but also aerospace, car manufacture, jet engine design. Some similar patterns have emerged there, as well.
If it is a mismatch between the team or group communication and the system architecture, then you will end up getting problems across that interface, across that boundary.
So, it seems like there is some kind of natural force or emergent force at work in these kinds of contexts, where you’ve got groups of people building stuff. Lots of people call that homomorphic force, in other words it tries to make things self-similar. Now, you can choose to ignore it, or you can choose to work with it. It’s not a law like gravity, where the vast majority of the time, if you’re on Earth, at least, then that gravity will exist. It’s more the tendency, that there is something pulling in that direction.
The question for organisations is, do you want to spend time and effort fighting against this force, or do you want to align things so that you are taking advantage of this natural force? Obviously, sensible organisations are avoiding fighting against this kind of mirroring effect that tends to happen.
Clare: Can you give an example of a communication pathway that might frequently get reproduced in the architecture of software?
Matthew: A classic one is that if you have a single database administration team that is responsible for doing all the database changes in the organisation, then you typically end up with a single shared database. Because it is in the interests of that single team to optimise for their own use, and then put all that stuff in that same database, so that they can manage it better.
So then you’ve got a mirroring between the social side and the technical side there. Whereas, if you had some sort of data capability inside multiple teams, you might have independent data stores instead. It’s that kind of thing. There are aspects around different tooling as well. If you have one tool for tracking bugs in software that is just for developers, and a separate tool for tracking bugs in software that is aimed at operations people, then you will end up with a harsh divide across those two tools. Which is something similar because you’re not cutting communication down. So, there are multiple angles as to how this plays out which are not necessarily immediately obvious to lots of people.
Being aware that there is this mirroring happening, that relates to how the communication works is by no means the only design concern, really. There’s lots of other design concerns. But, if you’ve completely ignored this mirroring tendency, then you are likely to be putting effort and fighting against this tendency, which is just waste, effectively.
Clare: Yes, interesting. I think I would quite like to explore that a bit more now that we are talking about it. Now I’m thinking about what people sometimes refer to as the Inverse Conway Manoeuvre, which is an attempt to use Conway’s Law to your advantage. Is that something you are able to talk about?
Matthew: Sure. So, the idea is that if we take on board this idea that the communication pathways in the organisation end up being mirrored in the software architecture, then the question is, if we want to get out of this problem, why don’t we try and work out what our ideal software architecture would be, or the kind of software architecture that we want, in the context of modern software. That it’s an architecture that allows for fast flow change, that has some asynchronous elements to it. It’s not all coming off one big relational and immediately synchronous data store. There are some asynchronous elements there as well, messaging and what have you.
Then there is a kind of architecture that we know scales really well. Some people call it reactive. Whatever, it’s been relatively well known since the 1960s what kind of architecture this is. So, we start with this architecture which we know is going to help us scale. Then, we change the teams and the communication pathways between teams to reflect the architecture that we want. That’s the inverse Conway manoeuvre. So, in other words we are changing our organisation to give us a better chance of achieving this architecture that we know is going to be effective.
It doesn’t guarantee that we are going to be able to build that, but at least we’re not fighting against this mirroring tendency.
Clare: Yes, fantastic, thank you.
I know in your book you identify four types of team. Can you tell me a little bit about that?
Matthew: Yes. Before I do, I want to say why we did this. In our work, Manuel, my co-author, and I, what we saw is that so many people in organisations were demoralised, they were confused. They felt like they were wasting time. There were lots of negatives about how people felt when they were in teams inside lots of organisations. One of the reasons we found behind that, was that people didn’t really know what type of team they were in. They didn’t really have a sense of purpose or definition. The teams were very nebulous, they were not well defined.
Sometimes managers would say hey, just do this piece of work, or hey, just do this, can you take on this other responsibility? Maybe you just need to take on some responsibility for this database. So on and so on. There was a huge lack of clarity in lots of organisations about teams, the size of teams, the purpose, the remit, the skills, whatever.
So, what we wanted to do was to try and come up with the smallest number of different types of team, that would then increase the clarity for the people in the teams and outside the teams, to help have better conversations about what we’re doing.
That’s when we ended up coming up with the four types of team that we talk about in the book. If your context is a fast flow of change, then we think that these four types of teams are the only ones that are needed. We also think that it is valuable to map and convert existing teams into one of these four types.
The starting point is what we call a Stream-aligned team – a team aligned to the stream of change. This typically could be a value stream, or it could be a product, or it could be a government service, like a citizen-focused service for example. Or it could be aligned to a user journey. We talk through different ways of finding effective stream-alignment in our book. Our starting point is what you would call the business domain. So, if we do find a stream of change that is relevant to the business and relevant to an end user, crucially, then we find a team around part of that flow of change. That team has all the skills they need to build, test, deploy and run that software in the live environment, in production. This might be what you call a DevOps team.
Clare: Yes.
Mathew: In other words, end to end, they are doing development and operations if you like. They are doing all the bits that need to happen for that service. And the reason we do that is because one of the greatest sources of waste or slowdown in an organisation, is handing off from one team to another.
So, because this team has end to end responsibility, we are not handing off this work to anyone else. It is entirely within this team. So, there’s a nice fast flow of change towards production. Because they are responsible for running that thing in production, they also have a detailed understanding of how that thing is actually running. They are very close to the users, they get feedback from users, maybe directly. They also get telemetry and logs and metrics and things from the live environment back into their team, so they can improve it really quickly.
That sets things up for a very rapid cycle time. Amazon have been running their teams like this for nearly 20 years. Clearly, it’s not prevented Amazon from growing to a massive scale.
Clare: Yes.
Matthew: We can at least say that it has not prevented them, and it probably has been part of the success. This is our foundational starting point. These teams need to be decoupled from each other. We need to find ways to have multiple separate streams of change. Otherwise, we are waiting on other teams all the time. We want to avoid these kinds of blocking changes.
It’s also worth saying that the size of a team is effectively limited. If you think about sports, I’ve only found one sport so far in the world that has more than 15 people on the field, which is Aussie Rules Football. Apparently, there are 18 people. But pretty much every other sport has 15 or fewer people. This speaks to some trust boundaries, effectively. As humans there are different groupings and different kinds of trust that can happen within different groupings.
There is a trust boundary which seems roughly around 15 people, which is why typically sports teams don’t grow beyond about 15. There is another boundary somewhere around five to eight people. There is a further boundary at around about 50 people, another at around 150 people and so on.
The military, different militaries around the world have discovered these boundaries over the course of many hundreds of thousands of years, of course. That’s why you would have things like units and troops and squadrons and blah blah. They discovered the effective sizes of these things. We can look at that and inform the likely point at which trust is going to be less effective in different parts of our organisation.
Loads of organisations just continue to add more and more people to the same grouping and expect things to be the same. That’s why you get so many problems.
Clare: Yes. I wonder whether there is some network theory in there. That the more people you have, the more lines of communication you have. Actually, just adding one more person to a group has a massive impact on the possible number of connections between people. It grows exponentially.
Matthew: Well, that’s one reason why we wanted to come up with a team-based approach. A team-based approach cuts down by an order of magnitude the number of different lines of communication. If you start with the team as a central unit of work, or the central grouping, rather than the individual, then it significantly simplifies by at least an order of magnitude if not more, the number of different lines of communication.
That was another driver for us to think about these four different team types. Our stream-aligned team has got a limit. For most organisations it is probably a limit of about eight people. Some organisations with very high trust might be able to have up to fifteen people in a single grouping. Typically speaking, it’s unlikely that your organisation has high trust.
If you are in that kind of an organisation with high trust, that’s great, go for it if you can. But even then, a grouping of a single team of 15 people might end up internally feeling like two sub-teams anyway. That can work. But as a starting point, just expect a single team to be no more than about eight people. It’s quite small, but what we are aiming for — we want high trust, because we want to be able to make decisions very quickly. We want to be able to have full context and trust the other people inside our organisation. We’re not worried about what they’re doing, we trust that they are writing the code and testing the code and specifying it and making changes in production. In the way that is best for the customer, but in the way that is not damaging for the team.
Crucially, there is a limit on the size of the software that a stream-aligned team like that can build. So, you can’t just keep adding people.
Say you’ve got eight people, they can work on a system, on a service. Let’s say it’s some kind of government service for registering citizens for some new medical update service, or something like this. It’s for receiving a medical alert or something to do with a pandemic like we have been through recently. People can sign up and they can do various things, whatever. That team of people cannot keep growing that service indefinitely. Because at some point, the complexity, or the number of things that they need to think about when they are building that thing, will become too large.
At that point they will slow down, they will have less trust, they will be able to do things less quickly and therefore, it works against the flow of change. So, a key design principle in Team Topologies is we have team-sized software. Team sized software becomes absolutely for us a fundamental architectural principle that we need to be designing for. We want to have the flow of change, we want to maintain high trust inside teams, because that gives them context and awareness about the users, awareness about the software itself and so on. We cannot just let the software grow indefinitely.
At some point, we either have to split the software in two, maybe two equal sizes, maybe two unequal sizes, whatever, ideally along domain lines, but it could be along a different line. Or we find some other way of reducing what we call extraneous team cognitive load on that team. It could be through training; it could be through a different set of skills. That might get us a little bit further. Or it might be through removing some of the responsibility from that team and putting that responsibility elsewhere. That is where the other three team types come in.
Clare: Okay. I was waiting for that.
[Music sting]
Clare: While I’ve got your attention, let me tell you a bit about Made Tech. After 21 years in the industry, I am quite choosy about who I will work for. Made Tech are software delivery experts with high technical standards. We work almost exclusively with the public sector. We have an open source employee handbook on GitHub which I love. We have unlimited annual leave. What I love most about Made Tech is the people. They have such passion for making a difference, and they really care for each other.
Our Twitter handle is @madetech. That’s M A D E T E C H. We have free books available on our website at madetech.com/resources/books, and we are currently recruiting in London, Bristol, South Wales, and the North of England, via our Manchester office. If you go to madetech.com/careers, you can find out more about that.
[Music sting]
Clare: A quick reminder that before the break, we were talking about how larger teams and larger chunks of software slow people down.
Matthew: The second team type is called an enabling team. An enabling team does not go on any software itself. It does not build any software itself. It’s a team of experts, it could be multi-disciplinary, it could be single-discipline. An enabling team helps stream-aligned teams to overcome capability gaps, to increase their knowledge in a particular area, to migrate from one thing to another, to adopt new practices and so on.
The enabling team will work with that stream-aligned team for a short period of time, days, or weeks, but not months and certainly not years. So, the enabling team never becomes a dependency, never becomes a crutch for the stream-aligned team.
Then the enabling team will move on to another stream-aligned team and then another and another and so on throughout the organisation, cycling round. The enabling team also detects common and repeating problems within multiple stream-aligned teams. Nine out of ten of these teams have the same problem around database migration, or around machine learning. We need to do something inside the organisation fundamentally, so we build a new machine learning capability, or we make it easier for these teams to access some kind of machine learning computation thing.
So, it’s a very distinct and different kind of team, the enabling team. It has a temporary relationship with other teams. It’s focused specifically on helping the stream-aligned team to improve their flow of teams effectively and safely.
The third type of team is called a complicated subsystem. This is where, if there is some aspect of the work that a stream-aligned team would be doing that is too involved, needs really hyper-specialist skills, like something to do with financial trading, something to do with video processing – typically something where a lot of complicated or unusual mathematics is involved. We are seeing, for example, that some of the machine learning stuff can work quite well as a complicated sub-system, but not always.
Clare: Yes, I was thinking about that.
Matthew: The key driver is thinking, is it reasonable to find the skills inside a stream-aligned team, and/or, would it be increasing the cognitive load on the stream-aligned team too much to ask them to take on this aspect of this computation?
If the answer is yes, then we might bring it into a complicated sub-system team, that might be the right thing to do. We are always driving that decision through the lens of a fast flow of change and limiting the extraneous cognitive load on the stream-aligned team. It’s through those lenses that we do that. We don’t just create a complicated sub-system, just because there is a nice little techy library that we can write. Which has been the approach in the past.
Clare: I imagine there might also be a danger there that the people in the stream-aligned team will be excited by something like machine learning and will see that as a new skill that they will be interested in learning. If you keep taking all that stuff away from them, then there can be a dissatisfaction that arises, that you are making us only focus on this one thing, and you keep taking the interesting stuff away from us.
Matthew: Well, if people have got that opinion, then they are free to go to another team. The focus should be on a fast flow of change. That is what we are trying to optimise for. We are definitely not trying to optimise for people’s CVs. We are not trying to optimise for keeping things interesting. We are optimising for a fast flow of change in the systems that we are building.
Clare: Okay.
Matthew: So that we can continue to adapt to customer needs at the highest speed possible, but still do it in a way that is compliant and secure. The danger in the past has been that lots of technology teams have just got involved in some really interesting technology but it’s not needed, and particularly now, with the speed in the change of technology, there’s a new cloud provider or a new software-as-a-service that is available to do exactly that thing.
Clare: Yes.
Matthew: There is machine learning as a service, now.
Clare: Yes, don’t reinvent the wheel.
Matthew: Well, don’t reinvent the wheel, but more specifically, use things like Wardley mapping to look outside your organisation at the ecosystem. Expect that there is going to be a SAS version of something around this product coming out in around 18 months, or even less, six months.
It’s because of this speed of change that we’ve got this inflection in the abilities from software that come about through cloud computing and through other things like this. Well, that requires quite a radically different approach to software development compared to certainly ten, and definitely twenty years ago. Where you could assume that you were basically writing all of your software in one language, you had a single database, you were deploying this stuff onto servers that you controlled and the world was significantly simpler, in that respect.
The dynamics now have to include what some people call FinOps or financial operations. Thinking about the relationship between software and the financial aspect and thinking about software and the changing technology ecosystem. If you want to be successful, your roadmap and plans and the way that you hire people, the kinds of skills and mentality that you hire for, has to be set up so that you are exactly expecting to replace your internal stuff with things that you pull in from the outside, on an increasing frequency.
That relates to the final of the four teams actually; what we call Platform Team. Which is really not a team type at all, it’s more of a grouping. Again, the platform only should exist if it helps to accelerate the flow of change in teams that use the platform and reduces the extraneous cognitive load on the teams that use it as well. That is its only purpose. It’s not about sharing licenses; it’s not about aggregating services. It’s a very different way of looking at what we ended up calling a platform. I don’t really like the word.
Its purpose is purely around accelerating the flow of change and reducing cognitive load. Inside the platform, you should expect people who yes, they might be specialists in doing something to do with machine learning, but the product owner around that machine learning capability is looking to the cloud. Going, hey folks, don’t invest too much time in this, we’re just going to buy this thing from Microsoft or Google in six months’ time.
So, you’re keeping the whole organisation nimble, avoiding investing in too many things which are of secondary importance to the organisation’s missing. Yes, building the things that are core, building the things that differentiate intellectual property, but not wasting time on stuff that is just heavy lifting and infrastructure grunt work. Or will be grunt work in about a year’s time. It’s the speed of evolution in the technology space that means we have to think differently about how and when we build something. Also, set up the dynamic internally that we are expecting to get rid of stuff that we’ve built. That’s a big ask, but it is the route to business agility, rather than being lumbered with a whole lot of internal stuff that is now basically no better, or probably worse than what is available on the open market.
Clare: Interesting. So, you’re not necessarily seeing the platform team as being a team that is building a platform. Is it more that they are monitoring the technologies that are being built, and kind of keeping an eye on what is on the horizon, thinking about what is going to be temporary and how you can make that work?
Matthew: That’s a nice way of putting it. So, from a team’s perspective, a platform can be literally – and I mean literally – a Wiki page that lists 10, 20 different services that a team should use. Those services are all built outside of this organisation. The platform team may not build anything at all. They might write absolutely no code at all, apart from some stuff to test things. What they’ve done is curated an experience for those stream-aligned teams, to enable them to use things in a way which actually works really, really well.
Clare: Yes.
Matthew: I mean that literally. A platform to me is absolutely not about writing loads of code. It’s not about building a load of stuff internally. It’s about shaping an experience for the stream-aligned teams, by reducing their cognitive load, but accelerating delivery of software safely.
Most organisations will end up building some stuff themselves, but the aim is always to build the smallest amount possible.
Clare: The interesting thing that occurs to me is that in building software, in my experience the biggest pain points are generally in the integrations. So, it’s the integration points with third party products that can create a lot of complexity. Absolutely I agree with you that it is not helpful to build things that already exist, particularly if it’s not a differentiator for your organisation. It absolutely makes sense to use things that other people have already built. But every time you do that, you create a new integration point. So, for me, I think, one of the jobs of a platform team is partly to think really carefully how to minimise the pain of integration.
Matthew: Yes. You’re going to get that irrespective of whether the software was built internally or externally, you’ve still got an integration point. Sometimes a good platform would abstract exactly where that service is being provided from. It shouldn’t really matter for those engineers using the eventual services, whether it is actually developed in-house or whether it is external. That to some extent is a good thing, you can swap it in and swap it out later.
Clare: I think that is probably where you come to the really important considerations when choosing third party products. One of the reasons it can be painful is if, for instance, the third party does not have good hygiene on their APIs, and they don’t provide good upgrade paths, they don’t have good version control. They don’t provide good visibility of upcoming changes. All of those things can create a lot of pain, if you are integrating against something and you suddenly lose an end point, for instance.
So, having some kind of confidence that you will be able to move fast because the people on the other end of that interface are also able to move fast and able to provide a good experience.
Matthew: That kind of engineering quality and developer experience becomes a fundamental decision criteria for whether you should go with that provider in the first place. Any signals coming from that provider which suggest that they have got version control wrong or that they don’t do API building properly – just run a mile. Go with someone else, because it’s going to really hurt things.
The really key point here is that for us, an internal platform is always optional. That sounds strange to some people but what it means is that stream-aligned teams have the option of building safe, compliant services themselves. They’ve got the option of building entirely their own infrastructure, entirely their own machine learning. If the product which is funding that stream-aligned team has the need to be independent and has the need to use something which is not yet provided internally, or maybe for which there is no plan to provide it internally, then that stream-aligned team will have to build it themselves or have to find some other way of doing it. That’s a good dynamic.
The idea of teams being forced to use a centralised platform is just one of the worst anti-innovations from the 1990s. The dynamic should be that the internal platform seeks input from the stream-aligned teams as quasi-customers and tries to make the developer experience so good that internal teams would like to use that internal platform, because it’s so good. That’s the right dynamic. They should never be forced to do it, because there will always be some team that has a need outside of that.
It’s also a great opportunity to separate the compliance criteria from the default implementation platform. So that everyone can see how to write compliant systems, code. Hey look, here’s a nice, really great default implementation in this internal platform. Feel free to use this, we’ll help you get on board with it. This is your quick route to being safe and compliant. If you have some other need, here’s what you need to do.
Then it allows the product to make the right kind of investment decision.
Clare: Yes, fantastic, wow. I’ve just noticed the time. I can’t believe that it has gone so fast. There was a bunch of other stuff that I was going to ask you, but there’s no time, so I am not going to. Instead, I’m going to go straight on to the questions that I ask all of my guests. The first one is just for fun, really.
Tell me one thing about you that is true, and one thing about you that is not true.
Matthew: I once walked 260 miles along the Pennine Way in England, well, from England into Scotland. I used hiking boots that were three sizes too big, which was pretty painful. But it was amazing. We did it in 16 days. I practise my trumpet for two hours each day.
Clare: Very good, I’m very impressed. The next thing, because we like to end on a high, what is the best thing that has happened to you in the last month or so? It can be either work-related or non-work related.
Matthew: I have recently persuaded an amazing person to join my company as an employee. She will actually be the first employee excluding me. I’m super-excited about that, I’m really looking forward to working with her. I think it’s really going to transform what I’ve been doing and how I’ve been doing it. I’m going to get so many new insights and opportunities with this person, so from a work perspective, that’s super-exciting.
Clare: Fantastic, which makes me then want to ask what is your company? What does your company do?
Matthew: My company is Conflux. As you can imagine, a significant chunk of the work that we do is around team topologies. Interestingly, not entirely. We’ve been doing a lot of work around reliability over the last 18 months. What is interesting is that the relationship between software reliability and the decoupling that we talk about in Team Topologies. I hadn’t kind of realised that when I was writing the book. So, we’re working with an organisation in the telecoms sector, with hundreds of hundreds of teams. We’ve been developing techniques to work across lots of these teams and reach 50, 150 people at a time doing workshops and things like this.
It’s been interesting to see this overlap between the reliability stuff that I’ve been working on for nearly ten years, and the team topologies through the decoupling and the architectural and organisational patterns that actually make an organisation more reliable and more resilient. That’s where we’re going with Conflux.
Clare: Okay. The very last thing is where can people find you? Do you have anything that you want to plug?
Matthew: Thank you, yes. Just find me online, go to MatthewSkelton.net. You will find there is a confluxhq.com. I’m on Twitter and LinkedIn and so on as well.
We have a new video course on our Team Topologies Academy. It’s called Platform as a Product. We’ll expand a lot on some of the ideas we’ve been talking about today around platforms and some of the dynamics there. If you go to academy.teamtopologies.com, I think there’s still at the moment a discount for signups, and there are group discounts as well for the people who want to send lots of people.
Clare: It’s probably worth me saying that the reason I wanted to interview you in the first place, was because a colleague of mine, Neil Vass recommended both your book and one of your training courses.
Matthew: Ah! Thanks Neil.
Clare: Thank you very much for talking to me.
Matthew: Thanks for inviting me.
Clare: Thank you for being here.
Matthew: Thank you, Clare.
[music sting]
Clare: As always, to help you digest what you’ve just heard, I’m going to attempt to summarise it.
As always, to help you digest what you’ve just heard, I’m going to attempt to summarise it.
The idea of Team Topologies originally came from exploring the relationship between development teams and operations teams, and how they could be more effective working together. Matthew and Manuel started out by thinking about responsibility boundaries. Then they started to think about software architecture, Conway’s Law, team cognitive load and adaptive organisations – specifically team interaction mode.
Ultimately, what they are talking about is helping organisations to have better conversations about how teams interact.
Matthew and his co-author Manuel Pais have come up with four types of team. There is the stream-aligned team, which I guess is the more traditional software development team, dedicated to building, testing, deploying, and running software in a live environment. It is important that they have end to end responsibility for the deployment of their products, to maximise the flow of change.
Then there is the enabling team. This is a team of experts helping the stream-aligned teams to overcome capability gaps.
Then there’s the complicated subsystem. These are people that are handling some aspect of the work that the stream-aligned team needs hyper-specialist skills for.
Finally, there’s the platform team, which isn’t really a team, it’s more of a grouping, and should only exist if it helps to accelerate the flow of change in the teams that use the platform.
They shouldn’t be wasting time on stuff which will be grunt work in about a year’s time. They should be curating an experience for those stream-aligned teams, to enable them to work effectively.
That’s not all. Stick around for extra content.
[Music sting]
Jack: Hi, I’m Jack, Made Tech’s Events Coordinator. Now, every other episode, this last short segment will be dedicated to Hack of the Month. Where one of our colleagues, and in the future, our listeners, will share a life or work hack. This month’s hack comes from me, on the benefits of taking cold showers.
This is something I discovered a while back and it is part of something called the Wim Hoff Method, that teaches that by incorporating cold showers into your day to day life, you can reap a wealth of benefits. For me personally, it helps with dealing with stress and anxiety.
Regularly taking cold showers introduces a small amount of stress on your body, which leads to a process called hardening. It’s almost like a form of weightlifting for dealing with stress. By incorporating a degree of controlled stress in a controlled environment, it helps to prepare the body’s reaction when faced with day to day stress and anxiety.
I know what you are thinking, that a cold shower replacing a morning hot one would be more stressful. I can assure you that nobody is expecting you to start diving into any ice baths anytime soon. Like weight training, starting small with 30 seconds at the end of a regular shower and focusing on your breathing, is more than enough to build on.
If any of our listeners fancy giving it a try, please let us know how you found the experience.
[Music sting]
Jack: Working in the public sector means that at Made Tech, we really care about making a difference. So, for this final Making Life Better segment, myself and my colleagues will be sharing suggestions for small things we can do to make the world a better place.
This week’s piece of advice comes from our Head of Marketing, Laura Plaga, who has some advice on the power of food in bringing people together. Laura, do you want to tell us a little bit more that?
Laura: Throughout my life, I’ve realised that whenever you are struggling to bond with people, food always helps. Things like eating together makes it much easier to form a deeper connection with people.
I personally love cooking, so when I was at uni or somewhere near and was struggling to create connections with new people, I would after a while invite people home for dinner, cook for them and that really helps in creating deeper modes.
Most of my friendships these days started with a meal. It’s something I would recommend to everyone.
Jack: I’ve got to ask; do you have a go-to dish for breaking the ice?
Laura: Well, depending on the season, my lasagne and tiramisu always seem to have lots of success.
Jack: Outstanding, I will probably be chasing you up for the recipe on that one. That’s brilliant, thank you very much, Laura, have a lovely day.
[Music sting]
Clare: And that’s the end of another episode. If you are enjoying the podcast, please do leave us ratings and reviews. It pushes us up the directories and makes it easier for other people to find us.
I’ve got a few talks coming up. You can see the details on my events page on Medium, which is linked to from my Twitter profile. You can find that @claresudbery, which is probably not spelled the way that you think. There is no I in Clare, and Sudbery is spelled E R Y at the end, the same as surgery or carvery.
You can find Made Tech on Twitter @madetech. Do come and say hello, we are very interested to hear your feedback, and any suggestions you have for any content for future episodes, or just to come and have a chat.
Thank you to Rose our editor, Gina Cady our virtual assistant, Viv Andrews our transcriber, Richard Murray for the music – there’s a link in the description, and to the rest of our internal Made Tech team. Kyle Chapman, Jack Harrison, karsyn Robb and Lara Plaga.
Also in the description is a link for subscribing to our newsletter. We publish new episodes every fortnight on Tuesday mornings. Thank you for listening and goodbye.
[Recording Ends]
Back to the episode
