00:00:12

Hi, everyone. Thanks for joining us today. My name is Matthew Skelton. I'm here with my coauthor manual patient, and we'll be talking to you about team typologies and action, some early results from industry and the founder of conflicts. And I've got background in building software and helping organizations to become more effective at delivering software on your own.

00:00:32

Um, Monroe fish. Am I in the independent it organizational consultant and trainer.

00:00:41

So we're the coauthors of the book, team topologies, organizing business and technology teams for fast flow. This was published by it revolution back in September, 2019. So just over a year ago. Um, and we're very pleased with how the book has been received over the last year. And you'll see some of the organizations who have been using the ideas in the book, uh, later in our talks today, the book has been described by people like Charles Betts. Who's a Forrester research. He describes it as innovative tools and concepts for structuring the next generation digital operating model. So the idea is in the book that can be quite strategically important for organizations in this kind of space. So what kind of problems can we solve using teams policies? What kind of questions does seem to kind of address? So here's a few, why is our transformation not a tree achieving fast flow? What's our purpose and mission as a team within the organization, why are our teams not able to respond quickly to business needs? And then finally, how can we safely remove low-level complexity from customer facing teams? So these are examples of questions that, uh, teams projects can help resolve inside an organization.

00:02:07

So the case studies today have all evolved since the book was published about 13 months, just over a year. So that is quite early days really, but it's, there's been long enough time for these organizations to make some good traction, get some good, good headway with these approaches. And there's four organizations we'll be looking at today. First asylum, pure Jim, you switch and wealth, whether it's just before we get into the case, studies themselves, let's just look at some key concepts from, from seeing topologies. So there's four team types, four types of teams that we define and that the fundamental type of team is a streamlined team. This is a cross functional team mix of skills with end to end responsibility for kind of build and running of a part of the software system, business domain, a set of kind of features or something like that.

00:03:02

There are no handoff at all. They build it and they run it in the live environment. And then we've got three supporting types of team and they willing team, a complicated subsystem team and a platform team. And you'll see these shapes being used in some of the diagrams that these organizations have, have, uh, have produced. And, and, and they've adopted this kind of, um, the visual patterns and ways of thinking. And there are also what we call three team interaction modes, which define how teams can and should relate to each other at a particular point in time collaboration, two teams working together to achieve a specific goal for over a period of time X as a service wanting, providing, wanting, consuming, and facilitating where I want to is helping another team to overcome some capability gap or to move technology or adopt a new way of working or something like this. And this is typically how we might see these, uh, team types and interaction modes combined in a diagram there's always an implied flow of change left to right in all of these diagrams. And that's really important. That's like a kind of key visual, uh, concept, which makes these kinds of diagrams look a bit different from some other diagrams, um, for it from some other kinds of ways of re representing teams.

00:04:17

So let's have a look at the first case study. This is from foot asylum for the asylum is a retailer based in the UK founded in 2005, they've got 70 stores in the UK now, and 260 million pounds worth of revenue annually, two and a half thousand employees. And in early 2019, they started to make some changes to it, to make it more responsive to business needs at the time. So back in January, 2019, there was a high fragmentation of work and focus, uh, within, within teams building and running software. Historically the piece of work would start with a senior project manager who would give it to a team of product product managers, and then they would assign these some tasks to individual developers. Um, so this, this, uh, led to the priority of work kind of changing on a short-term basis, depending on, on, on, um, who was most frustrated in terms of what they needed to get delivered.

00:05:17

And it prevented a focus on wider business outcomes. And so it was quite apparent that the way that the team was organized at that point was, was creating that the way in which the teams were organized was creating poor outcomes for the, for, for the organization as a whole, um, many, there were many different implementations of very similar things because work was not coordinated across, uh, the different groups of people and the cognitive load on individual developers was very high because they had to work in many different languages, many different, similar implementations that were slightly different and so on. So there's a decision was made to really kind of radically change how, how work happened. And they started by identifying sensible boundaries, typically mapped to business domains. So they, in, in their world, um, they came up with e-commerce as a, as a business domain, uh, the retail POS systems, customer experience and ERP enterprise resource planning.

00:06:16

And then it also had a certain what they call the services team. Um, and so by having these, these four main business domains are mapped to how the, the, the organization saw, um, uh, treated as its own business. Uh, and so there was no handoff in any of these, any of these teams, they could take a concept or an idea or change end to end and, and own that and deliver it. So there were setting those sales up for a fast flow of change, and then they saw, uh, me and, uh, Manuel speak at DevOps enterprise summit in London in 2019. So about a year and a half ago now. And it was kind of just the right time if you like. So they took some ideas from our talk and some of the other material that we, that we, that we put out at the time and started to use that.

00:07:05

And in particularly, they actually started to use the team interaction modes, uh, and it turned out that the product managers actually found these really, really useful. So this quotation here is from Andy Norton, who's a software development manager at foot asylum, and he says this, the product managers from each team took special interest in the team interaction types. Has it helped them to have useful directed conversations about upcoming work? They could essentially fact check their different roadmaps and making sure that the interactions required were lined up in advance. So actually the team interaction modes here are starting to help product management work out what that roadmap should look like.

00:07:47

The, what was then called the services team actually decided to rebrand as a platform team because they were taking some of the teams potties concepts, um, that helped them to think about how they were going to break up a complicated legacy backend system that had like a shared database and so on into, and they could break it up into smaller components that were individually deliverable. So we've got streams inside inside the new platform. Interestingly, they actually combine the team topologies ideas with something called Wardley mapping. So this is like a situational awareness approach. Um, and it's particularly useful for organizations with, um, we've kind of long and complicated value chains, just like, uh, uh, a high street retailer does have, they've got, uh, kind of high street stores, website, and mobile apps, warehouse, operations, logistics processes, and so on, it's quite involved. Um, and what they did is to use the kind of team types from team typologies and the team interaction modes to think about their value chain and which aspects of their value value chain should be moving towards say, commodity or product or service or something like that. If you're familiar with Wardley mapping, that will all make sense. The key thing there is that they were combining these techniques team typologies on Wardley mapping to help guide the strategy and target architecture,

00:09:02

Uh, this then they, they, they took one of the business remains. It was, there was more familiar, I, which has retail ethos team, and then worked with this new platform team to try and define, uh, where the boundary should be. Um, in particularly the concept of ERP enterprise resource planning is quite well understood in the industry. And so then they could, it was, it was, it was clear how they would, um, use the team interaction most of kind of established tools to assess and establish where these boundaries should be. It helped them as well to, uh, to adopt what we call thinnest viable platform. So effectively instead of having to build something that was very large and complicated. Um, there's one example that they give, which is that instead of building a complicated service around the location of their different stores, they actually could just use a static, uh, Jason file to serve that information because it turns out a physical store doesn't really move its location very often. And so they were able to implement something very quickly and that met the needs. So rather than, rather than building something huge, we could keep it the smallest size possible kind of finished viable platform.

00:10:13

Uh, and it's helps to provide some clarity of purpose having these different team types and, and, and the set of behaviors and thinking that goes with the different team types, help them to realize that for example, they do not need a database expert or data expert in each streamline team. They can actually have, uh, an enabling team of, of data experts that work across different teams at different points. And that actually is starting to work really well for, so quite a few concepts that they used it for this item from streamlined teams, then it's viable platform. The TV interaction modes are really important. And the combination of tinker policies with Wardley mapping that was very effective for them. This has given a foot asylum kind of product management superpowers. If you like to be able to kind of predict and plan what's happening in the roadmap, it's been really useful for them to have the well-defined kind of interactions between team, particularly during this COVID 19 pandemic, it's helped to, um, to clarify how people should be working. And ultimately they've got responsive autonomous teams being able to deliver things much more effectively for, for the organization and in order. And again says the interaction most defined by team to poverty has gave us real insight into how we could maintain effective practices and also cross team collaboration. So quick, thank you then to Paul Martin, who's it director for this island and other Northern who is a software development manager there as well.

00:11:43

The next case study is pure Jean. This is quite interesting because they adopted several of the aspects of team topologies. And so pure gene has been around actually since 2009, but there was a huge growth, um, in the last five years. And so they create all the software necessary to manage their network of gyms and oldest the software for, um, membership as well, bookings and payments and Swan. So they've always had this focus on online first experience. So right now, actually most of their gyms only actually have two or three employees on site. Everything else is automated. And the do history of how they grew is quite interesting because they started as a startup with less than 10 people. Um, everyone knew each other, they could talk to everyone. And so it was easy to discuss the, um, and clarify any, any questions. There were organized focusing on projects and also the business as usual team that would take care of small changes and fixing bugs and improving, um, some of the, the, the code and internal maintenance. And then as they grew to, um, over 40 people, this project approach that they had was starting to show some issues, um,

00:13:14

Did was hard to plan on long-term for the overall product, um, because every team was just focused on the kind of near term project that we're working on. Um, it was becoming quite hard to understand the overall, um, code base in the applications, uh, because many teams had changed them over time. There were no stable teams And they realized that they had gotten into this sort of monolith, where did a single code repository where all these different teams were, were making changes. Um, there was a lack of ownership of any particular area of the monolith, and it was very hard to plan for kind of long-term care and, um, architectural changes and, and other aspects of the viability of this software system in, in the longterm. And so they looked at as they, um, red team typologies, and they looked at the, the importance of defining the different streams, right. Um, so they looked at how can we break our monolith into, um, nice clean segments or streams? So they use different, uh, what we call fracture Plains, such as the cadence of change, the risk and the, um, regulations that different parts of this model is needed to comply with. And so they came up with this,

00:14:39

Uh, what you see here in this slide, where the identified streams, as, you know, Jim acquisition payments, uh, et cetera. And by doing that, they were then able to align their teams. Now they create a streamlined teams that were aligned to this streams de identified.

00:14:58

You can see, they also looked at the other typologies. They started to, uh, identify what else do we need help with? Or most of these teams, Timberland teams need help with around the developer, um, flow the workflow, the, the experience, uh, was one area improving the reliability and the performance of the different parts of the system was another area where they needed help. So they created enabling teams and they also had, uh, they started with a platform team that was focusing on, um, membership management gateway. So this is something that many of the streams needed. And so they, they, they knew that that was a good place to start for the platform.

00:15:42

They explicitly decided to have an initial phase of high collaboration between, um, most of the teams because they knew this was going to be, um, it was not going to be a, um, a one-step process to just break apart the monolith. Uh, so they needed those teams to collaborate and actually understand where are the actual boundaries that we need to set up. Um, as we break apart, the model is so that each of the streamline teams can evolve more independently. And so this collaboration is focused on, um, identifying, agreeing on boundaries. Um, and at the same time, this was increasing the ownership that each of these streamlined teams felt over the, the software they were responsible for

00:16:28

After they did that period of high collaboration, then they, uh, started adopting the other interaction modes that we talk about in team typologies, facilitating and acts as a service. So they started to, um, get the teams familiar with different interaction modes, depending on what they're trying to achieve. So the enabling teams around DevOps and SRE were facilitating some of the streamline teams. Um, they were helping them with their, uh, build pipelines, infrastructure, um, automation, things like this, helping them gain those, those skills, um, and the platform that was already by now quite stable. Those membership management services was being consumed, uh, in this acts as a service, uh, modes that we talk about.

00:17:18

So they got the teams familiar with the three different interactions, uh, w where collaboration is the third one. And by, by now, what they have is this kind of, um, much more organic and dynamic change between periods of collaboration, uh, periods of, um, facilitation by the enabling teams in particular. Um, they also realized that sometimes there are cross cutting concerns that are going to need different tumor line teams to collaborate. Um, but this now is much easier because they have this explicit expectations about when is this going to happen? What are we trying to achieve with this collaboration, uh, sort of interaction?

00:18:04

You might wonder what that mobile team in grays is, uh, what does that mean? Um, so actually they didn't have, or don't have clarity at this point yet if this mobile team, uh, is going to become more of a, um, an actual stream aligned team or more of an enabling team. So they're actually, that's okay. That's okay to wait and learn, you know, what exactly, uh, based on what we see in terms of dependencies, in terms of how often they need to interact with other teams that we can wait to make the decision and understand better if the, um, should the role should be more of a streamline team or an enabling team. So John killed Mr. Uh, who is principal software architect at pure team. Um, he said, attempt apologists, help them evaluate the relationships between their teams and the business strategy, increase team efficiency and evolve away from a monolith. Um, and as you can see, also increase the, um, ownership of each of the streamlined teams. They use several concepts from Kim topologies, namely fracture, planes, and the interaction modes for clarity In terms of results. They became much more business responsive teams with this increased ownership are able to, um, respond much faster and, uh, adapt and make changes to the, the streams that they are responsible for. And they moved away from that kind of project orientation approach they had earlier on.

00:19:46

They also, this also help improve team morale teams are more, feel more, um, autonomous, that they have more mastery and a clear purpose compared to the project teams. And this allows them also to make better decisions for the longterm architecture and general health of their systems. So we want to thank John Gill, Mr. And also rich Allen, who is head of consulting. The next case study is from, uh, another UK company called you switch.

00:20:19

So you switches the leading comparison, um, company in the UK for, um, home services like comparing electricity providers, broadband providers, et cetera. And so what's particular interesting about, um, their story is that actually they're starting to in 2000, but since 2010, they focus a lot on autonomous teams. So having each of, of the sort of streamlined team where they had full ownership of the whole life cycle around some business domains. So for example, one team was working on, um, the comparison service for energy providers and other for broadband providers. And they had almost full autonomy to make all kinds of decisions around tooling infrastructure, their development process deployment, et cetera. And this was quite helpful. Um, for a period of time, this, each of these teams was able to discover and evolve as quickly as, as they need it. But, um, a few years later they started to see quite an increase in how much each of these teams had to worry and effort.

00:21:30

They had to spend around things like infrastructure, automation, um, understanding different AWS services that they have to use, uh, all the different options and configuration, et cetera. And so they did something interesting, um, a bit, uh, geeky perhaps, but I find it quite interesting. They were looking at the, um, number of low-level NWS service calls, so calls to the, to AWS provider, um, before they introduced a platform. And as you can see it, it kept going up, kept increasing. And this was kind of a proxy for their, the cognitive load that these teams were incurring around, just areas. Um, I liked the way pulling those, uh, put it, so he's the CTO at switch that people were spending more time having to interact with relatively low level services. They're spending their time on low, low value decisions. And so they introduced a platform to reduce cognitive load on those streamline teams, provide them the services that they need, um, to be more efficient, uh, accelerate and focus more on the business aspects.

00:22:39

And they had a very, very, very much a product focused approach to the platform. So I did they identify the first customers, they created the services that would meet their needs. Um, and then, um, so th they, the, the initial platform started just with a couple of services, a few services for one Summa line team. And that was okay because it was already being consumed as a product. And then they realized the need to improve and make more visible the reliability and the, um, some non-functional aspects of the platform, uh, because each of those tumor line teams had done quite a good job in terms of making sure the reliability and performance of their end customer services was quite high. So the platform had to prove that they were able to meet those expectations from their own streamline teams. Um, and there were also looking at the adoption of the platform in terms of traffic, again, what was going directly to AWS versus how much traffic was not being directed through the platform services. And so that graph that you saw earlier kind of change, you see that inflection. And so this means this was a good thing. It meant less effort, less cognitive load that was being put on the similar teams around the kind of, um, infrastructure aspects.

00:24:07

And so, um, they also address some cross-functional aspects, uh, needs that each individual team would not have the time to work on by themselves, um, or, or the priority. And eventually they got adopted by, um, most or, or every, every line team in the organization, even those that had very high, um, demands in terms of performance in terms of reliability. So there was a need to demonstrate, uh, also from the platform point of view, that we can meet those expectations. And then, um, more recently they actually evolved and created, um, more than one platform. So besides this kind of more cloud infrastructure focused one, they also have platforms around consumer data and another one around, um, affiliate market, uh, affiliate marketing. So once they prove the pattern and they prove that this can actually accelerate streamline teams, they expanded, uh, and applied the same ideas to other areas that are, um, more kind of business focused. So Boingo said that the engineering principles that guided the way they organize teams were always loosely, coupled and highly cohesive. Um, and Tim topologies was great for tying a lot of those ideas together and, uh, giving it some language, which is something that many,

00:25:31

Many companies have said that having now the language with him, typologies to talk about the problems and, um, addressed them. So platform as a product, uh, was what is one of the key concepts they used, um, clarifying interaction modes as well. And thinking about this curated platform experience, where we have identified who are the users of platform we were addressing their specific needs, um, not just functional, but also, uh, other aspects that are non-functional Other results that they got from this approach was, um, while before they were focusing a lot on full autonomy, meaning making all the decisions by each team. Now they were focusing on teams being self-sufficient. So with the, um, self service patterns in the platform, but now we were, they were able to reduce a lot of cognitive load on those teams. So we want to thank Paul Ingles CTO at you switch and Tom booth, head of infrastructure and security for their, um, giving us and sharing the details with us.

00:26:51

So the final case study today is from a company called wealth wizards. They offer financial advice and find founded in 2009, and their customers are consumers and companies, and their kind of differentiator is explainable AI explaining how the machine learning actually produces the recommendations and results that they're offering. And they've been increasingly successful of the last, uh, 10, 11 years. So there's quite a large product growth, kind of, uh, six times the, um, the, uh, number of products that there were before. Um, and this increased success, uh, led to a need to kind of split how some of the, uh, software was built. And there was multiple additional products added on, uh, the difficulty, of course, with success comes a, comes a need to kind of change how we build, uh, and, and build and run the software that were, that were involved with.

00:27:58

And by the middle of 2019 software engineering effectively had halted come to come to a stop where leases were taking weeks or even months to appear and contained lots and lots of different microservices. Um, the platform that they built had had little ability to handover from one type of financial advice to another type of financial advice. So if you were speaking to a human being that human being will be able to deal with multiple different kinds of advice, but the way in which they built their, their products, it was very difficult to do a kind of handover from one product to another. And engineers had an increasing number of things to think about, uh, because I hadn't defined clear boundaries between different parts of the business domain and also different parts of the technology stack. However, in September, 2019, as we know, Tim typologies was published.

00:28:52

And so wealth wizards took many of the ideas and concepts from the book and started applying them, uh, internally. Um, we actually did a little bit of work with them, uh, and took them through some, uh, approaches like the independent service heuristics that we have on GitHub. See these, these are open-source creative commons, uh, just, you can, um, send us a pull request and they're available there. Um, we went to use an early version of these with a wealth wizards. These are rules of thumb or clues for identifying possible value streams by seeing if, uh, this thing could be run as a cloud product effectively. And what was interesting in this case was there was exactly one of the potential value streams inside the wealth with a business domain was already available as a separate cloud product from a competitor. So actually that was a perfect candidate for one of that, for one of their new streams, you can see that in their diagram here, they've used the teams, project shapes and colors, uh, and, and the kind of the flow, um, concept to help them reason about where they should put boundaries and ancestral responsibilities in the new architecture and Richard Marshall, a CTO at wealth was it says the teams bodies has given us tools.

00:30:12

We were looking for and have helped us to build a plan and have confidence that we know where we're going and how to get there. So they use concepts like streamlined teams, looking at boundaries that help flow and also adopted the supporting team types, particularly with a focus on reducing cognitive load on street reliant teams.

00:30:32

The results are that they have, they have clear patterns and language for talking about responsibilities and teams and how they should interact. They've been able to framework for design decisions and they've got confidence in their approach to scaling. And you can read more online, uh, in the, in the article that's linked on the slides here. So thank you to average Marshall who's CTO at wealth wizards. So a quick summary then, uh, what, what are we seeing from these, from these 4k study today? So, first of all, thanks to all the, um, all the different, uh, companies for providing the information and allowing us to share the, these, uh, these details today for, to silo pure Jim use switch and the wealth wizards. What can we draw from these four examples? So, one thing we can draw is the streamlined team is the starting point. It provides fast flow and feedback from running systems. And that's incredibly important that we use that as our starting point teach policy is also provides common language and a set of patterns for the whole it organization, not just for those building software, but also inside a platform or providing any kind of service around, certainly around it.

00:31:42

We need to explicitly design for team cognitive load. The size of bits of the system should be no bigger than, than the cognitive load that our team can handle. And that's a kind of new way of thinking about the size and the thinking about architecture software and systems architecture. So it's a new angle, which seems to be very useful. And finally, a platform can be seen as a curated experience for engineers to accelerate and simplify software delivery. So don't obsess about the technology in the platform. Think about the experience of people who are using that platform and use that as the starting point. That also seems to be a very useful approach, uh, that, that comes out of the team topologies book. So what's coming next well we're manual, and I are working on a workbook, which is focused on remote work. So in response to the pandemic and we're working with it, revolution on that at the moment, and we hope to have the app soon, the initial version will be free.

00:32:37

Um, so look out for, look out for details on that. We've got some free resources too. We've got some resources around remote first ways of working at the team, typologies.com/remote. First. We also got some free tools and templates on get hub, go to get hub.com/team topologies. We've got some other things as well. Like these team, uh, shapes, modeling shapes. We've got a physical version, which you, which is a pre printed card shapes. You can push out. We've got a PDF version of that as well. We're also working on some, some digital tools like for things like Miro and Google slides and things like this. We'd love to have feedback from you. Uh, you'll find us on online. Typically teams apologies, Twitter and LinkedIn, and so on. We can drop us an email. Um, we've got plenty of training courses now, which are fully remote first. Um, and we have used letter if you'd like to find out more than just sign up@teamtypologies.com. We're doing a Q and a in slack right now. So join us there. We've also got an ask me anything and AMA session on October 15th at 1240 Pacific time. So join us for that as well. So thank you very much for attending. It's been great to share these details with you and we hope to see you soon. Bye.