 Hello everyone, I'm gonna go ahead and get started and if people are coming in then They'll just have to catch up So this talk that I'm going to do These aren't the only five things you need to do, but they are five things that are I Chose these because it gets you to think about a different perspective on scaling So We'll go through this pretty quickly There are references and hyperlinks and all that in the slide materials themselves So if you have a chance to look at those later, there's some additional things to learn so the Five things that you need to think about to when you think about scaling your organization It's not really related to things like Scaling frameworks or processes But what most organizations find is that when they go to scale agile the biggest challenge is culture and So these five different dimensions here all sort of directed at the cultural dimension and so in order Support and protect agile values with strong leadership help teams and stakeholders to self-organize Manage toward outcomes not output Systematically really remove waste and then prove through feedback. So I'm going to talk about each one of these briefly Again, you know, this is a lot to cover in 45 minutes. So if I'm if I move too fast We've got probably time for questions at the end so in the As most organizations look at scaling the first thing I like to ask when I'm talking to them is essentially why do you want to scale and So when you consider some of the the reasons why organizations are wanting to choose agile a lot of times Organizations will say things like what we want. We want to improve cycle time we want to improve our responsiveness to the market and the reason behind that is Illustrated by some of the points in this slide is that you know, if you look at uber, you know, it's the largest taxi company own snowcars or Apple and Google are the largest Basically software vendors the app stores or you know have the most revenue going through them. They don't develop most of those apps Netflix is the world's largest movie distributor. They don't have any theaters So all of these things have more or less happened in the last ten years the iPhone just basically self-elaborated its ten-year anniversary last year and So all of and actually didn't have apps for the first year So all of these things have happened relatively quickly. It's The world is changing and most of us are here because of that the thing to also think about is These companies were once regarded as the leaders in their industries and they regarded themselves as basically invulnerable to a cat they had huge market shares and yet in a relatively small period of time in some cases just years they went from dominant in their positions like blackberry You know when the when the iPhone first came out everybody said well, you know, it doesn't have a keyboard It's never going to sell for the business community Blackberry nearly went out of business just a few years later So the fate the fate fortunes of the organizations can change pretty rapidly and one person's threat is another person's opportunity So that's the motivation behind this and why it's important to know the motivation is that the cultural change That has to happen in order to scale agile in an organization really has to start with why are we doing this? What's in what's important? How are we aligning to some larger goal and then teams at basically Self-organizing cross-functional teams can align to those goals and make better decisions by understanding the goals better So you can think about these organizations your organizations are even from that org you know, we're all sort of squeezed in between competitors or alternatives to our solution and the customers or the users of that solution so There's two different dynamics and organizations are trying to be more responsive Now change is hard and I've paraphrased something by Peter Drucker here Peter Drucker originally said Culture eats process for breakfast or there's a variety of different ways of looking at this Culture also eats agile for breakfast and it establishes Essentially, there's a cultural inertia in most organizations to continue doing the things that you've done in the past and the culture in a sense inoculates the organization against certain kinds of change and what we have to do is figure out a way to change that dynamic so that the People in the organization are now focused on a new goal. So the I think this is something from Buckminster Fuller, but there are variations on it is that you can never create you can never basically destroy an old order What you have to do is create a new order and then get people to move over to this. So From the perspective of this to think about it Peter Senghi I was talking to my colleague new guest just before this about Peter Senghi and the fifth discipline But Peter observed that people don't resist change They resist being changed So if they feel like they're part of the change, they're much more likely to participate in in that So having that focus on goals that you know, this is a new goal We can only achieve this by adopting agile practices and having everybody really strongly believe that is Really essential to having agile being adopted if they feel like it's just something they're complying with or just something that they They they're being told to do Because it's the latest thing or because you know people the organization wants to reduce cost then they don't get as motivated so the key thing to think about is that a Lot of people I think make the mistake of talking about well We need to change people's mindset and they act like well, you know, we've got it We have to convince them that they want to work in a new way and we've got to win their hearts and minds but When you look at a number of different studies The the data says that What you actually need to do is get people to work in a different way and gradually their minds and the culture and the belief system Re-oriented self to the new way of working Another way of putting this is that you can in a sense lecture people all you want about the value of empiricism And the value of doing short delivery cycles and getting information back But if all you've ever experienced is a traditional Waterfall delivery process or relatively long cycles you don't really understand what that means you keep translating it back into terms That you understand and you say oh we get feedback all the time we get feedback on requirements We get feedback on design we get feedback architecture and we get feedback all the time It's not the same kind of feedback, but until you experience What feedback and scrum means you you really don't have an understanding of that So the most important thing is to get people to work in a different way and then gradually the culture follows along with that now So so what the role that leaders play in this transformation is that leaders help establish those shared goals they help the organization align around those goals and And basically create a compelling reason to change the second piece of it is that leaders play a role in making it safe to change Making taking the risk out of it saying it's okay to fail It's okay to not Achieve what you set out to achieve if you learn something from it and that's really the key And we none of us like the word failure But the reality is that you know the old saying goes you know good judgment comes from experience Most of which comes from bad judgment So you know you're going to have to make some mistakes and things don't work out the way that you expected And the real problem with the traditional delivery process is that you don't get feedback early enough to figure out you're doing the wrong thing So the third thing is that leaders actually model the change by by showing people a different way of work working and demonstrating that Then they essentially serve as role models for the rest of the organization. So That's sort of the first thing. So leaders really are the key to getting this cultural change to happen Now, you know, this is sort of point number one There's still four other points. So it's that's necessary, but it's not completely sufficient so the second thing leaders have to do in addition to those things is that they have to help teams and the stakeholders to self-organize and You know anyone who's been through a scrum class or been through other agile agile practices You you know that self-organization is really important But a lot of times organ people think well that that's the scrum team doing that scrum team So self-organizing and the reality is that the entire business has to self-organize or at least the area Of the product you're delivering So you can't you can't really do some well if you have the business off doing Detailed requirements documents and working in six month cycles and long-term product planning and ignoring all the feedback They can get from every single sprint so one of the things to think about is that John Cotter is one of his is a professor at Harvard written lots of books on organizational change and He makes the observation that the organizational structure that we use today was designed to solve a different problem than what we're trying to do with agile and That different problem basically had to do with relatively poorly trained workers Who didn't have a lot of autonomy? They weren't cross-functional. They're essentially working on repetitive tasks, which are relatively easy to find But when you look at a dynamic situation that model doesn't work a lot of people think that the military is organized in a Hierarchical manner, but actually going all the way back to Napoleon that there's essentially a high degree of Cross-functionality and autonomy because when you're in a battlefield situation you have to make decisions on the spot You can't go clear it with somebody who may or may not be you know might be a miles away, so That's one thing to think about your organizational structure is it of most organizations isn't really optimized to work in an agile way Now what's different and what enables us to think about a new kind of organizational structure? That's much more in a sense cross-functional and self-organizing cohesive is that There's another piece essentially from behavioral psychology That's illustrated in this book by Dan Pink and there's a URL really nice short video to watch there But but his key message in this in drive is essentially that We aren't motivated by money. We're not voted. We're not motivated by Promotions. We're not motivated by all these other things. We're actually motivated by having a strong sense of autonomy in what we do Feeling that you know, I'm very competent. I know what to do You know, I have a strong mastery over what I'm working on a strong mastery over over my the expertise that I exhibit and I'm working towards something that's worth working on and But it's only when you have relatively simple mechanical tasks that paying people more for producing more is Motivated so one of the theories behind that traditional organization is is essentially wrong It doesn't reflect what we've now learned about about psychology So the challenge that leaders have is to essentially free the people from the structure of that existing organization and leverage the intrinsic motivation that in a sense bribes everybody So this traditional organization you can think of that as being very hierarchical CEO at the top BPs middle managers line managers finally you get employees and all the way at the bottom if you can read that our customers or you know if you're developing internal application users and to get the benefits of these self-organizing autonomous teams you really want to invert that and And sometimes you know so interesting thing as we refer to this as bottom-up intelligence that you know The people at the bottom of the organization who are working closest to customers have the best Insight into what to do for those customers. Well here, you know just for for visualization purposes I put customers at the top because in a sense the customers are the top priority And then the people who serve those customers directly are the next highest priority And then managers on the CEO So there's a whole bank of literature now that talks about serving leadership and the value of supporting those those autonomous cross-functional teams and So this is starting to take hold You know if you pick up things like MIT Sloan Journal or Harvard Business Review you see lots of articles today about serving leadership and so that this model is gradually shifting and there's much more awareness that In a sense to really get the most out of the people in our organization and deliver the most value We have to let people do their best work and figure out how to free them to do that work even better so that and I said earlier that this transformation is Not just for the scrum team and it's not just for the product owner, but it's also for all the stakeholders So everybody who is working with the team even in an extended way needs to understand and buy into the values of Working in this new way to make this work most effectively If they're if the stakeholders are asking well, you know What's what's our project plan? And I want to see be called milestones and where are we against the milestones or even even the question of you know I hear this a lot Are we going to get all the features that we want by this particular date for this particular cost? And I'll talk a little bit about why that's not even the right question to ask But if the stakeholders are asking questions like that then the motivation of a team Basically just collapses sort of like the air going out of a balloon So everybody needs to really buy into this model now not everybody in the whole organization But at least everybody working on the product that the team's working on So the third point which I started to touch upon is that the question of am I going to get all the features that I want buy a certain date isn't the right question to ask and The reason for that is illustrated by this chart so this is based on a study that a researcher at Stanford did in collaboration with Microsoft and they used to Bing platform because they're basically doing a Continuous delivery model online softwares of service very easy to do new releases and measure the results of that and What they found is that of ideas not just features But ideas that they came up with for improving the overall customer experience or improving business results is that they found that a third of the ideas Basically improved the outcome a third of the ideas did nothing and a third of the ideas actually made things worse Now that's pretty sobering if you think about it because it says that this is Microsoft So arguably they really know what they're doing. They're they're one of the best managed organizations in the world for delivering software and If they are spending two-thirds of their effort Delivering things that have no business value. What does that say about just an average company? So That's sort of one thing to think about and and what they found was that there wasn't a correlation between how much experience somebody had or where they stood in the organization or You know what their rank was or anything Everybody on the team had good ideas at various points and everybody had bad ideas at various Points and so the key thing is to be able to deliver quickly Measure the result and then quickly adapt So, you know we we talk in scum about inspecting and adapting and this is really key and the faster You can do that the better your business results That was one of the key learnings that I had when I was working as a as an industry analyst of forest research was that there's a strong correlation between the speed of feedback or cycle time and overall business performance so The thing to think about it's a good little mnemonic You have hippos in India, right? So I don't mean those kind of hippos though what I mean are highly paid person's opinions and So that there was actually a slightly negative correlation between Somebody's rank in the organization and the quality of the ideas they came up with because they're further and further away from the customer So, you know you get some sales VP comes in and you know I just talked to you know my counterpart over at XYZ company and they told me that you know They absolutely need this particular feature. Well, what usually happens is the team kills itself delivering that feature and Then they they ask the customer well, you know, how did you like that? My customer says what I've never I don't use that It's not valuable to me or they you know some variation on that to be their thing And and so the problem is is that there's lots of theories and and again, they're not bad They're not you know, they're just theories and you have to actually deliver something measure the result and then improve So, you know, you were a hippos highly paid person's opinions so a better way to work is that you look at what outcomes are we trying to achieve you step back and say what's the customer situation what's their current alternative and What where would they like to be with that? What can we do to improve that particular outcome that because that the customer or Again, you can look at internal users the same way, you know, where are they today? What would they like to do or what not what would they like to do? But what outcome would they like to achieve that they can achieve today and Then you come up with ideas and this is product owners through this Team members could do this stakeholders could do this come up with ideas Frame them frame them as experiments or hypotheses Develop some you know a minimum Essentially the minimum amount you need to test that hypothesis and then you know you get feedback that says that was good Let's do more of that. So Focusing on outcomes is incredibly important to achieving better results So the way to think about this is that you can look at personas and and Out of that persona you can look at well what outcomes do they want to achieve? What's the current experience the satisfaction gap is essentially, you know the difference between current desired state and The opportunity from an economic standpoint is essentially the value of closing that gap And so you can use this concept to manage your portfolios to decide how you want to spend money You look at where are the biggest gaps? Well, we should spend money on closing those gaps How do we do how do we close those gaps? Well, we form experiments and and figure out what the best approach is so So that's that's the idea on that now as you as you deliver those things as you try to improve your cycle time and improve the time it takes to get feedback there's lots of waste in our processes and We have to figure out ways to remove those and leaders You know at scrum masters help with that the team helps with that Leaders in the organization can help help remove these various kinds of impediments And so we think about what gets hard about scaling is we start to you know add teams The teams are working pretty well, you know, we maybe get a third team that works, okay But as we add other teams we start to get a decline in the overall productivity And the reason for that is that we end up having various kinds of impediments and barriers that Prevent the team from working as well as they can so in a lot of cases these are various kinds of cross-team dependencies and Steve Porter and I are going to be delivering a workshop over the weekend where we're going to talk about how you can use the Use something we've developed called nexus that to help remove costing dependency But what however you do it you have to figure out what are dependencies? What are the bottlenecks? What are the barriers and and how do we remove those? so these cross-team dependencies end up basically Exploding and you know if you've got poorly Basically poorly refined product backlog items that involve lots of different teams to get something done You're going to have lots of different handoffs. You're going to have wait time in there It you might refine the backlog items so that the backlog items are restricted to one team and they don't have any dependencies That would be a perfect world Reducing them might be it might be the best thing to do so refinement might be it might be an aspect of this another aspect might be Moving to a more modular architecture like using microservices where you've got a high degree of independence between components That's another technique It might simply be you know having dedicated team members instead of having people spread across multiple teams and Having to wait on somebody because they're not available having more cross-team skills So so there's a variety of ways of removing these crossing dependencies and that ends up being one of the keys to scaling Not the only thing we talked about some of the other things, but it but it's a big one especially down at the team level The other thing to look at is you can pull basically a technique out of Lean and look at the at a value stream map and look at you know What are all the steps that it takes to go from an idea to when the customer receives benefit from it? And you can actually measure that benefit so or you know essentially One of that what some people call that measure lead time so Some people call it cycle time. There's a finer fine distinction But the point is that there's a lot of different waste in that overall process It might be waiting for a test environment. It might be waiting for the people doing the test to become available. It might be Waiting for feedback from the customer. It might be having ops actually deploy it It might be you know a whole host of other things and The interesting thing about doing this kind of analysis is that where you think the waste is isn't always where it is an example of that is that number of years ago, I was working with a telecommunications company and They initially brought me in because they said well, we want to automate our build and test automation process So, you know, can you help us with that and I said well, that's great. Sounds sounds good Maybe we could take a little bit of time and just spend a few hours and math out where you're spending the time in the delivery process and As we did that a couple of hours later It became pretty evident that the time wasn't in build and test time was actually waiting for a decision There were lots of places where people waited for decision waiting to get approval for or to deploy to a test environment or waiting for Approval to do this or waiting for feedback from users or waiting for feedback from stakeholders and all of these different different wait time basically added up to 70% of their overall lead time was spent waiting and So we worked with them to try to basically get that number down and we started tackling Individual parts of that problem. There wasn't one single solution that solved that but there were lots of different individual pieces and So that tech using that technique doing doing some value stream mapping trying to figure out where your impediments are You know this might come out of a sprint retrospective or it might be something that you know You spend some time during the sprint to try to figure out If you if you're running into impediments, you're not going to hit for sprinkle So, you know, this is it. This is a great technique for trying to figure out where the waste exists now Look at and it's hard to read that because the color contrast but if we look at industry statistics and how effective organizations are these percentage numbers are based on numbers out of a standish group report and so The you know the average organization is about 50% effective in its collaboration In other words about 50% you know think of it this way half of the meetings that you go to were a waste Probably more than that actually But let's say that you know if half of the meetings are half the interactions that you go to Now you spend hours on a conference call that had as no value to the things that you're working under your teams working on The you know in the case of the what you know You've already seen that let's say a third or in this case 35% of the features that you build are actually valuable So it won't it if you know that number improves You know that that then you might be able to get perhaps 40% or 50% but and then The 30% building new features measures. How much time do you spend doing maintenance and corrective work versus spending new development? So if we run the example And we say you know you've got 8,000 just to make it even numbers. I put you know 8,000 rupees Going into that process. How much do you think you really? What's the in a sense the purchasing power of? That 8,000 rupees coming out in other words, you know if you subtract out all the inefficiencies. What do you end up with? Any ideas or be Yeah, you just multiply so yeah, so it's about 420 Right, so it's it's five and a quarter percent so that's before in a sense you can think of that as almost like a a Inflationary loss in your money, so the $8,000 8,000 rupees that you started with are actually only worth 420 rupees when you when you look at how effective that money spend is that doesn't even say that you're building right thing for the customer Now that's average for most organizations, right? That's so we just did simple in industry multiplication on the math So if the average organization is essentially losing almost 95% of its effectiveness through ineffective practices Then there's huge opportunities for improvement. So this isn't this isn't Data that you look at and go You know life is terrible and and we're just going to give up because it's hopeless actually it's like no There's great opportunity there. We've got you know We could easily improve that number to you know 15 20 30 percent instead of five and a quarter percent by doing a few things Right, so there's huge opportunities, but we have to start focusing on that most organizations don't so The other thing to think about is that in order to remove that waste leaders have to get involved So, you know scrum masters and scrum teams have a lot of autonomy, but within a limited sphere But if you need a dedicated, you know, mainframe test environment so that you can test the application You're working on and you want to do that relatively fast cycles most organizations that I've worked with you know They it's a shared environment and you can't get exclusive access to it It doesn't get cycled frequently and as a result the testing isn't very effective So to solve that problem You've got to go make a business case with some executive and they can maybe help with that So there's a variety of different things that you know back to the executive base where Executives can and need to get involved to solve those problems So the fifth thing is that you know as you do these things You have to improve through getting frequent feedback So this isn't an exercise where you say well Let's take the next six months do our value stream map and improve our process in the meantime We won't actually deliver anything because we have to do process improvement first The best way to do it is actually through frequent feedback Not just of the product but also the process itself so the two challenges in this are first of all building the right thing making sure that you're You're building the right product and the second thing is is to build that product in the right way and So the two ways to basically handle that kind of feedback First of all building the right thing is that if you think about this We kind of do it before in a little bit different way is that you've got some idea You do some work you deliver it out to a customer or a user you measure feedback So you've got some economic value coming back. Maybe you've got some qualitative feedback coming back You've got other other interesting data coming back interesting anecdote on that so one of our Members of our community was working with an organization and he said that you know they be You know he kind of quoted that average Statistics that you know 40 or 50 percent of features developed or never used and this organization is like no you know we're much better at that and Essentially more or less said prove it And they did you know they said okay, we're going to instrument our application They were convinced that they were going to see much higher numbers How high do you think their number was? Features implemented that were actually used 10% So 90% of what they built was not actually being used by the customer now That's not too hard to imagine. You know you take something like let's say PowerPoint here You know I use I I use that a lot for these kind of presentations I use a fraction of what's in there Microsoft Word probably even worse and I've written books and done lots of other things like that So, you know, there's lots of opportunities for improvement But so so an interesting way to frame those experiments to figure out whether you're delivering the right thing I pulled this from a book called in UX by Jeff Goddalf and Josh Sidon is that you frame that and instead of just using the user story format You you frame it a little bit different say, you know We believe that doing this in other words that the feature that you're going to build or a description of the thing You're going to build for these people in other words the personas that you have sort of stepped through this These you know for these people in other words your personas will achieve, you know a particular outcome so you know and We'll know that's true. And this is the important part when this measurement changes because if you can't measure it, it's just all a theory anyway and So lots of lots of scrum teams are doing lots of good things even if they're delivering in the production But they consider done, you know done is when it shipped into production Well actually done is when you get feedback on that thing that you built the right thing So by making your experiments more explicit and say how are we going to measure that? How would we know this is the problem with all goals setting? So, you know, our goal is to do, you know, let's achieve this. Well, how will we know that that happened? Otherwise, you know, if it's if you can't measure it, it's just sort of a platitude so You can use those outcomes to plan the sprints Right, you can you can say well, you know Product owner could say well, you know, here's the goal that I'd like to achieve in the sprint or here's the experiments We want to run in this sprint and the development team can come back and say great, you know, we can do that Or they might come back and say well, we don't think we can do that in the sprint You know, there's too much work to do but could we scale that back a bit? So there's a bit of give and take in the planning process But but effectively using outcomes has a has a more interesting way of planning the sprint and simply going, you know, we're going to deliver this number of stories and and in a sense, so what if you know if you Kind of a side note about what's the right size for a release? Well, the right size for a lit, you know The minimum size for a release has to be essentially one changed outcome for at least one person Hopefully a group of people or a whole persona, but you know, if it doesn't change the outcome It's not worth doing and if it changes more than one outcome, then you essentially you've over-invested in that release So anyway, the outcomes end up being really, you know, simple but pervasive and powerful in the way that you organize the work The second thing is that when you get to the sprint review the question is well, okay We ran this experiment or you know, we set out to deliver this outcome. How do we do? Well, you know, that's we if we set our goals so that we can measure them Then it's it's a pretty easy matter to say well, we either achieve it or we didn't or the answer might come back Well, you know, we don't know. Okay. Well, then in our retrospective We can start to think about well, you know, how do we get better at measuring that? You know, how do we get better at improving our processes to measure that but but outcomes end up being really really an interesting and important way, I think to just Refrain the discussion about what you're trying to achieve So then building the thing right when you know, you can you use your retrospect your sprint retrospectives to say, okay How'd that go? What could we improve? Do did we build the right thing? If we didn't maybe, you know, how can we get better at that if it's you know, we had a lot of waste You know, we stumbled around we didn't collaborate very well. How could we improve that? So there's a variety of ways that you can focus on that continuous improvement process and That's really why we're we're adopting things like scram or Agilent in general anyway That's we want to use a feedback mechanism so that we can continuously improve so to summarize the first thing, you know, the the scaling Might you know often involves lots of changes and processes Changes in the way people work maybe change the roles but we lose sight of you know, if it really becomes a process kind of thing and People think of it as well, you know, we're just changing our processes And it doesn't really involve leadership about achieving some greater goal or the organization Then it kind of falls flat. You know, it just turns into kind of a mechanical scrum And that's not really valuable to anybody it ultimately doesn't isn't sustainable So leadership is really important in helping to establish the right goals and then removing the impediments to achieve those goals then You know, what we want to do In order to scale is we want to get everybody's creativity and energy applied to solving these problems in new and different ways and You know, one of the things that it's easy to lose track of is that, you know, all of us in our personal lives You know, we have you know, everybody has all these all this complexity But you know, we're able to do this on our own, right? There's nobody telling us what to do and how to do it when to do it You know, we can self-organize in our own personal lives pretty effectively But when we come into an organization, sometimes we we inadvertently We think that people, you know, somehow they can't think for themselves and we create an environment in which that becomes a self-fulfilling prophecy so helping the teams and the stakeholders to self-organize and really leverage all that power and energy that people have is usually important and Then focusing on outcomes So it becomes clearer the connection between that goal and the work that people are doing ends up being really key to scaling because it's just It's it's incredibly easy to just get lost in this massive user stories that you're delivering and eventually you start forgetting Why are we doing this? What are we trying to achieve and and leadership doesn't know whether you're actually getting any benefit out of it? It just feels different So that's usually important and then you know as you along that way removing waste and improving through frequent feedback Ends up being really hugely important. So those are the five things. I think are really important in scaling We've got about five minutes or so for questions. So If you've got any then Yeah, so it's it's in some ways, it's it's easy to do Once you get a paradigm shift to happen so a lot of the work that I've done is Around these executive workshops where we help leaders to really understand what motivates people and how they're going to get the best result from working with those people and So helping the leaders understand that, you know, they've got really talented people in the organization who want to do great work but they're often held back by You know sort of the ineffectiveness of the processes, but you they could achieve so much more if if you really kind of Focused on not controlling them and guiding them But rather to get them energized towards solving the right problem. So it's mostly a mindset change in leadership And there's a secondary problem that relates to the middle managers so a lot of times leadership buys into this and The team people the teams think it's great and the middle managers are like, well, what do I do? You know, how do I work and so helping them understand how to become better serving leaders and Getting them to realize that they have a hugely important role in helping their teams and that the value that they add is in this network of relationships that they have with other people in the organization to help get things done and so they sort of go from being Controllers and you know having to kind of keep control on everything. So basically being kind of fixers You know people who can really kind of break loose log jams and be creative about things because they're also Girl, you know, most of them were really talented developers or other things And then they got promoted and now they're kind of stuck in a role that they don't really like either But it pays better and and they like that. So we have to kind of decouple The sort of reward and compensation system and get people to focus on the right things But so it's so what I found once people have a vision for how their lives can be different Then you get them to move toward where they want to be instead of you know Since you know the problem with a lot of especially the middle managers is that the way that we usually talk about the problem is That we talk about all the things they're not going to do You know, you're not going to be managing people you're not going to be telling people to do this You know, you're not going to be doing that and and there's nothing positive in that and it's rather threatening like well What if you know, that's what I do all my day, you know, they're not going to need the sec Actually, look at all those impediments. There are huge numbers of things they can help or to remove We just have to get the focus on that. So it's a mindset change, but it's also helping them to get started and Focus on that problem. Any other questions or comments about two minutes