Designing your org for fast flow of change with Matthew Skelton

Episode transcript

Rob Zuber: Hello, and welcome to The Confident Commit the podcast for anyone who wants to join the conversation on how to deliver software better and faster. (singing) Today you’re listening to Episode Seven. I’m talking with the co-author of Team Topologies, founder of Conflux Matthew Skelton. I’m your host, Rob Zuber, CTO of CircleCI, the industry leader for all things CI and CD. Hey, Matthew, welcome. Thanks for joining me.

Matthew Skelton: Hi, Rob. Good to be here.

Rob Zuber: Awesome. Well as we’ve discussed before this, but for everybody’s who’s listening, I’m a big fan of the book Team Topologies. We use it as we think about organizational structure here at CircleCI. I would also say that multiple times on this podcast, it’s come up. Not by me, maybe sometimes by me. I’d actually have to go back and check, but certainly by guests saying, “Oh you should go read this book.” It sort of comes up everywhere now. So congratulations, I guess, first of all-

Matthew Skelton: Thank you.

Rob Zuber: … for hitting on something that was so important to so many people. And I would say I talked about this a lot. I think one of my favorite types of books is something that gives names to things. Patterns that maybe we’ve seen, but really sort of crafts them into patterns, and gives us a way to talk about things more concretely and consistently. Because sometimes we’re doing the same things in slightly varied ways, or whatever, and we’re talking about them. And it’s just like, the conversation is hard, the language is hard, and therefore getting the concepts across becomes hard.

And so I’m curious, I mean, to me, that’s a really exciting outcome of this. But what were the drivers? I mean, what led you to… Well I guess you and Manuel to write the book? Was it any of that? Was it patterns and practices that you had seen and were trying? Like, what was the motivation between putting all this down or behind putting all this down on paper?

Matthew Skelton: That’s a really good question. The motivation, to some extent, if I’m really honest, is sort of frustration. Because we were ourselves experiencing kind of, I guess, frustration inside teams. When there’s ambiguity about purpose and kind of focus for different kinds of teams we were working on. And both Manuel and I, by the way, our backgrounds are software development, but we worked in all sorts of different parts of software delivery.

And we both worked in the kind of CICD space. I mean, going way back to my first job, I put in a very early distributed version control system, in a company back in 2001. So this is before SVN even, well before Git. And I’ve been doing that kind of thing, pretty much every role, I’ve been thinking about the sort of practices around source code and what eventually became CICD. So we’ve been in that space for a long time.

And of course, if you’re working in that kind of CICD, what’s now called CICD. That’s the heart of software delivery. You get to see all of the pain, if you like. All of the nice stuff, but you get to see all the pain as well. And I guess a lot of our experience came out of working in the middle there, seeing all the different interactions with different kinds of teams and the way that technology interacted with teams and so on.

The opportunity for deployment pipelines to be a very rapid way to get things deployed. But also we’ve seen plenty of situations where deployment pipelines are incredibly slow and take even days or sometimes weeks to go end-to-end. And so we’ve seen lots of stuff firsthand is the short version.

But we wanted to kind of combine that with you could call it a kind of reverse engineering of what other organizations were doing. So lots of people have heard of the phrase two pizza team in relation to Amazon. And that’s something that they did a few years ago. In other words, that the size of their teams was no bigger than could be fed by two pizzas. That sounds kind of a bit flippant. But actually behind it and behind some of the other key Amazon Web Services principles are some really important kind of decisions and fundamentals that have helped them scale, that have helped AWS scale massively. Particularly around keeping teams substantially autonomous and decoupled from other teams and presenting a kind of interface out to other teams and so on.

It wasn’t just Amazon there’s plenty of other places that have demonstrated some really interesting practices. So I wanted to do is to bring our own experience, reverse engineer some practices that are out there, that seem to be working really well. But also look at… Have a future looking thread as well. The future looking thread of course, is a fast flow of change because increasingly organizations that… All kinds of organizations are using software to differentiate themselves from the competition and to make sure they stay ahead in the market. Or to be able to provide Citizen Services more effectively if you’re working in government context.

And so fast flow of change becomes absolutely essential. Of course, as we know, from a CICD perspective, the deployment pipeline is the kind of the way that we get that. And that is really at the heart of any software delivery effort. But it’s not just about having some CICD in place. The shape of the teams, and the interactions and so on strongly influences how effective we can be at delivering software on an ongoing basis, particularly at scale.

And so we took this as a starting point. What would happen if we optimized our organization for fast flow of change? And it turns out that for some organizations, or they’re already doing it, they might not have characterized it like that before. But that’s effectively what they’ve ended up doing is optimizing fast flow of change. Yeah, Amazon as well, and there’s loads of other companies that are in a similar place.

But many, many companies and organizations are very far away from optimizing for a fast flow of change. So they optimize for something else. And so that’s how we ended up coming out with these kind of patterns, different kind of team patterns. Thinking about what’s the bare minimum set of things that we really need to sort of define, to effectively have a set of useful behavioral constraints, definitions and constraints on our organization delivering software. Because it helps us to talk and reason about what we’re doing better, if we’ve got things better defined, and kind of templated like that.

Rob Zuber: Yeah, got it. That totally makes sense. I think that whole notion of just, I’m seeing it, I’m seeing patterns, I’m sort of extracting it, and then finding a way to talk about it. But to the point of so many people bring it up in all these different contexts. It just makes that whole conversation so much easier. To then say, “Oh, okay, this is a platform team, this is an enabling team.” Whatever, or even the notion of stream-aligned. I think that plenty of people have different names for that concept. And just to be able to say, “Okay, this is kind of in a bounded context, ubiquitous language point of view, this is the way we’re talking about this right now. Great, we’ll use these terms. This is what we mean.” And to have that agreement makes the rest of the conversation so much easier.

Matthew Skelton: There’s actually an interesting quotation from someone called Eduardo Silva. And he suggested that Team Topologies is actually a kind of domain specific language, DSL, for organization design. Certainly in a software context, and probably outside of software context, as well. And that’s kind of interesting way of looking at it. A DSL, so it’s specific terminology and ways of putting this stuff together that helps us to get to the… Helps us to solve problems more quickly, effectively. And I like that kind of way of thinking about it. It was nice to see someone see it in those terms.

Rob Zuber: Yeah, that makes a ton of sense. And I think the thing that you kept raising in there, the fast flow of change, I think it is what many people are striving for. You said some are optimizing for other things. Some are definitely optimizing for other things intentionally, some are optimizing for other things, because they’re not seeing the possibilities. And it’s really interesting to think about just how impactful the organization is in that. We’re tool vendors. So clearly, people come to us asking the questions, how do I use this tool? What can I get from this tool to deliver software faster? And we absolutely want to enable them.

And I think sometimes they sort of look at us funny when we start talking about their organizational design or other things that all of these pieces play together? Is the culture going to support it? Is the organizational structure going to support it? And if not you can move a little bit on the tooling piece. But you’re going to find that you have to move all of these pieces together to really get the maximum results. And so interesting that you actually talked about being focused on source control and CICD as a driver to end up in this space.

So as you both are an author, but also someone who consults and helps teams improve, do you find that you spend kind of an equal balance of your time on these different facets? It’s not just about organizational structure, it’s about tool choices and culture and what other things really come up often for you as you try to help people deliver that fast flow of change.

Matthew Skelton: Sure, totally. And so, obviously, at the moment I’m spending a lot of time talking kind of going through Team Topologies’ principles. But yes, there are some other important things. The relationship between teams or the relationship between kind of humans and tooling is an important one. I gave my first public talk on that back in 2015, I think. I’d been thinking about it for a couple of years before that. Which kind of relates to Conway’s Law or sociotechnical mirroring. Kind of communication pathways inside the organization can be shaped by tooling, can be enabled or disabled effectively, or hampered by tooling.

The classic one is where the software development team has got one kind of way of tracking issues and bugs and the operations team looking after the live environment has got a separate tracker. And so those two different sets of tools are kind of driving some different behavior and that kind of thing in the organization. So that’s a really obvious example.

But I’m interested in this relationship between technology and groups of people. So definitely tool choice. And the way in which you use a tool is massively important. The tool itself can be relatively neutral, but the ways in which is deployed in use and the way in which access is granted to it and different kinds of roles and so on can have a massive positive or negative effects on how well that tool is received. So I do a bunch of stuff around that.

Interestingly, more recently, over the last year, we’ve been helping a large telecoms company in North America to get to grips with reliability, software reliability. But increasingly bringing in so the liability angle is around things like SRE, Site Reliability Engineering, but also just fundamental principles around operability, testability, things like that. Helping the teams and product owners and so on to understand how to do that, how to get to grips with an approach to help make the software more reliable over time.

But of course, it turns out that Team Topologies can help too. And a combination of Team Topologies and kind of reliability engineering then starts to get quite interesting. For example, if you take the time to decouple teams and their services and software, then there’s an opportunity to make those services and software more reliable. Because they’re less interwoven, they’re less kind of accidentally coupled to other things. And so the failure modes are a little bit easier to define, and so on.

So there’s some really interesting work I’m doing at the moment around the relationship between some of these more technical disciplines and the patterns and principles from Team Topologies. And so far, we’re super pleased that they’re working super well together. And being able to take those two things hand in hand, the organizational side, and the technical side seems to be a really, really useful, really positive thing for the organization’s we’re helping them on.

Rob Zuber: Well, that’s a very cool example. And one of the interesting questions that we’ve been discussing internally and sort of our own application is around SRE and sort of the overall kind of model of Site Reliability Engineering, and kind of how much of that is platform versus enablement. If that’s like two different types of disciplines within the overall umbrella of SRE. So as you’re trying to apply it, how are you thinking about that in terms of… And maybe you should give a little bit of a definition of those terms for people who haven’t read the book, although you should. And you could probably… Anyone listening could get a quick brief pretty quickly, but give a quick overview of those two terms, and then how you think about SRE within that.

Matthew Skelton: So for us a platform is a curated experience for engineers that are using the platform. And the platform is focused on enabling a fast flow of change in teams are using it and reducing cognitive load inside those teams using the platform. It may have some technology in there, it may just be a wiki page. But the key thing is on fast flow and reducing cognitive load. And an enabling team is a team that mentors… A team of experts that mentors and helps other teams to become more effective at a practice or to adopt a new technology, or to bridge a capability gap for a few weeks. Let’s say they’re moving one database or another or they’re adopting a new way of working or something like this.

But the enabling team doesn’t build and run anything itself. And so fundamentally, let’s say we’ve got a set of stream-aligned teams. Some people might call these product teams or some people call them DevOps team, end-to-end, with a kind of full end-to-end responsibility. The key thing there is these stream-aligned teams have end-to-end responsibility for a particular service or product or the part of the system. They’re on call for the service.

And so they got very fast flow change, there’s no handoff to any other teams, and they see what’s happening in production. And then in the Google SRE model, the starting point is what we call a stream-aligned team. Google call it something different, but it’s effectively a stream-aligned team, that’s always the starting point. And if the service gets more usage, and starts to see many, many thousands of users using the service, then you’ll start to see some interesting reliability problems. Just because if something only happens in 1% of cases, as soon as you start to hit thousands of requests per second, then you’ll see that kind of every day or every, every couple days, whatever.

So then you need some help from some people with strong reliability engineering expertise. In the Google model, initially, those SREs act in a kind of a consultative way in what we would call enabling teams. At Google only when a service or application becomes massive scale properly, massive Google scale does the SRE team, take on some of the kind of runtime responsibility for that thing. And it’s worth noting that’s a response to Google’s massive scale. Most organizations would much better benefit from just taking the first two approaches.

That Google talk about, which is the starting point is always a stream-aligned team. Always, always, always it’s product owner that should have the responsibility for the runtime success of that software. And be on the hook effectively, for how well our software works in production.

And then, at certain points, if there’s some tricky situations, or some things that that stream-aligned team doesn’t really know about in terms of reliability, then they should get some help from some reliability experts. Now, of course, that might come in two flavors, as you’ve just identified. It can come in the form of an enabling team, a team that comes in and mentors or helps that stream-aligned team for a short period of time. Maybe it’s like two weeks, maybe it’s more slightly more than. A month or so.

As I’m doing some complicated migration, or they’re dealing with some really awkward performance problem, say. So that’s one model for kind of SRE and for most organizations, is enabling team. But of course, that enabling team might detect that 9 out of 10 of the stream-aligned teams have got the same problem, they got the same gaps, they’re struggling in the same way, with this kind of performance thing, whatever it is.

And so they say, “Well, actually, wouldn’t it be great to have something that these stream-aligned teams can consume from let’s say, something that looks like a platform? That will make all of our lives easier if this thing was somehow simplified and packaged up into an API that they could all just consume?” And so you’ve always, always, always got this dynamic, in a Team Topologies context between enabling teams and a platform, there’s always a dynamic there.

And it’s asking the question, or trying to say, our SREs should all be in the platform or our SRE people, Site Reliability engineers should all be enabling teams is sort of the wrong way of looking at it. It’s a dynamic. There will be need for some Reliability Engineering inside a platform to help stream-aligned teams. And there will be a need for some reliability experts to mentor stream-aligned teams but at different points. And that changes over time, depending on what’s happening. In the software, in terms of how users are using it, you should expect basically these two different roles to kind of be fluid or flux between them, depending on the needs of the organization.

Rob Zuber: Yeah, that totally makes sense. And I like that sort of lifecycle view of it to think about, exactly, starts within the stream-aligned team, which is primarily how we work. And then we also have very platforming components that people build on top of. But in between that, hey, you need a little bit of help here, you need a little bit of help there. Oh, look at this pattern that’s coming out, when we can turn that into a platform piece. I think that lifecycle model is an important thing to overlay to kind of make those pieces make sense. That’s really cool.

And I would say another thing in there, and you talked about kind of helping out for a couple of weeks, and then maybe handing off some of that… Not handing off the knowledge, but building up the knowledge, mentoring and building up these teams to the place where they had that stuff built in. A huge part of the of the book and the model is focusing on not just the teams, but the relationships between teams, how they work and how they coordinate. I mean, was there sort of an aha moment behind that. That feels like the key insight almost, more than even the teams themselves. What led to that? I mean, you mentioned Conway’s Law a little bit. But was there something kind of behind focusing on that relationship piece?

Matthew Skelton: Yes, that’s a really, really good point. And I’d agree with you, I think the four different team types are kind of a distillation of some stuff that’s already out there. We put new names to things, I think the names are helpful. Because they’re a bit clearer that calling it, say, a product team. Product has two different meanings.

So the naming that we gave to the different team types was I think useful, but the team interaction mode is genuinely new. That’s something that basically didn’t exist before we wrote the book, as far as we’re aware. And there’s something we’ve been… I mean, we’ve been thinking about it for a long time. I’ve been thinking about it since… I mean, I wrote a blog post in 2013 that was kind of the genesis of some of this kind of thinking.

Some of that early work was used by companies like Netflix and Conde Nast and companies like this, to help them think about their teams. It was working through it in different organizations, private sector, public sector, governmental is what I mean. All kind of different organizations and being inside teams and working with teams and listening to the kind of conversations they were having. And the kind of confusion that was arising because people didn’t know what kind of relationship they should expect with another team.

They were frustrated working with other teams, they say, “They’re really slow, or we’re always waiting on them.” It was super clear to us that there was in the industry, a general lack of a way of kind of talking about the relationships between teams, when we’re building software. It just kind of wasn’t really there before that. And so part of the motivation there was kind of genuinely from the point of view of trying to try and make building and running software systems a bit more like humane, if you like, a bit nicer for people who are involved in it. Because we’ve seen the frustration firsthand.

But also, when you’re looking at systems, in general, and particularly complex adaptive systems, which is what an organization building software really is. The behavior of systems is normally defined or strongly influenced by the relationships between different parts, not by the parts themselves. And so fundamentally, we wanted to have some definition and in fact, it you can see the team interaction modes as enabling constraints in a complex adaptive systems sense. We’re deliberately kind of constraining the kind of behaviors between these different parts of the system in order to be able to reason about it better, and to get some way of better being able to dance with the system if you like. It’s partly from a kind of pragmatic point of view, but also partly deliberately, from a kind of more theoretical point of view around complex adaptive systems.

Rob Zuber: Yeah, that’s a really cool way of thinking about it. We talk a lot about cognitive load, you mentioned it earlier in a different context. But we tend to think about it in systems. I’m isolating you from these other parts of the system, so that you can reduce your cognitive load and focus on the parts that matter to you. And organizationally, you’re sort of applying the same principle, which is like, you don’t need to worry about what these other teams are doing. You understand your systems, and you understand these teams. And that’s what you can think about. That makes a ton of sense.

So let’s talk on the SRE front or on the reliability front, you said it all starts with a stream-aligned team. So let’s talk about stream-aligned teams for a second, what is critical to the success of a team stream aligned team. Not a team aligned… Stream-aligned team? And how do those teams know when they’re succeeding? I mean, if you were working in a stream-aligned team, how would you be thinking about your success?

Matthew Skelton: Great question. Critical to the success of a stream-aligned team, there’s multiple different dimensions. One, they need to have end-to-end responsibility, end-to-end ownership of a service, application, part of the system. And end-to-end we mean, at the very least from the very close to people who are defining the roadmap for this thing that we’re building, and they write the code, they test it, they deploy it, and they run it in the live environment.

So that’s what I mean by end-to-end rent responsibility. They’re on call. They’re watching what happens to that code in the live environment and they’re able to make changes. They’ve got the autonomy and not just permission, but they’ve got the context, be able to make the changes to fix whatever that problem is. Very, very rapid feedback loop. So typically, there’s going to be a mix of skills in there and the mix of skills very much depends on what they’re doing. A team that is responsible for some kind of website booking flow, they’re going to have some kind of web engineers in there, and maybe a bit of database and a few other things. But a team that is building and releasing a machine learning model will have a different set of skills. The key thing is they’ve got enough mix of skills in that team to be able to own that thing end-to-end.

But it’s not just about the skills and the end-to-end ownership, we need to make sure that the alignment of responsibility around that team makes sense. This is where techniques like kind of domain driven design and things like that come in where we’re thinking about business concepts and kind of untangling business concepts. Even before we started to write code, what happens in many organizations is the different kind of business concepts are kind of mashed together or tangled.

And therefore the software that gets produced is also tangled. Because from a logical business point of view, these things haven’t been sufficiently well separated. And it’s absolutely not surprising that the code we generate is also tangled, because code is literally encoding of business intentions. That’s really all it is. Nothing more than that. So if the business intentions are clear, the code can be clear. If the business intentions are really muddled, and they’re kind of twisted together, it’s very, very unlikely that we’re going to get nice clean code out the end.

So we need to make sure that the kind of application or service or thing that team that stream-aligned team is responsible for is, if you like decoupled in a way which makes sense for a fast flow of change. It’s no good just choosing arbitrary kind of… Just splitting something up in an arbitrary way. If those split points don’t align nicely to a nice flow of change that makes sense from the business perspective. Because we’ve got to do work, we have to do work on finding good boundaries, to enable flow of change from finding good boundaries that are aligned to sensible flows of change, basically.

Rob Zuber: I mean, I think you said product is a word that gets used for too many things. We talked about autonomy and software teams, it’s another word that gets used too broadly, I think, but the ability to say, “Okay, we can deliver real customer value within the bounds of our stream, therefore, we can make the changes and we can get those in front of customers.”

Matthew Skelton: Yep.

Rob Zuber: So I asked the question of how you would know you were succeeding, but now I’m a little more interested in the question of, do you have a good way of measuring and or identifying how well that’s working? What is the sign or symptom or number, whatever it might be within an organization that you know what, we haven’t carved up the system in an effective way? What are the indicators of that?

Matthew Skelton: Really good question. So the indicators we want to use are around flow. So we can use kind of standard flow metrics, we can use the four key metrics from accelerate as a nice starting point. Which also has a focus on how well the software is kind of running or how well our changes end up working in the live environment. So lead time… Sorry, lead time, deployment frequency, mean time to restore and change fail percentage are those four key metrics from accelerate, but we also add in a fifth one, which is flow efficiency.

So it relates to lead time, but flow efficiency effectively is the proportion of time spent doing actual work rather than waiting other people. Because it’s that waiting, which really kills flow. And apparently, in loads of organizations, the typical flow efficiency is 15%. So 85% of the time teams are spent waiting on other teams, it’s just astonishing, and massively, massively wasteful.

And so actually looking at flow efficiency and trying to improve that and trying to remove the wait times, and trying to improve the wait times is a kind of value stream stuff, value stream mapping. Remove those wait times, work out why these dependencies are in place and put the effort into, decouple and remove those dependent… Decouple them in terms of blocking dependencies. We’re looking to turn those blocking dependencies into non-blocking dependencies. All software depends on something else. We’ve got a whole chain of dependencies. But if the dependencies are non-blocking, then we just consume them as a service and move on. So we’re not blocked by that thing.

Rob Zuber: And just to clarify-

Matthew Skelton: That’s an important distinction, basically. Be aware that we’re going to have dependencies, but we need to be looking to turn them into non-blocking dependency, so we can just consume them and have a nice fast flow chain.

Rob Zuber: So things flow. Now, just to clarify, when you talk about that 85%, sort of wait time. Is that the unit of work is waiting, or people are actually waiting? I’m assuming people aren’t working 15% of the time and the rest of the time sitting on their hands, because they’re waiting on something from someone else. But I’m prepared to be terrified.

Matthew Skelton: So it depends on what the work looks like. But it’s quite astonishing how much time these team actually end up spending waiting. And so the danger course, if you have a team that kind of starts doing something, and then if they have to hand it off to another team to get tested, or deployed or something, they start work on something else.

So their work in progress goes up. And all the stuff we learned from lean, just then kind of goes out the window. And so we’ve got massive high work in progress, we’re always chopping and changing multiple things, we do not have a nice, high throughput. And so we can look at those metrics too, look at things like working number of items, work in progress, compared to the number of people in the team and so on.

It’s a rough but useful indicator. It’s also worth looking at the number of blocking dependencies, basically, the number of other teams that we are waiting on, either right now, or we expect to be waiting on soon. Because that is a leading indicator of problems with flow. Just looking at the number of teams we’re blocked on right now or number of teams that we expect to be blocked on soon. That’s the leading indicator, we want to take leading indicators wherever we can. And putting actual effort, so architectural effort, if you like, into decoupling teams so that there can be a faster flow.

So the short answer is typical flow metrics around flow efficiency and those four key metrics from accelerate, and looking for opportunities to turn blocking dependencies into non-blocking, and really putting the organizational architectural effort into doing that decoupling is really, really key.

Rob Zuber: Makes total sense. It certainly gets you to that stream that end-to-end stream of just, I can own a thing, I can decide to do it, I can get into production that’s obviously the perfect model. Every once in a while there might be some dependency on other teams. But I think it’s a great way to combine those two things. We unsurprisingly, think about the metrics from accelerate a fair bit and talk about them. And we have looked at our own customers and where they land, it’s been interesting for us because unsurprisingly, folks that are doing CD tend to be in the top quartile.

When we look at the overall spectrum, it’s not like we’re seeing people taking a month to ship something into production when they’re using our platform. So it feels like within that we need to start to… It would be interesting, I don’t know if we need to, but it’ll be interesting to start teasing apart that upper echelon, if you will, and see what the behaviors are that allow you to get better and better and better.

One thing I’ve been thinking about a lot lately, and it doesn’t necessarily specifically tie into this, but I’m curious for your perspective on it, is then your once we know that the machine is working we have good flow, we’re moving things through we can recover quickly, we deploy regularly all of those pieces. We know that we’re moving units of code. But we don’t necessarily know from any of those things, that we’re moving the right units of code, if that makes sense. We have the ability to get faster feedback, so there should be good and ciliary effects. But how does that then tie into how we think about making sure we’re doing the right things? Is there a next evolution of all of this that’s like, look, we’ve optimized the machine, the factory floor. I hate calling it that, but let’s use the metaphor for a bit because we’re talking about flow. As much as possible how do we make sure we’re shipping the right units, the most valuable thing and put that out into our customers hands. Is that a different discipline? Or is it really layered into all of this?

Matthew Skelton: I think is strongly related. I mean, part of it is a need to move away from this traditional feature factory, sort of disease that the industry has. Which is “Hey, the more features we ship, the better is for our users.” Which is complete nonsense. Users don’t want features, new users want a great experience, and have come to expect it. And more features does not mean a better experience. And just because users are asking for it, “Oh, we need this feature.” It doesn’t mean it actually is what they really want.

They’ve got… What they really might actually prefer if you presented it to them is a simplified experience, which just works better. And then they don’t even need that thing that thought they needed. That might have been a workaround, in order to get to work around some other kind of crappy part of the software, which they don’t really like anyway. So I think moving away from a feature factory is going to really be the next kind of step. It’s not just about shipping stuff and then moving on. It’s about seeing a change in perspective.

So hey, we got to put something in production into production. And that’s just a hypothesis, it’s just a guess, do we even know whether this is what our users need? And a super tight feedback loop in there, and then that enables product teams or stream-aligned teams or whatever to say, “Actually, this thing goes wrong, this is the wrong thing to do. And the data is telling us that.” So basically, a kind of honest, data driven approach to experimentation with trying to meet user needs in a way, which uses the minimal amount of code, the smallest amount of code that meets user needs.

And that’s pretty far from where lots of organizations are right now, where they think, “Oh, if we just got faster and faster and faster, then we’ll be able to ship more stuff.” So it’s a kind of mindset change, I think, and then the organizations that manage to get this, because they have less code in play, they ought to be more nimble, because if they need to make a massive change, if the industry shifts, if something like COVID comes along, or massive floods or changes in international trade agreements, or whatever comes along, you suddenly have to make a big switch from one way of doing things to another.

If you’ve got less code in flight, you’ll be able to do that more easily. And so to me, that feels where the kind of software industry… The next big discipline will arise around that. I mean, it’s happening already, there’s organizations doing it already, and have been for many years, but there’s still so many organizations that just think if we only just got faster and shipped more stuff, we’d be in a better place. And it’s just the wrong mentality.

Rob Zuber: Yeah, I think you’ve highlighted such an important idea and expressed it really well in there. So I’m going to try to play it back just so we don’t lose it, which is there’s all of this optimization around flow and delivery, which you can think is just for the purpose of getting the same things out faster. But when you ship in small increments, and get those pieces into the hands of customers, you learn faster, and spend less time building waste, basically, and can adapt faster to those changes.

And so you have much more targeted delivery. So it’s actually a compounding effect, I guess. Because you get those targeted pieces delivered much more quickly. And that is where we all want to be, I think, but not everyone knows that even we can get there. That’s a really cool way of thinking about it.

And I will just repeat and plus 1,000, or whatever you do verbally, the less code is better. Less surface area for bugs, less surface area for security issues, lower cognitive load, ability to change. I was just talking to someone earlier today about the whole concept of counting lines of code. And just how absurd that is. I mean, yes, we should measure lines of code and be optimizing the other way. Not in the Can I fit 17 semicolons on this line of C where every variable is one character, not in that view. But how simply can we express this? And how much can we tighten it down and not write our own stuff, because that gives us the space to move quickly to adapt, to understand it. For someone new to come in and say, “I see exactly what this is doing.” And I can change it or whatever. Cool. So what are you working on next? What are you excited about now?

Matthew Skelton: So, what’s happening? Some really interesting things that are coming on that is this combination I mentioned before of using the Team Topologies patterns, but also a bridging into other areas. So I revisited some sort of my kind of past experience around CICD. And looking through that lens CICD is at the very center of an organization’s capability to have a fast flow of change. And it’s such a good thing that Jez Humble and Dave Farley put together in the Continuous Delivery book from 2010. It’s a gem. And it was really foundational, it’s absolutely at the core of any organization’s ability to do any of this stuff.

And what’s interesting is that many organizations now, don’t… They think that they know what it is. But they’re not adopting… They think it’s just a tool, effectively, they’re not adopting the practices. Kind of based on what you were saying before. It’s not just about buying a tool and everything will just be magic. I mean, there’s a lot of magic in tools like CircleCI and things, that’s for sure. Completely amazing, compared to like 10 years ago.

But it’s not just about that. It’s about how the tool’s used, it’s about how it fits into the organization, about your decisions about who defines the flow and pipeline, who can change it and so on. All of those decisions will have a massive impact on how effective that kind of practice is. At the same time we’re kind of looking in the other direction. And looking to… We’re starting to have a conversation with organizations who are using Team Topologies outside of IT or technology or software.

Still within organizations that are in this kind of space, but they are applying into kind of the legal department, HR marketing, what have you. Those other departments. We are actually now looking at… Having some conversations where people in research and development R&D are using Team Topologies, effectively. So we thought that Team Topologies would maybe not work in R&D, but apparently it’s working fine and really helping them, which is kind of cool.

So that’s in an engineering organization, particularly, but there’s also… We’ve got some stories from like pharmaceutical and healthcare and so on, as well. And we think that’s around the kind of clear team definitions that’s really helping in that space. Because a flow of change is not necessarily so relevant there. Team Topologies is also moving into a government context. So we’ve got in North America, and multiple places in Europe, governments starting to adopt Team Topologies, and finding a very useful for kind of Citizen Services. So that’s kind of interesting.

And we’re starting to kind of codify, pull together, I don’t really like the word productize. But anyway, codify some of our kind of experience around this into sort of acceleratory things, things that help to accelerate people’s awareness and sort of workshops and so on that really help people to get to grips with some of these things quite rapidly, starting from their own context.

Rob Zuber: Wow. Well, that’s a lot of application. I was actually, as you were talking about that, was wondering. So I don’t know if I’ve ever mentioned this on this podcast or to you personally. But my very first job, I worked in a factory. It was a manufacturing facility, and that’s where I actually learned about Kanban because we called the trays Kanbans, but I think that’s not technically correct. But they had just built this huge warehouse and then converted everything to just in time, it was very fascinating. But anyway, I sometimes wonder if all of this exploration that we’ve done that was manufacturing influence 20 years ago, in software has made its way back to engineering, or sorry, back into factories.

Matthew Skelton: It’s going there now, for sure. Yeah.

Rob Zuber: Because a whole different discipline has put all of their time and energy into thinking about a metaphor that they stole. And it makes me wonder have we just totally changed it? Or are there things that could then be fed back? Because you were talking about how it’s being applied in these other places.

Matthew Skelton: So you should look at the talks by Mik Kersten, who’s the author of Project to Product. So his book is published by IT Revolution, which is the same publisher who publishes Team Topologies. Basically, any book from IT Revolution is great, they published Accelerate and DevOps Handbook and all these kind of books.

So Project to Product, one of the one examples that Mik Kersten talks about is the BMW factory in Germany, which is basically kind of software configurable, if you like. And it’s starting to take some ideas from what’s going on in software space. Toyota is actually leading the way there, they have a factory in Japan, which is programmable. They can program the factory to change the factory floor layout, and therefore very, very rapidly produce a new car or whatever it is that they’re building.

So yes, some of this stuff is coming around. I actually was on a… Well, sorry, next week, I’ll be on a call with companies that are primarily around retail and distribution and manufacturing in the UK. And so there’s interest there. Certainly, in the UK, I mean, it’s going to be further afield as well from companies that increasingly are using softwarey type techniques, using software to help them do all this stuff. And therefore looking to software principles, to help them organize and prioritize stuff. So yes, it does feel like it’s kind of coming in a kind of full circle learning loop again.

Rob Zuber: That’s cool. We’re paying manufacturing back a little bit from the software industry for everything that we-

Matthew Skelton: Stole.

Rob Zuber: … Stole. [crosstalk 00:44:43]. Toyota in particular is a great example. I mean, used in so many stories of all this background. Well, cool. Thank you so much for joining me today, Matthew, it’s been such a pleasure to talk to you. Thank you for all of the work that you and Manuel put into putting this out there. As I said, I hear about it Everywhere. So clearly it’s landing and people are able to improve and do better work as a result of the effort that you put in. So really appreciate it.

Matthew Skelton: That’s great, thank you. It’s great to be here. I love talking about this stuff, as you can tell.

Rob Zuber: Yes, yes, I can tell as do I. So it’s perfect. Well, thank you. Thank you again, so much. Thanks to everyone for tuning in today. If you enjoyed this, share with your friends, sign up, register, find it on all of your podcast platforms. And if there’s something in particular, you want us to talk about, someone you want us to talk to reach out on Twitter at CircleCI. And join us next time. Thanks again to everyone for tuning in. And thanks again, Matthew.

Matthew Skelton: Cheers, bye.

Rob Zuber: Bye.