Software Delivery in Small Batches

Matthew Skelton & Adam Hawkins discuss concepts in "Team Topologies" and inflection points in team and software architecture.

Show Notes

Adam welcomes Matthew Skelton to the show. Matthew is co-author of the book "Team Topologies" and a DevOps Enterprise Summit speaker. This episode builds on the previous podcast introducing the team types and interaction models.

Adam and Matthew discuss the first principles in Team Topologies, building internal platform products, and the impact on software and team architecture. 

Adam's Links
Matthew Skelton's Links
ā˜… Support this podcast on Patreon ā˜…

Creators & Guests

Host
Adam Hawkins
Software Delivery Coach
Guest
Matthew Skelton
Co-Author of "Team Topologies"

What is Software Delivery in Small Batches?

Adam Hawkins presents the theory and practices behind software delivery excellence. Topics include DevOps, lean, software architecture, continuous delivery, and interviews with industry leaders.

[00:00:00] Adam Hawkins: Hello and welcome. I'm your host, Adam Hawkins. And each episode I present a small batch with theory and practices behind building a high velocity software organization. Topics include dev ops, lean software architecture, continuous delivery and conversations with industry leaders. Now let's begin today's episode.

[00:00:26] Adam Hawkins: Hello everybody. Welcome back to small batches. Today. I am speaking with Matthew Skelton. I think this will be the last time that I directly discuss team topologies on the podcast. It's a really important book in my opinion, super important topics and approaches to team architecture and the role on software delivery.

[00:00:49] Adam Hawkins: So today I have Matthew Skelton on the show to discuss his book. Let me read off his official. Matthew Skelton is the author of team topologies, organizing businesses and technology teams for fast flow. He is recognized by tech beacon in 2018, 2019 and 2020 as one of the top 100 people to follow in DevOps, Matthew curates.

[00:01:15] Adam Hawkins: So well-known DevOps team pathologies patterns devopstopologies.com. He is the head of consulting at conflicts and specializes in continuous delivery, operability and organization dynamics for modern software systems. So I invited Matthew on the show to gonna close out the discussion around team topologies, kind of take a retrospective look on how has team typologies been applied in the.

[00:01:44] Adam Hawkins: What are some of the inflection points when teams are growing in, like when maybe different typologies make sense versus them don't and really just a high-level discussion about the importance of team topologies. So with that, I'll give you my conversation with Matthew Skelton.

[00:02:04] Adam Hawkins: Matthew welcome to small batches.

[00:02:10] Adam Hawkins: Thank you, Adam. It's good to be here.

[00:02:11] Adam Hawkins: Well, it's my pleasure to have you, I'm actually really excited to talk to you today because of just been discussing team typologies a lot on the show and also get my full-time job, I think it's really relevant to all of the work that we do as engineers.

[00:02:24] Adam Hawkins: And it's sort of the topics discussed on the show. So I invited you on here to kind of bring the conversation back to an area that I don't, I haven't really heard it discussed so much, which is. We have the ideals put forth in the book that there's these different team types and these different interaction modes for me, I can clearly see how this would apply to and, you know, to enterprises at scale and larger organizations.

[00:02:47] Adam Hawkins: But for me, I've largely worked in small companies, either companies like, you know, maybe they have 20, 30 engineers, or there's two engineers with three engineers. Right. So. that. So the questions that I like to discuss with you today are how does the model and the approach put forth in team topologies, you know, scale up as the team grows, and then sort of what do you do when you are at this sort of small team perspective and you need to split or grow and sort of the impacts on software architecture.

[00:03:19] Adam Hawkins: So we can start the conversation by just Maybe what this question is how do you see the team topologies model applying to say an organization that only has one team? then they're looking into making say a split either with team or software architecture. How does team topologies applied there?

[00:03:39] Matthew Skelton: That's a really good question. I like it. I like that you've taken this angle. So some key principles in the team's policies book are that we're trying to optimize for a fast flow of change. So that while that means is we're trying to, we're expecting ongoing stream of changes to our software systems. That's what we mean. And that that's sort of theory of change. It should be, it should be rapid so fast flow of change, but we're also making sure that we're not exceeding the cognitive load on the team. That is, That is building that software. So these are two, I mean, there's the several other principles overly important, but these two are really, really important. So let's take those two principles and see what happens when we apply it to a single team Even if, even if that group of people is just two people say applies to two people, right?

[00:04:20] Matthew Skelton: So they're building some software and they're going really, really quickly. They're able to to get something out very rapidly. They're using some third party tooling for things like telemetry and metrics and build and deployment and all great. That's all fine. And the company starts to get some customers.

[00:04:36] Matthew Skelton: And then we start when we add a third engineer and she brings some additional skills on infrastructure automation. And so we can actually then automate more of our infrastructure and do some more fancy things and so on. And so on at a certain point, the remit of that team, let's say gets to five people or six people, and they're still, still going really quickly.

[00:04:55] Matthew Skelton: But at some point, because of the success of what they're building, hopefully. There will be too much, too many things for that group of people to think about. They start to need to worry about all of the kind of metrics and logging and infrastructure and automation and whatnot, all of this, well, or, or, and all, they need to start dealing with a D an additional business domain.

[00:05:16] Matthew Skelton: So instead of just, instead of just, I dunno, providing digital downloads, we're now shipping something physical, Or we're now providing some kind of user manager, but my account feature, something like this. So those are different business domain. and these kinds of challenges can occur very, very early very very small sizes, even just in in a group of people like five or six people.

[00:05:39] Matthew Skelton: So from a very early stage organizations should be thinking about flow fast flow of change. What is slowing us down is something now, you know, six months ago, everything was fine now. Now, it feels like we're going slow. What has changed, what feels like is not relevant to our main core core business focus.

[00:05:59] Matthew Skelton: Are we dealing with too much infrastructure? Are we dealing with too much kind of automation, detail, whatever it might be. Are we dealing with too much, detail around maybe a data privacy, something like this, and be conscious of the difference between work that is related to the main business. domain, Selling data selling digital downloads or, you know, my account versus stuff, which is not really related to that.

[00:06:25] Matthew Skelton: Like managing data, privacy, infrastructure metrics, whatever use that use these two signals around flow and around cognitive load to tell us, ah, there's probably, we've probably reached a successful size where we actually need to start thinking about somehow dividing this. work, Perhaps wanting takes my account and wanting team takes the digital downloads, or we have still one group focused on, on the main kind of user focused part of the application, both downloads and my account.

[00:06:54] Matthew Skelton: And another team takes on things, for example, relating to other data or infrastructure or something else, which are kind of outside of our domain. But that can happen very, very early. So we, a few years ago, we, we worked with, a startup in the media space and they hit this problem. at there were, I think, 11 people in that organization at the time, and it really started to hurt It hurt the speed of delivery and all sorts of kind of arguments and things happening that It can appear very, very quickly, in organization. Don't get obsessed about kind of looking for, two, to build a platform team also to put in place and an ability think about cognitive load and flow as, as the guidance kind of at all times, but particularly when, when, when the, when the organization is small and use that to guide, when you need, when you should start to think about, you know, bounding the responsibility putting boundaries about responsibility, again, with the aim of a rapid flow of change and limited cognitive load on, on the teams.

[00:07:51] Adam Hawkins: Yeah, I think probably one of my favorite parts about the book is using the flow of change and cognitive load as the two, like really Horistic about when to make these decisions. And I think the challenge that organizations small organizations have is when they. hit Like those first key inflection points in their growth.

[00:08:10] Adam Hawkins: Like, Hey, we're succeeding as a business. It's time to hire more engineers, or maybe we're going to double, double our staff or just things are growing. Right. And the decisions made at those points in time have really longterm ramifications. Like those are the hardest, like those are the hardest things to do well, but the easiest things to.

[00:08:32] Adam Hawkins: To go wrong with, And this is sort of, you can think about, you know, flow of change of cognitive load and, you know, you'll have, you know, engineers and new people joining the team. And then, Hey, maybe you say we were to use team topologies, one entire aligned team. And now we're going to sort of like split maybe into two stream aligned teams or something like this, but that sort of forces a question regarding the underlying software architecture of the system itself.

[00:09:00] Adam Hawkins: And I'm curious as to your experience on this. where Typically, you know, teams will start off by a building with a monolith. I think that's pretty reasonably safe assumption to start with. And then things eventually split organizations grow, but the underlying software architecture doesn't so like when you hit this inflection point where you think, Hey, I'm going to create a new team, or maybe I'm going to create a platform team or whatever.

[00:09:26] Adam Hawkins: How do you think of the underlying software architecture at that point?

[00:09:30] Matthew Skelton: Really great question. And you're absolutely right There's a real danger that organizations are not aware of things like Conway's law and kind of more generally social technical mirroring and, and these kinds of trust, boundaries and social inflection points. Don't take the time to plan to reshape the architecture. And that's a real problem. So if if you see a diagram from the team to properties book, or certainly a diagram that shows the teams in place and any of the diagrams that we've created, since These diagrams are always a snapshot in time. There's always, this is how things are currently working, but that diagram is effectively both a reflection of the, team responsibilities.

[00:10:10] Matthew Skelton: And also the kind of software architecture that is sort of one in the same at the same time. And that's absolutely deliberate. We're, we're suggesting that there should be this kind of very strong relationship between the software boundaries and the team boundaries. So if So if we, yeah, if we, if we were just a single streamlined team building this customer facing application, and now we've realized that, you know, the teams got too big, it's now heading towards 12 people.

[00:10:33] Matthew Skelton: It's too big. We're going to, we're going to have to hire a couple more and split that team. important question. you split it on in terms of the business domain may be entirely tiny, tiny, reasonable to split it on the business main. Do you split it? So that you have some kind of platform underneath. And when we talk about, when we say platform, we mean fundamentally a kind of curated experience for the engineers using it.

[00:10:57] Matthew Skelton: It's not about technology, it's about an experience so that it enables that streamlined team. That's using that platform to get them to go quickly, safely, and and not have to think about stuff underneath whatever that stuff is. It could be a design platform, a data platform, an infrastructure platform, all kinds of different different platforms.

[00:11:13] Matthew Skelton: The key thing there is, it is. about Reducing cognitive load on that, on the streamline team and enabling enabling fast flow. And there's, there's no right or wrong answer. So it's going to be context specific as to what kind of split you put in place. There the key thing is just, like you said before, drive, drive the decision through focus on the fast flow of change and kind of ways to limit cognitive load of different teams that you ended up with.

[00:11:37] Adam Hawkins: Do you see that, the software architecture and the team architecture. almost but Ideally, they should move with each other. Like they should be happening in parallel, or there should be a high degree of cemetery between these two things. Because like in this scenario that we were describing, you know, a team could choose maybe to do just for the sake of discussion here, like one of two different things they could say, Hey, we'll split the team, but not change the technical architecture or we'll split the technical architecture, but not change the you know, Change the teams and each one of those of course has its own like pro you know, problems or trade-offs. But if you're deciding to do one or not, the other, I think that you've really missed a point in. that, You have to first consider both and then at least going to move both of these directions towards the same objective. And if organizations are not doing that, then I think they're shooting themselves in the foot. Is that a fair point?

[00:12:32] Matthew Skelton: Exactly. And this is, this is where this is where really the old style kind of software systems architecture is dead. Hmm. It it doesn't exist because because designing software systems, just just thinking about the technology is a dead end.

[00:12:44] Matthew Skelton: However. The new software architecture is actually really exciting because we get to think about all the technology stuff, but we also get to think about other people interactions as well. And it's a much broader remit than, than in the past. We have to speak to HR people to come and we have to speak to the procurement department.

[00:12:59] Matthew Skelton: We have to speak to maybe people who decide on budget, all sorts of things. is actually because we really, because there is increasing kind of awareness. that, that there is these three of these forces kind of shaping tending to shape the, architecture of the system. Then we have to take those things into account.

[00:13:16] Matthew Skelton: So certainly splitting the technical architecture from the social architecture seems at the very minimum a very bold and probably just foolish. There may be some edge cases where, where it is the right thing to do, but generally speaking, it seems like when you take into account, the kind of particularly need to take into account kind of organization dynamics around trust kind of a sense of kind of ownership and empowerment. Then generally speaking, with that, if we want to be able to go quickly, we have to have a high degree of trust and we don't want teams to feel like someone else has been kind of stepping on their toes or kind of jumping into their code base and and messing things up.

[00:13:52] Matthew Skelton: So that's why we have all these kind of principles around, around things like this, which then end up being reflected in how we think about the software architecture responsibility boundaries. So, yes, you would, you would. Generally speaking expect to, if you're changing the teams to, change the architecture, And if you're going to change the architecture to change the teams as well.

[00:14:08] Matthew Skelton: It's not always one-to-one, but, but you would absolutely expect to, to reassess what what both of them look like at the same time.

[00:14:14] Matthew Skelton: Yeah.

[00:14:15] Adam Hawkins: That was one of the other, This was one of the other points. I actually really appreciate it. That was made explicitly in the book with regards to. the boundaries at the technical layer and that, you know, each software system should be explicitly owned by one team.

[00:14:27] Adam Hawkins: They are responsible for it. They're the ones who, you know, build it, deploy it, operate it to whatever. Then if you take that principle to the, and apply it to the situation where we're describing, when you have, you know, a code base with shared concerns, the way to fit that to whatever your team architecture would be, would be to split the code base in such a way that it aligns with the teams, because the goal here is to create a software architecture and a team architecture that optimizes for flow of change. Right? So if one of those things is inhibiting the other, then that's the place where I think you would start. at, Right. Okay.

[00:15:05] Adam Hawkins: So the other thing I like to discuss with you is sort of a natural progression in the growth of teams.

[00:15:12] Adam Hawkins: I'm kind of coming at this from the idea of you say again, you know, we're considering a small growing team and initially it's one team and then they're going, you know, they're growing. kind of thinking in my mind that likely. It's going to be a streamlined team and then maybe another streamlined team, but the likely the next team type under the next would be the platform team after the platform team, maybe then becomes enabling team between the stream aligned team and the platform team or something like that.

[00:15:41] Adam Hawkins: And maybe who knows down the line, if there is even a need for a complicated subsystem team. So again, your experience. If you're a growing organization, How do like what's kind of the order or general direction for how these different team types enter the wider organization.

[00:16:00] Matthew Skelton: That's a nice, way of phrasing it. So again, just going back to the principles, our starting point is flow fast flow of change and, and, and then secondary cognitive load. The way to get a fast flow of changes to avoid hand-offs avoid any kind of handing off of work from one team to another. So that's why a streamlined team has end to end responsibility for a particular part of the domain or application or service, because there's no handoffs.

[00:16:21] Matthew Skelton: It has all the skills and capabilities needed to take that all the way through to production and they run it in production. So. Sometimes it's called kind of a, you build it, you run it. Some people call them dev ops teams, but there were dev ops kind of means all sorts of things these days. So anyway, have you build it? You run it. They're there. They're on call. They're responsible. They get very fast feedback from production back into the streamline team. So if you could run your, your entire organization, if you could build all of your software just for streamlined, teams, And each and each team had the right amount of kind of responsibility and the right skills to do the work for that particular part of the, of the software.

[00:16:52] Matthew Skelton: Then that's great because they're nice and independent. They're decoupled. We know from kind of key software architecture principles that go back decades. I mean, back to the 1960s and wherever that, you know, modularity and decoupling between between software architecture. kind of Blocks. If you like is a really key predictor of kind of high-performing systems.

[00:17:13] Matthew Skelton: And so it we're taking the same approach and bring it into, into the organization. So if you can run with multiple streamlined teams that are basically fully independent and define everything themselves, then just run with that forever, that there's no need to introduce anything else because you cause you're optimizing for that fast flow.

[00:17:32] Matthew Skelton: However, typically what happens is after a certain point, These say it's three or four streamlined teams. They're all there, They've got this nice fast flow of change. They're all busy kind of building stuff around that particular domain. But over time, that tends to not always, but often tend to end up dealing increasing with things that are not relating to that domain, like infrastructure or data security or info, information security, all of the stuff it's several degrees away from, a focus on I don't know, selling digital downloads for example. And so at that point, they're saying, because we're having to focus on this other stuff is actually slowing us down. If we didn't have to focus on all these details, if we could just consume something around, you know, data privacy or something like this, then we will be able to go even faster. So that's there when discussions start to occur around what options do we have for reducing the cognitive load on this team?

[00:18:28] Matthew Skelton: It's not just building a platform because one option is we we, we re-skill people inside that. team, We send everyone on a training course around InfoSec or around cloud automation or whatever, or even on, cause we, we, we worked with some clients in the manufacturing sector, We did quite a bit of work around bridging the technology gap between kind of cloud and mobile and firmware and embedded software that's a really interesting space actually. And, And maybe you train up all of your people in the stream on team to understand how to write, you know, low-level C code for embedded microcontrollers, maybe that's the right thing and be able to do cloud. I mean, the problem there is that at some point you're going to be struggling to find people to fill up for those kind of roles. Because that's again, the kind of people who can do a kind of modern infrastructure automation plus plowed native apps, plus firmware is kind of limited. So just practically speaking, you're going to have to think about what that balance of skills is. Again, eventually you come to the point where you think we've reached the cognitive load on the team.

[00:19:30] Matthew Skelton: They can't go any faster. We have to find another way to start to reduce that cognitive load. And then something like a platform or maybe a complicated subsystem, which is kind of. a mini platform tends to, You tend to end up using something like that. You might, you might get away with an enabling team, which is a team of experts who are able to work across multiple streamline teams for short periods to help them understand, to help them bridge a kind of capability gap.

[00:19:57] Matthew Skelton: So maybe that's, you know, InfoSec people would be in this enabling team help these streamlined teams to increase their awareness. But again, once you get to a certain size, typically something, this there's typically a need for something like a platform. At some point where you've got five, six, seven teams now all trying to build their own InfoSec implementation and across the whole organization, that's too much time being spent on something, which is not domain focused.

[00:20:21] Adam Hawkins: Yeah. I like this discussion about inflection points, because for me, this is always the. the most interesting lens to think about these different models to see. okay, When does it break down? When do we have to change the way that something is happening or you know, working, whatever. because it sort of takes the thing to the extremes at one end.

[00:20:40] Adam Hawkins: So we already talked like one inflection point of growing team, their first like extra stream aligned team or platform team or whatever. And now you have multiple stream of mind teams, multiple platform teams, whatever. So it's have two inflection points. And then like we extrapolate further down the timeline.

[00:20:57] Adam Hawkins: In your experience, working with these like SMEs and larger enterprises, what other inflection points have you seen in say the adoption of these processes or points in organization's lifetime where they should have made a certain decision?

[00:21:10] Matthew Skelton: So it's still fairly early days in terms of directly applying the ideas in the book.

[00:21:15] Matthew Skelton: So the book is published September, 2019. So we want just over a year after the after publication. So the, the number of organizations, the type of organizations who have directly use the ideas relatively small at the moment, just practically speaking, it takes longer for a large organization to change. There's a really nice case study on our website, teamtypologies.com from a company called you switch, which is a UK is a foremost consumer utility switching.

[00:21:38] Matthew Skelton: So they do. They help consumers to choose between different broadband providers, different mobile phone providers, different gas, electricity providers, all the, orders kind of thing. I know that they've got different finance providers and I think pensions and things now as well. And there's really interesting interesting case study there.

[00:21:54] Matthew Skelton: They mentioned in the, in the teen typologies book, but they actually used, they kind of, when the book came out, they used, some that is and that's a refine what they were doing. and they It's a good, really good example because they started. Off, just with independent streamline teams, but what we would now call stimulant team independent teams and they ran with that for as long as they could and so it's a really nice example of we're not going to build a platform before it's necessary for as long as they could. They run with independent independent teams for these different kind of business domains, broadband, mobile, gas, electricity, whatever these, these, these domains are quite different. So as soon as it's very handy for them, very convenient for them to be able to run separately separately like this for a long time.

[00:22:29] Matthew Skelton: But eventually this is where we're, we're focusing too much on, on kind of cloud infrastructure. And so they needed to put a platform in, but they, were very smart in the sense that they, they, they had this very strong focus on. The purpose of the platform reducing cognitive load on the teams of both encouraging a flow of change and crucially treating the platform as a product, treating platforms, or product which is optional for these other teams to, to consume.

[00:22:54] Matthew Skelton: So the teams were not forced to use it. the platform team how to effectively do marketing internally and demonstrate why the platform was really good. And it's such an important dynamic, such an important dynamic that feels like an important inflection point to get to the point. where We realize when it's something like this is needed, but you do not have a strong temptation to force teams to use something like this And so as a sign of real kind of engineering maturity, and and product maturity to realize we should not force him to use it because that will cut off a really important set of signals that tell us that we're building the right think over the wrong thing. So, So that's a kind of important realization for for lots of organizations to reach that level of that, that that are well, that level of awareness and kind of, yeah. Kind of product discipline to not force teams, to use a platform and to put the effort in to make their one or more internal platforms really compelling, really kind of exciting if you'd like to use by internal teams. Yeah, that seems to be a really important aspect.

[00:23:51] Adam Hawkins: Yeah. I think that's actually right. probably one of the hardest problems to solve. Just generally speaking, because I say, I like to just use the example of Heroku. I'm not sure if you've ever used a Heroku, but like as a developer, I've not yet found anything. that approximates or approximates, but like, That's not Heroku that delivers the same benefits as a platform to the developer.

[00:24:08] Adam Hawkins: Let's say, let's say that I'm a developer working in one of these stream aligned teams. I know that I don't have to worry about infrastructure. I don't have to worry about anything. I just say, Hey, run my web server, Run this process and everything is taken care. I don't have to worry about anything. So that's, I have access to all of the things that I would need to do in my day-to-day work.

[00:24:26] Adam Hawkins: Like if I need to execute a command in an environment, I can do that. I've have to run database migration if funny telemetry or whatever. You know, it's all there with really minimal effort to me, which is what I want as a person working in this team, because I don't frankly care about the details of this.

[00:24:41] Adam Hawkins: Right. I just think it's delivered to me I've not found anything else. Like in any of the cloud providers or anything that delivers that kind of benefit as a platform. So then you come to any different number of engineering organizations. They're going to have sort of a, a mismatch of, Hey, we use this, like we use, maybe we do cloud with AWS and we use this for CEI and we deploy with this thing and it kind of makes this, or we use Kubernetes over here or we don't or whatever, and it kind of creates this like Vague sort of a mass of all these different tools that make this kind of lack of a better, like, what we would want to provide as a platform is a real compelling and exciting thing. that let the developers in the streamline teams can use, but sort of, we struggle to do that. And I think you brought it up as the inflection point, but it's also the, I think there might be an inflection point before that where you can even say it's worth us like, it's worth it for us to actually try to do this as opposed to like, we already maybe have it.

[00:25:44] Adam Hawkins: We need to refine it because like, where is that inflection point? When, you know, maybe you have say like, SRE is like myself or people like an infrastructure teams or whatever, who could maybe create something. like this, But there definitely has to be sort of a minimum viable investment to create something that's compelling enough to use.

[00:26:03] Adam Hawkins: Like, and if you don't actually deliver on that promise, then you might be doing your team a disservice because then maybe they're disincentivized to use it, or happy or whatever, you know?

[00:26:13] Matthew Skelton: Yeah. And so so it's kind of creaky to have some kind of, effectively user research, user feedback, on the users being the streamline teams, are you going to use the platform, make sure that's in place, make sure that feedback, loop tight feedback is in place.

[00:26:25] Matthew Skelton: There's a really interesting talk from, the platform, that had a platforms at Adidas Fernando Canaga who that this was a DevOps enterprise summit as well. And in the slides there, you can see a kind of diagram of how the time How they focus that time in, in in the platform. And actually about half of their time is spent on building new stuff.

[00:26:45] Matthew Skelton: And half of their time is spent on kind of advocacy and interaction with with their internal customers. Half of their time is spent on, on, on stuff. That's not writing code or, or running bash scripts or whatever. And that's, you know, that's even I was slightly surprised, but actually it makes a lot of sense because it's so important to to understand what's actually needed and just build a minimum amount of stuff.

[00:27:07] Matthew Skelton: If you can get away with composing your platform from services that run entirely in someone else's cloud. And all you're doing is kind of collecting them together with a little bit of lightweight documentation and a few little examples and maybe some default configuration, if that's all you do. That's brilliant, but maybe you just put a tiny little wrapper around her Rocco, for example, some, some sensible conflict defaults and some, kind of security policy, whatever it is, a tiny little bit around Heroku, that's all you do that you don't need to build, you don't need to go ahead and and create a a bad version of Heroku. like, what was the point is already really good. So like, like, think about the experience that developers or engineers are going to have when they use this thing and focus on the experience not on building stuff, give them an experience which has kind of curated and shaped for them, but you don't have to build it.

[00:27:58] Matthew Skelton: You, I mean, it's kind of exciting to go and build something, but you can do that in your spare time. Right? If you want to do a lot of coding, the key thing is the experience of things that the customers are going to have.

[00:28:08] Adam Hawkins: Well, that's the other part I think the hard problem, especially for a small team, right? Is that you can't just think of yourself as say, if you're a member of this theoretical platform team that we're discussing you, can't just think of yourself as somebody who builds a platform, You have to be a marketer you have to do. an user research, you have to, you know, like really get involved in the actual product development of this thing, which may not be something that you've really ever thought of or like maybe even know how to do, but that's such a fundamental aspect to actually creating a compelling and useful platform.

[00:28:41] Adam Hawkins: Right. So like if you're a small team, might be hard to maybe like delegate the resources required to do that. Right. And it sort of also speaks to the cognitive load on the consumers of this thing, because, you know, if in theory you can create a platform that is say, Hey, we use A, B and C, here's the docks of how to glue a, B and C together.And for some stream aligned teams, that may be enough because they have the skills required to understand the glue and do it all together. But. Other teams. So composed of other developers with different skills may not have the skills required to actually do that. And you can I think you would say you could use that as a heuristic for when you should try to. You know, sort of like level up your platform apply it from the team, right?

[00:29:23] Matthew Skelton: Yep. So, Absolutely. And again, you're always using These two principles flow both inside the platform, but also for your customers. So users use the four key metrics from the accelerate book, predict higher initial performance, lead time, deployment, frequency, change, fail percentage, and meantime to restore and and those four make sure that you understand that your platform should be improving those four metrics for your customers all the time. It should not be, you should not be in badly affecting those four metrics or the very least, and also kind of thinking about cognitive load and, and some other metrics like this, which which give a strong indication for whether the platform is doing its job.

[00:29:59] Matthew Skelton: And that's, as you said, that that would requires a whole bunch of skills. which lots of people who have been working in kind of infrastructure certainly, or data have not needed maybe before. This it's a really good opportunity to kind of broaden your kind of professional professional awareness and professional skillset. But at the very least, even if, even if you've got like a, a full-time product manager or kind of internal platform, developer relations or someone, then at the very least you should be aware that you need to have some focus on developer experience on how do we market this is this the smallest thing we can possibly do to deliver the right kind of value and reduce cognitive load. And these kinds of questions It should be the things that we're asking ourselves when we're, when we're building a

[00:31:06] Matthew Skelton: platform.

[00:31:10] Adam Hawkins: What do you

[00:31:41] Adam Hawkins: think about if the idea of the platform as a black box? In the sense of like, say if you're using AWS and there an issue with AWS, maybe you open a support ticket or whatever, you don't try to you know, go behind the curtain sort of debug it yourself.

[00:31:54] Adam Hawkins: So I'm kind of, I'm coming at it from the perspective of, Hey, I created this platform It was all the documentation, you know, it should be useful to the end user in such a way that they can achieve their goal without having. to.,say get the hands-on support or if their application is broken or, you know, in like such a way that they should be, they should have.

[00:32:12] Adam Hawkins: The skills or docs or tools, whatever they need to like debug it, or, you know, resolve the issue as much as possible. So like, okay. Yes, sure. Like maybe everybody's all part of the same organization, but, in your experience, have you seen things like, You know, like, Hey, if I'm a developer in the streamline team, like I opened a support ticket on the platform and maybe there's some, person, on the platform team who was, you know, trying to triage and support issues and how do you have you seen those? How have you kind of seen those dynamics work out?

[00:32:40] Matthew Skelton: So nice question. So to some extent, to some extent, the need if you have a need to open a support ticket, then something's basically. gone wrong. Like, ideally we should be, it should be self-service. It should also be, we should have a high degree of observability into whatever we're using, whether that's an internal platform or a third party platform like if it's not possible to see why, you know, some provisioning thing has failed inside AWS, that's kind of bad. We should be able to see some logs or we should be able to see some useful output and have sort of like a trace ID and be able to use that and plug it in somewhere and get some more information.

[00:33:11] Matthew Skelton: Self-service as much as possible, but at some point, you know, we're all human and there'll be some parts of the platform which are less mature or less kind of, we haven't found all the educations yet, in which case we do need that kind of human support. there, but That should be for the, that should be a signal to us that this aspect of the platform, that, that that's available is not really as polished as, as it needs to be because this developer couldn't self service and understand why this provisioning failed or why this data migration failed. And that they should have been able to understand why this thing has has gone wrong. I mean, there's two types of things, right? One is something failing and that's kind of bad, but there's two. We should be able to have a huge amount of observability and and, you know, self-service logs, and metrics and diagnostics to at least get to the point where we can go. Ha. That's why it's fairly. it was my fault. I need to configure this thing differently, right? I'm still self-service or actually looking at these logs.

[00:34:08] Matthew Skelton: This does seem to be a bug in which case I am going to raise a ticket, but we need that level of transparency and, and, and telemetry and things to, to be able to get us close to that decision decision point as possible.

[00:34:18] Adam Hawkins: Well, also the focus on the boundaries of these individual teams, right? Because you can sort of imagine that If you have coming back to the example of just like a Wiki page that says how to glue a, B and C together. Okay. Hey, you're the one who glued ABC together. If it's not working, maybe you should be the one to debug it or fix it or try to, you know, do whatever you need to do. Whereas say, if the platform team has provided a glued together version of ABC, if it's not working, that kind of falls on their plate.

[00:34:44] Adam Hawkins: I think this really goes to the discussion of The boundaries and responsibilities are really important between these teams, because I guess you mentioned the focus is on self service, which I think kind of is I don't really hear that talked about so much in the discussion of these teams, but it's a really critical aspect of why we actually do these things. And If you think about it through the lens of self service. then I think the boundaries become more clear.

[00:35:07] Adam Hawkins: What do you think?

[00:35:08] Matthew Skelton: Yeah, no, totally. I mean that should absolutely be the goal. And particularly when particularly when we're providing something like a platform, a set of capabilities that should help us to go quickly, safely you know, call our platform, call it something else, whatever but, but that, that should be the key thing. If it's not self-service, which is blocking flow, because, because we now have a streamline team so-called that should be able to deploy all the way through to production, but he's now waiting on a. On another team to, to, to get back to them and they might not get back for two days.

[00:35:33] Matthew Skelton: I mean, that's, that's fundamentally blocking flow. I mean, it's kind of, it's understandable if it, if it's a, if it's an aspect of the platform that has been recently recently developed or has a bug in it or something like that is Fine. Okay. It's an awkward situation. But generally speaking, if we're talking about new normal normal activities, including things not working properly and in the normal course of things, then it should be self-service all the way there's basically no, no excuse now with the kind of software tooling that we've got, it's just amazing with. kind of like, you know Open-source API stuff, open source, telemetry, source infrastructure, automation, data migration stuff. It's just this there's a huge myriad of tools out there. All of which are many of which are really, really good. And this has changed in certainly in my working lifetime, the the, the tooling. Now it's just amazing. So there's no excuse for not for not making this stuff Self service.

[00:36:18] Adam Hawkins: Well, maybe besides the internal will or perhaps the skills of the engineers themselves, because like, as you mentioned, the number of the number of technologies that we have to work with, the, you know, the different layers that we all interact with on a day-to-day basis, you know, and all the different ways that those Problems can be solved or that they can go wrong. does require a sufficient amount of knowledge, or really a broad base of knowledge to operate effectively. And this comes back, you know, we're right back again, to the point about cognitive load, is that sure you can pick all these different technologies, the different tools did build whatever, but you know, at the end of the day, If the developers tasked with building and operating that system, can't fit that all in their head.

[00:36:58] Adam Hawkins: Then you have a proble., you know, you could choose a load it up with all this stuff, but you don't just because you can doesn't mean that you should. And also that, you know, speaking to your point about scaling up different members of your team, like say if you were moving to a structure where. You didn't really have streamlined teams.

[00:37:16] Adam Hawkins: And then maybe there's some kind of mix of people who can do like this and that, whatever. But Hey, you say, now we're going to create a streamlined team and you have to have, you know, responsibilities, a, B and C, which requires you to know like technology, you know, X and Y, and be able to operate that whole system from, you know, it's designed to production, ultimately, decommissioning.

[00:37:35] Adam Hawkins: The members of that team that might be, of their first ever go around at that. Right. And you have to factor that into the composition of the people in the team and ultimately like your sort of hiring process, I think. I mean, have you seen anything like that, play out in any of the case studies that you've, that you've seen?

[00:37:54] Matthew Skelton: That's a good question. Have we seen, so what tends to happen eventually is that organizations with the platform that's serving multiple teams. We'll tend to have maybe two or three different options. They'll have a nice kind of paved path or straightforward approach, which is, which is, which works.

[00:38:13] Matthew Skelton: it's not super flexible, but it basically works if you, if you've got certain parameters and then you can get started with that. Then when that team is happy with that and wants to flex their wings a bit and wants to wants to spread their wings a bit and try something a bit more. well, they're more flexibl. but yeah, it's more adventurous, but essentially a bit more flexible, allows them to do more stuff, then there'll be some kind of API or some kind of like toolkit or something.

[00:38:35] Matthew Skelton: I know Spotify, for example, have written publicly about how they do this from an engineering perspective. And so there's, there's actually kind of three options that they provide And then the final one is kind of just a set of KPIs, which allow them allow teams to. kind of Automate automate their own way of deploying and testing and things.

[00:38:52] Matthew Skelton: So eventually you'll probably end up at a large enough scale evolving platform to, to have these like a staircase of options for, teams with different levels of maturity and awareness, which again is it's targeted app flow and cognitive load. So it's, it's it's perfect example of, of, of organization, even if they're not explicitly addressing flung country load effectively, they are by offering, offering those kinds of options, right.

[00:39:16] Adam Hawkins: Because it's you know, different scales. One size does not fit. All right. Each team's going to need different, you know, different things and be able to do different stuff. So I got one short question for you before, before we go, is it, what is the next step for you with regard to sort of getting team typologies out there and like case studies and what's what's the future? look like?

[00:39:36] Matthew Skelton: That's a really great question. It was interesting that we saw just today that, the people behind safe scaled agile framework, I've actually, thrown out there previous recommendations around types of team. And I've announced saying you need to use a team to produce a approach for if you're using safe, which is super interesting. It just came across into the day. So there's no doubt. that There's going to be some interesting work around, around very large scale software delivery situations. benefit their clients that we'd be working with over the last year have been running some kind of large-scale agile delivery approach, Some somewhat, some more successful than others as you might expect.

[00:40:17] Matthew Skelton: So definitely a lot of work in that space. We're working with all companies of all kinds of different sizes. One thing which we, which we're really excited about actually is to be working, working with a couple of people with backgrounds in psychology.

[00:40:28] Adam Hawkins: Oh, that's interesting.

[00:40:30] Matthew Skelton: One in, I think she's I think she's from Europe and one, one person who is in, modern person who's in Australia and they're they're both in the software space, but they've, they've got a background in psychology. And So we're going to be doing some work on measuring team cognitive load because that's one of the most common questions that we get is, Hey Matthew, on our own, well, how do we measure team cognitive load? And there isn't a straightforward answer now because actually. Applying the kind of cognitive load techniques to groups is something that has only really started happening in academia and in industry in like the last few years.

[00:41:06] Matthew Skelton: So this is quite an sort of, it's a new application of an existing concept. So we're super excited to be kind of doing some work in this space and, and, hopefully during 2021 it's next year, we'll have something come out, which is then they'll probably be a series. of Different versions of kind of comp team cognitive load assessment that come out, but that's hopefully going to be really, really useful for lots of organizations.

[00:41:29] Adam Hawkins: Well, that sounds definitely better than my version, which is just gauging by pain and frustration. When I talk to people about things

[00:41:36] Matthew Skelton: I know about, that's not bad start.

[00:41:38] Adam Hawkins: It's certainly like a, you know, just a rule of thumb. you know.

[00:41:41] Matthew Skelton: Yeah. Yeah. How, how, how painful is it to work with this, this aspect of the platform or this, this aspect of this thing?

[00:41:47] Matthew Skelton: That's not, it's not a bad start to get. People's kind of gut feeling responses.

[00:41:51] Adam Hawkins: It's definitely a gut reaction. And certainly you can encourage an emotional reaction, but sometimes, you know, that's what you need to get started.

[00:41:58] Adam Hawkins: All right, Matthew. Well, thank you so much for coming on the show. It was my pleasure to talk to you about some of these things I've been turning over in my mind.

[00:42:06] Adam Hawkins: Is there anything you'd like to leave listeners with before we go?

[00:42:10] Matthew Skelton: It's been great to be here. Thanks Adam. Just head to teamtypologies.com/examples, And you'll find some more recent case studies from, from a few of these organizations see what they've been doing. Some of these organizations have been kind of mashing up doing, doing some kind of mixing a few different techniques, including one that's used a combination of team topologies and Wardley maps, to get kind of situations, situational awareness and, that been, there's been some use of domain-driven design. Together with team product as well. So it's really interesting what different organizations are coming up with seeing different ways to use the ideas and things in, in, in the real world.

[00:42:42] Adam Hawkins: All right. Well, thank you Matthew, for your time and hope to talk to you again.

[00:42:46] Matthew Skelton: Okay, great. Thank you very much. See you

[00:42:49] Adam Hawkins: Bye bye.

[00:42:49] Adam Hawkins: You've just finished another episode of small batches podcast on building a high-performance software delivery organization. For more information, and to subscribe to this podcast, go to smallbatches.fm. It hope to have you back again for the next episode. So until then, happy shipping.

[00:43:09] Adam Hawkins: Like the sound of small batches? This episode was produced by pods worth media. That's podsworth.com.