Transcript for "How AI Is Changing the Way We Structure Engineering Work – and How It Shouldn't": Hi, and welcome to Blueprint plus plus a webinar series where we interview leading thinkers at the intersection of the technology and business. We are gonna be talking about trends in software development and AI, and all the best practices which are gonna be helping out the enterprises in the world to achieve the better results. One quick note on this webinar is that it is prerecorded, but we will be live in the chats during the webinar every time. So please drop your questions in the live chat in the system, and we are gonna be answering those. I'm Misha Vink, VP of Business Development here at JetBrains, and I spent the last thirteen years with JetBrains changing the life of software developers, and that's been a great journey. And today I have with me Matthew Skelton, the author of Team Topologies. Matthew, welcome to the webinar, and thank you for being with us here. It's great to be here. Thanks so much for inviting me. I'm sure that it's gonna be a lot of fun to discuss. So just to get started, to familiarize the audience with the Team Topologies and you, can you give us your quick elevator pitch of what are you up to, what are you working on, and what are the team topologies? So Team Topology is the book first published in 2019. The second edition came out in September 2025, so just recently. Second edition is is the one we need to look at now. It's got 10 great case studies from organizations around the world applying the ideas, with really good success. But just to set back, like, what was the problem that we're trying to solve with the book? So Teams Portage effectively provides a bit of a blueprint or a set of principles for thinking about how we organize capabilities, skills, technology, and so on inside organizations in the context of a fast flow of value. The Teams for these patterns effectively came out of IT and technology in terms of the kind of DevOps movement and software delivery in the sort of twenty tens and then we evolved the ideas in in around from about 2013, '22 to 2018 when writing the book, because it turned out that a high velocity software delivery actually solved a whole load of problems in the organizational operating model space. And there's also reason for that partly because people involved in building software, many people are thinking about things like boundaries, interfaces, things like this, which actually turns out you could apply to an organization operating model, very, very valuably applies to an organization operating model. So, like, some of these patterns were kind of experimented with and and discovered inside, like, software delivery initially. And in the last few years, what we've been doing is applying these patterns outside of IT and software delivery as well. And, we've we come up with terminology and types of teams and types of team interaction modes and that kind of a whole mindset for thinking about how you decide how to use technology to enable you or to help you with value delivery. If it's knowledge work in general, then Teams forty is is a good fit for thinking about that. Yeah, perfect. Thanks a lot. And, Tahira, that's very good recap of what we've been doing in the last year. So I have a question which relates to AI, obviously, because right now the teams and the companies and the products and everything literally is changing, impacted by AI. So do you see the AI transformation and generally the AI age we are at already changing their team topologies, approaches to the teams, and approaches to the software development, or it's a bit too early to apply that to the enterprises? That's a great question. I think the answer is kind of yes and no. What AI is doing is amplifying practices whether they're good or bad. So a bad approach to AI would be to have in the case of software, delivery, the bad a bad example would be to have, AI generate millions and millions of lines of code, which no one understands, and then you have to pass to a separate testing team to try and work out what's going on before you deploy it. That's going back to the nineties. That that's not a sensible approach, but somehow lots of organizations have kind of found themselves in that position because they're not really thinking about what value is. They're not really thinking about now is is a million lines of code valuable, or what does it do for the value consumer? Oh, we're not really thought about that. So there's some organizations that are falling into patterns which actually don't look very good at all and not gonna actually produce an usual business outcome. So we're starting to see this in industry report industry reports. So Goldman Sachs released a report just a couple of days ago saying that basic AI seems to have added almost nothing to The US economy in the last, in the last year, which is quite quite an an impressive or quite a a huge sort of red flag, really, a warning sign that, like, the way in which AI is is being used in organizations is just it's not focused on value effectively. It is it's focused. It's being used as, like, a shiny new toy in some cases. If if we wanna find good uses of, like, AI inside organizations, then we can go back to the team's reporting principles of end to end value flow being the team being good stewards of that value flow on an ongoing basis, whether it's building a product or it's building us, like an online service or whatever, and thinking about how we manage come to load as part of that. And by using those kind of principles, we can then start to predict some ways of using AI which actually help. In other words, we want to avoid these handoffs. We don't want to overload people with a huge amount of new stuff to learn or information to digest or process or something. If we keep those two those two core principles in place, rapid value flow and managed cognitive load for the people working in that space, then we can, like, work out what what does a sensible approach to, like AI assisted software delivery look like. So the the short version is whether AI really changes things depends on the the kind of fundamental principles that the organization is using to set up capabilities and teams in the first place. If they just think it's about generating lots of code, then they're gonna fall down into into a massive, like, swamp of failure, basically, because that's the point is not to generate lots of code. If they're thinking about value flow and empowering teams to look after things on an ongoing basis, they'll be in a great place for that. And this is this is definitely what we're seeing with organizations that we work with. Yeah. And if you look at that from the year side of the year, JetBrains has their developer centric organization. That's what we see as well. And so your AI and all the generative AI tools and agents, they often, of course, generate a lot of code for you, but very rarely they're gonna tell you, okay, you need to remove this part of the code, you need to refactor that and so on. So that's just not the state of the technology we are in at this point, and that's where we see. In fact, the very good work of the new AI agents and the new GenAI tools together with the more deterministic legacy software, which would be the quality analysis, and that would be the refactorings and all of those things. So that's where it all comes together. But we see that it's been very tough on the teams because all of this additional generated code, of the AI slop in some cases, that just adds a lot of cognitive load. That's something you're talking a lot in the book as well. Cognitive load on the individuals, but also cognitive load on the teams. And so it seems that AI is not exactly improving the situation, at least not at this point. So how do you see that from your side? Do we see more cognitive load on the teams and the individuals, or it's somehow already alternated through the introduction of the AI? Because know that a lot of companies try to save on the cognitive load through their, let's say, summarization of all other features of the AI models. But from our stats, it doesn't seem to be quite there. Yeah. Great question. So let's just be just refine the question slightly. So cognitive load in itself is neither good or bad. Like, it's it's cognitive load that is not related to the mission or the the key focus of the team that then becomes something we wanna question and and look to maybe move somewhere else. So in the book, we call, like, strangest conch of load. We're probably gonna adopt adopt some slightly different terminology in in the next book. But the key principle there is if we have a team that is focused on a particular area, let's say a domain or service or or part of a product or something, we can then more easily say, okay, what are the things that that team needs to think about that are valuable for working that area? Well, if they're doing, let's say, banking payments, well, that team needs to know about how banking payments work. They need to know about reconciliation. They need to know about all of the swift international banking system or whatever it is. They need to know about that stuff. You actually want an amount of cognitive load on that team. They would we want them to keep that stuff in their heads. So that's, if you like, kind of a good flavored cognitive load. We want them to have that in their heads so that they can focus on the domain in hand. But what we don't want is we don't want them to be having to think about how to configure this deployment tool or how to, how to collect the application logs from a live service and bring them like we don't want to think about that stuff. That's just extraneous to to mission effectively. So, again, using that framing, then we can be a little bit more refined about how we think about AI. So we've, we've been speaking to, a couple of tools vendors in in the kind of, software operation space which are using AI to help, incident triage. So help shorten the time to understanding, like, why a particular incident has happened. That's a great use because then you're empowering the the team of engineers or people building our product. So you're you're shortening the time to their understanding of where to look for the resolution of that problem. Brilliant. But that is framed in terms of empowering that team. And you likewise might have AI doing some heavy lifting around maybe refactoring or, bringing some insights about an older code base or about, what it was stuff like this. Again, if if the focus is on is on, empowering that team to properly be good stewards of that domain or that product or that solution, then you're in a good place. But if it's just a case of just use loads of AI in your work and demonstrate that you're you're using it a 100 times a day, what's the point of that? Like, this it makes no sense. Yes. So it's basically running, running, running without thinking without a strategy and the strategic employment of AI in that sense. And, actually, some of the things you're talking about remind me of the experience with the switch from developer productivity as a term to the developer experience. Because if you think about the productivity, you know, like old legacy, probably in a bad way, understanding that you might want, as a part of the developer productivity increase exercise, to try to get as many lines of code out of a single developer you can. But then you realize that, yes, you can totally do that. You can optimize to the number of the lines of code or number of features delivered, but then you realize that the developers would burn out because they cannot handle it anymore and they cannot maintain it anymore. So that's where you switch to the developer experience, where you actually design the entire system to be sustainable, not just to maximize one single metric, which would be the throughput of the year, developer to the lines of code. So it's like, seems with AI, quite some similar things need to happen so that companies employ that strategically and change their approach. Would you agree to that? Definitely. I mean, I would say, there's one specific point that that I wish you could come back on this, like speaking of someone who said they used to write code. Most most organizations will be better off writing as little code as possible. It might be a little bit of difficult thing for for jet planes to get behind, but, really, like, if you think about it from a security perspective, the attack surface area, the more code there is, the more likely you're gonna get vulnerabilities. So to some extent, and the more code there is, the harder it is to maintain and and and reshape and change and validate and and attest and all of this this kind of stuff. So from a very real perspective, certainly for regulated industries, but generally speaking for everyone, the the the the lower the amount of code you've got, the less code you've the better. But, yeah, more fundamentally, like organizations, many organizations would benefit from actually genuinely defining and understanding what are the multiple flows of value in the organization because then they would realize, ah, to meet this need over this to meet this customer need over here, we only need to do this small thing here. One specific use of AI in this space actually, if we can get it right, if organizations can get it right, is AI can prototype a whole load of different scenarios, run them against synthetic users, get some actual sensible data back saying, well, actually, most users probably don't want most of this. So therefore, what we're gonna do is only focus on the stuff that's truly valuable. Yeah. That's that's a very interesting discussion. And on the topic of the developer experience and the experience of the developer tooling, one of the things JetBrains has been investing a lot is the unification of the experience for the for the developers, because we try to get the developer in the context of the single tool, which is the integrated development environment like IntelliJ or or others. And then we try to get all of the tools integrated and connected. So we do the same for AI agents, we do the same for the models from different providers, and we give the developers the freedom to choose what they wanna work with within the IDE. So with that, we try to achieve their reduced cost of switching the context, basically, so reducing the cognitive load. Do you see that with the current state of the market, because we see all of those tools popping up in the market, Do you see that it's it's been a bit of a negative trend that there are so many AI AI approaches, AI tools, developers need to jump around, rather than rather than spending time in in the in the context, in the flow? Developers are a kind of single space in in which to kind of work and understand and reason about what they're doing feels to me to be a good thing rather than having to kind of pull together lots of tiny little tools. But there's one, so, like, having all that stuff in integrated inside a single ID makes a lot of sense to me. There there's one specific thing about multiple different AI models, which is really interesting, particularly bringing those into, like, an an an development environment. The one thing which AI is actually helping within this space. So let's say got a developer, they've got seven years experience, pretty switched on, they get it, they've they understand the nature of of the problem, and they they're setting about, like, you know, encoding it in in software. So writing the code. But this so before AI, you're you're leaning on their one perspective, let's say, or if they're pairing with somebody else, they'll do a shared perspective or if they're doing ensemble programming, you've got a team perspective on that thing. But it's still there is some multiple different perspectives at play there, but what you can do with AI, obviously, is create quite a wide variety of very different perspectives. So you actually the the the the different tools are doing cogeneration, lot of different kind of, like, bias and different models and things like this. We'll come up with different kind of solutions. And then crucially, if we can then take, say, five or six different potential solutions, different patterns, because there's there's also different engineering. Right? There's also different ways to solve a problem. There's no, like there's some bad ways, but there's no, like, often, there's no, like, perfect right way to solve a problem. One thing AI can do and and is doing is presenting these options, We've got five or six different options to solve this particular problem. Which one is best? Well, now we can actually use additional tooling to assess those five or six different options from multiple different perspectives. And in particular, we can assess it from the perspective of like code based health, the health of the code base in terms of, how well, what does a coupling look like, how easy is it to change, Does it reduce, like, some kind of, other dependencies and so on and so on? Is it easier to read? All that kind of stuff. We can actually assess that before we make our choice about how we're gonna implement evolving over time. That links directly that kind of signal, code based health, because it's a multidimensional signal. Right? The the one that they use. And it links directly to, cost of change, and therefore, like, how quickly we're gonna get stuff out the door. And then those kind of metrics are then very interesting to people like the COO or the CFO. You're connecting options for code through to through to actual, like, business stakeholders who care about the financial and operational aspects of of choices that we're making right down here in the go base. Yeah. That's very powerful, and it seems like a lot of a lot of major impact on the enterprises and the companies. And one of the ideas that you have, one of the key ideas that you have in the book was also about the breaking down the monoliths and monoliths in in a sense of the architecture of the application, but also it seems like in the in the sense of the Teams as well, and the team topology side. And there, if you talk about the software development right now, we see two different camps. The first camp is more like enterprises that we are gonna continue coding, and we are gonna apply AI here and there, but we're gonna be very careful in moving slowly. At the same time, other companies on the startups, SMB sites, where you would also sometimes have the monoliths, they tend towards the idea of let's wipe code or let's just rewrite the application from scratch and just redesign that sort of like different approaches, either the evolution and the breaking down monolith manually, and another one going through AI and using the modern AI tools to do that. Do you see any successful cases in the complex system that you would be able to apply AI just to break down those monoliths or it's more like, still more likely a human effort? That's a really good question. So, I think the use of LLM generative based AI is starting to help in that space. But, we've got to be a little bit careful because there's no real understanding behind, the current set of AI technologies. Now there there is some work on genuine, genuinely intelligent AI, but it's it's not in the current crop of LLM based, transformer based technology. So the transformer based stuff is just matching on tokens and so on, and there's a danger that you actually bring together two different concepts that are that look the same in terms of a token, in terms of the spelling, but actually very different. So that's what domain driven design was brought in. You know, 2004, Eric Evans brought the the Blue Book. All that stuff is still and all that stuff is still relevant and, in fact, is even more important now because we need to make sure that when we're plugging AI into the system, it's not accidentally coupling things together and creating incorrect associations. Never mind just monolith, but actually coupling things together that shouldn't be together. Humans know that this version of an order is different from that version of an order or choose an order concepts like loads of systems. They've got multiple different versions of of what an order means. But but, naively, an LLM based AI solution can find those two references in the code base and go, oh, it's the same thing. It's mission together and suddenly you've you've actually lost domain fidelity. So I think there's there's a danger there of some of that tooling. It'll certainly get better over time. But, the kind of the the the upside of of in this space is using using AI to to, like to summarize and and find detect aspects of a code base that exist that perhaps humans perhaps weren't obvious to humans. By looking at relationships between, code written and the teams that worked on it or the people that worked on it or looking at, coupling or looking at a whole bunch of other things, which actually are way easier to now to to to do using, like, generative AI techniques. It really depends on the domain, depends on the majority of the organization in AI adoption and many other things. So one of the trends we see is that the developers, but in reality, other roles as well. When exposed to a lot of AI in their life, they're starting to also, not really take over, but kinda do some tasks of the adjacent roles. So for example, your developer would be doing a bit of more product management, a bit of more UIUX design just because it's so easy with AI. That's one of the trends. It's like you kinda get the blurred lines of the scope between the AI developer and some other team members. And the second trend we see is also that the developer is starting to be more like the orchestrator of the agents, of the AI agents working for them. And they they are more in control of code reviews and many other things. Do you see those trends? Are there any trends other trends we are missing in the role of the teams and in the role of the software developers in general? And do you see any transformation of the teams in regards to the team topology with their specific application of the AI in the life of software developers? So a few things there. The first thing is AI is expanding the remit of what a group of people can do. And if that helps them to be better stewards of that product or service, brilliant. That's that's a good good place to get to. The there's there's a slight danger. Well, I think it's a I think it's a big danger that some organizations are reducing the the organization is shrinking the size of teams are focusing on things because they can say, I can just use a single engineer or a couple of engineers and then everyone else doesn't need to be there. The danger with that is that you're losing a diversity of perspective and experience and those organizations are in danger of, ending up being quite blinkered in terms of the solutions that they're coming up with because they're assuming that the AI systems are somehow either neutral or have a lot of great different perspectives, but that's not true. So if you're shrinking teams, you are losing potentially, you're losing innovation capability because you're not actually don't have enough diversity of perspective inside the the group of people who are working on that. Yeah. Totally understandable. And in regards to the four types of the teams in the Team Topology book that you rely on, there is the value streamlines, then there is the enabling, which is basically enabling the capability of other teams. There is the specialized, complicated subsystem team, then there is a platform team, which basically builds the platform and provides the APIs to others. And looking at those four types of teams, it seems that they are very much specialized and, like, specific for different things and see the AI capabilities might be helping or not helping in different magnitude there. Do you see the tools we've been talking about helping some one particular type of the teams or helping or not helping another. How do you see that in terms of the evolution of the team and the team capability? I think it'll be using it can be used across all, and some organizations are starting to use it across all as well. So we've talked a lot about kind of stream alliance teams, so, like, ongoing, steward of of value in a particular area, like a product or what have you. Enabling teams are really interesting. So enabling teams don't build anything themselves. What they what they're doing is going out across the organization, helping to uplift the capabilities inside the streamlined teams principally. But one thing that, is now starting to emerge, that's kind of AI enabled or AI based is tooling that looks at multiple signals in the organization, things like Slack messages or Teams messages, stuff in, different code repositories and, say Jira tickets or ServiceNow or have you pulls information together and, flags problems much sooner. So raises so I said, hey. Look. There's a team over here or these 17 teams are all struggling with the same thing. Great. The enabling team of people can go out and work with those 17 teams, but they can detect that much sooner. So much more rapid detection of problems, a much more kind of clustering of problems and maybe even some some upfront analysis of it could be sentiments, it could be, like, word clustering. So these teams have all got are all talking about this kind of problem here in a way which suggests that they don't really understand it. Right? The enabling team can go and target them much more quickly, taking much more targeted intervention. Platform groupings or what have you, they're providing multiple services out to lots of different teams. One of the key concepts in team depologies is for a platform to detect or streamline team or in platform combination to detect when something that should be consumed as a service is not really that's that that capability is not really being provided as a service. Let me give you an example. If a Streamline's team is having to go backwards and forwards by email or Jira ticket or Slack message or whatever to the platform people in the platform group saying, hey, how does this thing work? How do we configure this? Like, this this parameter doesn't seem to work properly here, blah blah blah. That's not really as a service because it should just be consumable like an API or something like that. So there's so that way in the Teams' body's book, one of the key concepts is listen for that signal, which says something that used to work really well as a service is now no longer working as a service. That interaction mode is effectively changed into collaboration. Let's make that more, let's make that more intentional. And again, AI, generative AI can be used to detect that kind of problem sooner and suggest, and I've seen this in tools that are in beta at the moment, listen to those signals and suggest, hey, it looks like you should flip from you need to flip into collaboration mode now by making more intentional, work out why there's now a problem, takes say two or three days to work that through, and then hopefully the service improves and you can consume it again as a service. So I think AI can be used when we're thinking about these patterns, AI is going to be used often for much more rapid kind of triage and pinpointing and diagnosis of where some of these organizational problems are. Yep. Yep. That makes a lot of sense. Totally. And I have a couple of questions not AI related. So just to get us distracted a bit towards the human parts of the AI team topologies and the operating the software development teams. So the first one relates to the enabling teams, which you've been already doing quite a lot in the answer to the previous question. So in many cases I've seen, and that's both JetBrains and non JetBrains experience, is that's kind of like the enabling team which is coming over to, let's say, the value stream specific team and StreamAlign team, rather, and brings a new capability. And in many cases, they might be seen as a distraction. They might be seen as the know it all folks coming over and teaching you something. And there is a very big work needed in order to integrate the enabling teams so that they deliver value and really help developers develop this capability. And then there is a moment when this team leaves because the capability is developed and the enabling team is going on their next job of enabling some other teams to get the capabilities. So do you see that as an industry problem? What are the good practices in making sure that there is a safe and good environment for the enabling teams to develop the capabilities on top of the streamlined or the complex subsystem teams? So the first thing in that space is is that people inside enabling teams are, should be kind of experts. They're bringing a lot of expertise. The challenge is, as humans, often people with expertise, they've developed or they have a kind of how can I put it politely? They're they're coming with a bit of ego basically. They're saying, oh, I I I know all about this and all about that. And and the problem with that is as soon as you've got the ego inside the Skelton's team, then those people are, you know, it feels toxic. So you there's a lot of work needed to to make sure that the people inside enabling teams, yes, they've got the expertise, but they also have training effectively and learning on how to effectively facilitate things. So we're often looking for enabling teams to have a blend of people who can learn how to work together and relearn how to actually share their expertise in a way that then gets adopted. And using some metrics like that can be really valuable. So, yes, you've got some great new ideas about, I don't know, cloud scaling or automated compliance or whatever it is. The success criteria for the enabling team is really about how rapidly and extensively those ideas were adopted. Because if for some reason other teams are not adopting them, it's actually your fault as an enabling team really to an extent. Like, you should make it really compelling. Going away from the platform teams, in this regard. So the very typical situation in an organization that at some point you realize that something should be a platform, then you extract it, then you create this platform, then this platform starts to serve different teams and provide this platform layer. And then you end up in a situation when the capacity of the development on the platform is not enough, and then you basically can end up in a situation that the stream stream aligned team or a complicated subsystem team would just go ahead and either create their own platform or they just go out and purchase some other platform from the market, which would deliver value to them quicker. So it's like basically not waiting for the established platform to deliver the value for them just because they need to run faster. Do you see that as a typical problem? Do you see that as as something which can be fixed in the organization or it's just inevitable? I actually don't see it as a problem, which might surprise you in this sense. So it is definitely appears to be a problem in lots of large organizations. So for example, we're talking to multiple different, well, UK and global banks at the moment. In in in any any large organization like that, you've got multiple, multiple initiatives all trying to do the same thing. Because as you said, the the teams working closer to the customer don't feel like they can wait. They build it themselves, but then you've got duplication. They they would love to just consume it from from somewhere more central if you like or like a platform of some kind, but they don't really trust that platform because all sorts of reasons. Their relationship is too big, they they can't have enough visibility, they the way in which the platform interacts with them is not very appealing and so on and so on. So you end up in this situation. Right? We were talking to one just recently where they've got, I think it's 70 different implementations of a thing where ideally there are only two or three. And and and but here's the thing. At scale, you will always have an aspect of that. You will not be able to get away from it. And actually that doesn't need to be a bad thing. When technology and compliance and markets are changing so quickly, you actually want, you deliberately want some distributed and duplicated innovation because you want to discover that the the good patterns as quickly as possible. What most organizations miss and lack, what most most organizations don't have is the organizational scanning and innovation diffusion to to spot the the the innovations and and the the implementation is a good version. Spotlight is a shine a light on it. Help the people who are who are building it to talk about it in a way which is appealing, and then create a bit of FOMO, a little bit of fear of missing out friendly FOMO. Right? Like, make the other parts of the organization go, wow, that's a really great version of that. Why don't we just use that version? And then that version can be can be then harvested into a platform. And then so you've got distributed kind of execution innovation, but then the harvesting into a central platform, and it gets, like a virtuous cycle off the back of that, with innovation at the edge, but then some harvesting and then the kind of operationalizing, if you like. So we're making this this version of the service just much more consumable and scalable than anything else. All innovation does not have to happen inside the platform area initially. It can happen outside and we bring it in, but that needs a very intentional dynamic to make that stuff happen. It it does happen in in some organizations that are more switched on, but this is missing in in many, many, many organizations. Yeah. So, basically, that would mean that, you know, this concept, Shadow IT, Shadow AI, plus, in this case, Shadow innovation. And then you wanna have the framework which is gonna be capturing that and just kinda elevating that to be this next standard. And then the next development is gonna be on top of that. So it's basically just the increasing the velocity of those things coming to the organization. So yeah, that's very smart. Yeah. Yeah, so the last question for today, and thanks a lot for this amazing conversation, last question from my side is on the advice to the enterprise companies and the enterprise developers who would like to rethink their team structure, team topology based on the current changes in the AI and changes in the software development practice in general. What would you recommend them? How would you recommend them to start? So I think fundamentally that AI doesn't really change anything in this space. What it is, it does provide some different options, but like I said before, fundamentally, the the the the mental model I've got is how do we empower groups of people to be good stewards of value delivery on an ongoing basis. The extra thing on top of that is the thing I've just mentioned a little bit ago in the context of innovation detection detection and things, but there's more general thing which is if a group of people of a team has done something which actually is outstanding, let's find that, let's promote it, let's help them to tell that story, let's help them feel effective and help other people to see that. But that means active knowledge diffusion across the organization. Most organizations don't do anything like that. We need to make that diffusion of knowledge active and spotlight it and turn, develop this dynamic of, kind of whole organizational sort of learning and sharing, which some organizations do amazingly. We don't even just need structure and and interactions between teams. We need an active approach to sharing knowledge and diffusing innovation across the organization. And that's the thing which which is often missing. So that's the thing I would definitely recommend that any organization look at the be honest with yourselves. How actively are you looking for good practices and innovation and actively sharing that and setting up the conditions so that other groups and teams want to adopt these different things. That brings us to a very interesting point, that everything that we are changing in organizations has to be designed. Right? So that comes to the team topology, comes to the process of the communication, that comes to the process of innovation, and that comes to the internal conferences and all kinds of activities. And I'd say that's a very powerful insight because all of this evolution is gonna happen in the company anyways. But if you don't design it, then don't control it. Don't see where it's going. Yes. And that's very powerful. Thanks a lot, and I would definitely recommend all the folks on the stream to read the Team Topologies and look at all of the awesome use cases Matthew and his co authors put there. So thanks a lot, Matthew, for being with us today here. That was very insightful for me. Thank you. Super. Thank you so much.