 Welcome everyone to the systems thinking for happy staff and elite customers by Simon Popsay. And I just start with the short introduction about Simon Popsay. Simon is a lead transformation consultant and is on a mission to help organizations understand and unwind complex and cross functional obstacles. So without any further delay, I would like to hand over to Simon. Thank you Sundari. I wish I had you to introduce me everywhere. You do a good job. Thank you very much. Hello everyone. I think we have a smaller session today. So that's good. So please ask questions. Slow me down. Interjective things don't make sense. I'll have my chat. I'll bring my chat up at strategic points during the session. See what people are saying so I can make sure I'm running at the right speed. I'm making sense and any curiosities that you have I answer. So please make use. We should have plenty of time to touch with. So as you already know, Sundari said much better than me. I'm Simon. I'm from Open Credo. I like complex problems and cats and I'm really grateful to be here with you today. Thank you for spending your time. So Open Credo is a consultancy. We help leaders create conditions for staff to succeed. Our work often starts with a short assessment of organizations to understand the root cause of a number of obstacles. But the real reason I'm saying this is because the tools that we use during that assessment I want to share with you today and I hope you find them as interesting as I have. Happy staff related customers. Basically I want to tell you two stories today. And in telling you those stories I want to show that the approach that we're often taught to solve problems in organization often creates more problems than it solves. And I want to arm you with an alternative way of solving problems in organizations. There's an interactive session halfway through that we'll do as a group and they'll let you practice the tool. Right. Oh and one other thing I'm drawing the ideas of many smart people including my dad. I hope the only hope I have is I don't distort their thinking as I share it with you. But let me do my best. So I want to tell you a story to begin with. And that is a story of Wayland Uhtani. And this is a true story. I've simplified it anonymized as you can tell by the name. But this is something based on experiences that I've had. So Wayland Uhtani was facing a number of obstacles as an organization. What they were seeing was that software delivery was slowing. Their upgrades and decommissions of the infrastructure was becoming more expensive. IT costs were increasing. Customs were going elsewhere. Two competitors. And their instant volume was increasing. This probably sounds very familiar. A lot of organizations struggle with these obstacles. And the solutions that we've been conditioned to think about as managers. So when it comes to software delivery slowing, I've been conditioned to think about separating operations to development for focus. So operations can focus on keeping the lights on. And development can focus on shipping new features. And when it comes to expensive upgrades and decommissions, additional approvals can help make sure that we scrutinize every penny or repeat spent to make sure that is going in the right place. And IT costs are increasing. We get outsourced. Where possible. Customers going elsewhere. Well, if we deliver more features, we can retain more customers. We can delight them. And we can hopefully attract some as well. And if the instant volume is increasing, we can add more quality gates so that as we deliver software, it's of higher quality and will generate less instance later on. Are these good solutions? So get on the chat. Tell me what comes up for you. I'll have a quick peek. If anything, just curious. Do these sound familiar? And typical ones. Yes, yes. Yes, I'm deep. I agree with that. I'm in solutions. Delivering more features does not help. Oh, I'm interested in that, Deraj. I think I'm agreeing with you. No, not good. Rashmi, I think you're ahead of the game here. Those are solutions that may not cure the problem. Pradi. Yes. I feel like you're already know what's to come. I'm excited by that. Okay. Let me continue. But I love what you're saying. Please keep it coming. Right. So let's play it out, right? Let's play it out anyway. So yeah, it feels like the answer is it depends, right? There's a lot that we can't see to know whether these are good solutions. I think some of you are seeing things that I haven't yet seen and I haven't seen at this point when I was looking at Wayland Utani. But if we look at this in a little bit more detail, especially since a lot of these solutions are typical solutions, as you said yourself, they're things that played out in different companies and we therefore know how the play tends to unfold, albeit in a different context. You might see that separating operations development as the DevOps movement also tells us breaks a really critical feedback loop, which means that now it's really hard for operation to prioritize a fix with the development team to stop instance reoccurring. So over time, the instant volume just increases because we can never actually put the fix in because development is prioritizing new features over fixes. And also, if we add more quality gates, won't that slow software delivery? Because there's now more checks and balances to do. And if we have additional approvals for expenditure for upgrades, for example, and we depend on some of those upgrades to ship our software, that could also get in the way. And if we deliver more features, depending on how we do that, if that means delivering more in any given period, that could mean that we need more people and that could increase costs. So I don't know about you, but it feels like all of my solutions are hurting themselves. All we're doing is we're just shifting the problem around. And Russell Aikoff puts this really well. He says, a problem never exists in isolation. As we saw, they all are interacting. The more of the context of a problem that a scientist can comprehend, the greater are his chances of a truly adequate solution. And there's something else about this that's really bugging me. As I look at all these obstacles on the left hand side, it makes me want to say, why? Why is software delivery slowing? Why are expensive? Why are upgrades and decommissions expensive? Why are IT costs increasing? Why are customers going elsewhere? Why is the instant volume increasing? They all feel like they're pointed to something deeper. They all seem like signals or something else. Why? And I realize you're ahead of the game, but I just want to make sure I don't miss anything out here. But if we imagine that, in our room, we have a bad smell, we can smell something bad. What we recognize is it comes from somewhere. I may have left some food out overnight and it might have gone rotten. And that's where the smell is coming from. And so there's an underlying cause to the smell. And really, if we want to remove the smell now and in the future, what we do is we get rid of the rotten food, we put it out, we put it in the bin. We can spray deodorant aerosol air freshener, and that will have a temporary impact, a temporary benefit that will mask the bad smell from the rotten food. But it won't get rid of it. And we know the smell will come back. We can guarantee that. So what we need to do is we need to treat the cause to eliminate the effect. And it's the same with a headache. If you have a headache, and it keeps coming back, there's often an underlying cause, and that might be stress. For me, if my monitor's at the wrong height, I get neck and then headache. And it reminds me that I need to change my monitor. So we need to treat the underlying cause to eliminate the effect. Otherwise, the headaches will just keep coming back despite pain killers. And it's the same with costs. Costs are a signal. You can't treat costs directly. Costs increase because of an underlying cause in the business. And it might be attrition. What was interesting about attrition, of course, as you know better than me, is people leave a business because of a reason itself. So although attrition is perhaps a reason for costs to increase because we're spending more money on hiring, retaining, and training talent, the fact that people are leaving is also an indication of something deeper. So there's another why to ask in that case. But again, if we work out why people are leaving, maybe they don't have the opportunity to grow the skills that matter to them, we treat that, that people hopefully will no longer need to leave the organization. And then hopefully costs will start to level out. And again, another ACOF quote, in a system, the best way to treat a problem is seldom where the problem appears. We don't try and cure a headache with brain surgery, but by putting a pill on the stomach. So what I was doing with all those problems one at a time was, okay, well, there's a problem. Let me treat it. There's a problem. Let me treat it. But I wasn't trying to find the underlying cause. And so if I lay those same, those same obstacles out, and at this time horizontally, that we're seeing at Weyland-Utani, what this is helping us see is these are all causes, I think this is probably inherently, so these are all effects. I think this was inherently obvious to all of you as you hinted at in the chat, but it took me a while to work that out. So these are all effects and they're begging, it's begging the question. Why? What is leading to this effect? What is the underlying cause? And so we need to find and focus our efforts on the underlying cause to eliminate the effect. And Goldrat says, however, that focusing on everything is synonymous with not focusing on anything. And so this is scary to me. And a business naturally will have a lot of obstacles, a lot of the things getting in the way of its stuff. And if we look at each of those obstacles and try and find the underlying cause of all those obstacles, and then try and treat the underlying cause of all those obstacles, that sounds like a lot of work. Lisa Sheinkopf says something that's helpful here. She says counter-intuitively to me that few causes tend to be responsible for many effects, rather than the other way around. And what she means by that is if you trace back far enough, the causes should converge. There should be just a few underlying causes behind many effects, sometimes one, sometimes two, but many fewer causes than effects. So by tracing further and further back, we actually get this leverage where we can focus on just a few underlying causes. And in doing so, we could theoretically tackle many effects. And it's like what we see in engineering teams. I know that when I've had an issue, an obstacle, slow my team down, an engineering team down, it's often the same obstacle that slows my neighboring teams down. And if we were actually to go and trace that back and find where it's coming from and treat it, all of our teams would work much better for it. And so what we need to do is we need to find and focus our efforts on the underlying causes. So recap. And I'm going to pause, see what comes up for you, questions, thoughts. Anything that doesn't make sense or doesn't feel right. Tackling each obstacle in isolation, as I did at the very beginning and as you saw was wrong, is can generate little, no negative impact in a complex organization. Obstacles are often negative effects of underlying common causes. And finding and focus on those causes can help us eradicate many obstacles with SFM. Right. I want to go back to William Geetani. Before I do, I'm just going to open up the chat and see what comes up for you. Any questions, any thoughts, any reflections, anything that doesn't feel right. A lot of the questions and the reasons I'm pausing is to make sure I'm conveying the content in a way that makes sense. So really, I'm testing myself. I'm not testing you. Automate. Yes, that could be one of the original solutions, Mikesh. We could have one of the things I could have on the right-hand side was automate. Actually, I didn't think of that. That's more creative than what I had. And as we've seen, it might not tackle the underlying issue, but it could tackle the effects. Any questions? Oh, Q and A. Here we go. Do you have any real-time examples to share? So any real-case studies, Pradeep? Yes. And that's what I'm going to go into next. Absolutely. Thank you. Yes. Yes. I have two examples to share. I'm going to go into the first one now, and then there's one later on. So yeah, it's fine. Thank you. Otherwise, it does feel a bit theoretical and not so helpful. Any other questions? Any other thoughts, reflections? So recalls analysis, like five-wise analysis, fishermen can help in narrowing down on blind calls. Yes, it can. I'm less experienced with... So fishbone diagrams, I think so. I think there was an article I read which what fishbone diagrams may not do, but again, I'm not an expert, is it doesn't help us kind of necessarily converge and find the common underlying cause of many issues, whereas what I'm about to show you could help. But nonetheless, the fact that you're asking why and you're acting as scientists in a way to understand where is this coming from is a really powerful, whether it's root cause analysis or find why it's the same idea that we ask why or what I'll be showing with your hope, it can add to your arsenal so that as you ask why, you can also converge and understand from many obstacles what is the common set of underlying causes. So we get to kind of a few things that matter, a few things that can help generate a widespread benefit, if that makes sense. That's the right, yes, it kind of connects to a degree with those tools. Yeah, very astute. Anything else? If not, I will continue. Keep the interaction coming, helps me make sure this is useful. Yes, system thinking is helping to build a holistic view of big picture. Yes. Thank you. E-Pam agile bypass. Yes, hopefully. Let me try that. I'll tell you a story and then just let me know if it has actually given us a bit of a big picture. I'm going to close the chat and jump straight back in and then I'll come back to the chat shortly. So we want to try and trace back with way than due time. We talk theory now, we say that there's a few underlying causes behind many effects, but how do we do that? So Steve Tendon comes in and says, often it's hard to do that because organizations initially seem complex. And Steve Tendon is talking tomorrow, I can't wait to attend his talk at Hatch Island yet. But he says, businesses often seem complex, but they're not really complex. After all, we created them ourselves as human beings. There must be a way of understanding them if only we can join the dots. And he says, cause and effect thinking can be a way of helping us join the dots, helping us understand a few things that matter behind the many obstacles. Yeah. So let's try that cause and effect thinking at way than due time, which we actually did. And I'll just, what I've done is I've taken a small part of that cause and effect thinking and I want to replay it to you. Before I do, I just want to give you a quick boot camp. I think you're probably all well aware of how to read these diagrams, but I just want to make sure that I don't forget to share anything with you. So the way that we draw these diagrams is an arrow is an FN. So if the lamp is not plugged in, then the lamp will not turn on if then. And the only other thing to remember is a circle is an amclose. So if it is not raining, and if I'm outside, then I will get wet. Right. So let me walk you through a story. And this is a simplified version of way than due time. So these were the obstacles that we're seeing. There's nothing new here. IT costs increasing, software delivery slowing, instant volume increasing, customers going to competitors. There's one other obstacle I didn't share. Margins are reducing. You could have probably inferred that. If we just look at these obstacles, we can already start to see some cause and effect relationships between these things. So it might be that if upgrades and decommissions are increasing in cost, maybe that's one reason why IT costs are increasing. Maybe not the only reason, but one reason. And maybe if IT costs are increasing, that's one reason why margins could be reducing. Not the only reason, but possible. If our customers are going elsewhere, maybe that's why margins are reducing on the other end. And way than due time, what we found was in the face of reducing margins, the organization was focusing on cost reduction to try and increase the margins from the bottom. And what was interesting there was if we upgrade and decommissions do not provide any immediate value, it's kind of a deferred indirect value. It's like changing the oil in your car is better than me. That we want our car to keep running. It's not that putting change in the oil today will help today, but it will help in the future by stopping our car needing to go to the repair shop. But right now, there's no immediate direct value. And so what Wayland G, Tani, were doing as a result was they were skipping or deferring upgrades to their infrastructure and software because that had an immediate cost, but not an immediate direct return. But the problem is that deferring upgrades and decommissions, as you probably know better than me, requires more effort, the longer we defer it. If we defer upgrades, we now need to jump major versions and jumping major versions requires more risk analysis. What could this impact? What else in my IT estate could be impacted by jumping several major versions in one go? And it becomes harder to roll back if anything goes wrong. So we need to get it right. And decommission as well, what we found was the longer we leave a decommission, the fewer people who know about that thing were about to switch off, remain in the organization, and it becomes harder to know if we switch off what's going to happen. So they slowly turn into major programs of work, just as a result of deferring them. And so upgrades and decommissions were increasing in cost over time without Wayland G, Tani realizing. And there's a downward spiral here that because we were focusing on reducing costs, we were deferring upgrades and decommissions, they were starting to grow in cost just by fact not being done. And that was leading to IT costs to increase the margins to reduce to a degree. And then with margins reducing, we focus on reducing costs. And so there was kind of a reinforcing downward spiral there. And if we skip or defer upgrades and decommissions, it was leading to something else. Over time, the IT estate was growing in surface areas, growing in size and complexity. There was just more of it. And if building on top of a complex IT estate requires more effort, it requires more analysis, more architecture and thought, it requires more development, it definitely requires more testing, because we're building something that's more complex and tangled sometimes. Then that's one reason why software delivery was slowing over time. Because we weren't pruning our IT estate. And software delivery slowing in some cases, the business was working around IT. And that was in those cases where they really needed to get to market quickly to protect their market share. And so the way they did that was they in some cases went to IT consultants. And there's nothing wrong with IT consultants. But we need to recognize is that IT consultants will need to integrate with the IT estate at some point to make what they've created useful. And despite best intentions, if they don't have access to the understanding of the IT estate over time, they're just going to add to it. And it will slowly grow in complexity even more through no one's fault. And so we have another downward spiral here that by the IT estate not being pruned through decommissions and upgrades, software delivery slowing, the software delivery slowing, sometimes the business works around IT. And despite their best efforts, because they don't have access to the knowledge they need to build on it in a way that's more logical, it grows in complexity. And we keep going round and round. And if we believe that being efficient reduces costs, i.e. doing more in any given period can help us reduce costs when you need less people, then what the way that you were doing was in focusing on reducing costs, they were incentivizing, they were giving the operations team a target to close as many instance as quickly as possible. And these were instances like to do with data discrepancies for one or two customers at a time, they weren't anything major. But what that meant was because they need to close as many as possible, there were set targets to close as many instances possible in a given period, it meant that problems weren't fixed, but they worked around. They didn't have time to do recalls analysis to do the five ways to understand where these instances were coming from and to fix the underlying problem. All they could do was work around and fix the customer data rather than fix the upstream issue that caused the data discrepancy. And if we also recognize that the IT estate is growing because we're not pruning it, it means that new problems will arise. And if we're not tackling the old problems, and we have new problems coming in, over time, instant volume will increase. And as instant volume increases, and it directly affects customers, like they can't check their bills, perform critical transactions, they may go elsewhere. And if they go elsewhere, our margins reduce. And if our margins reduce, we focus more on costs, and it goes round and round. But also, if instant volume is increasing, we may find we need more operation stuff, and IT costs increase. And that's what we're seeing in this case. So far as trying to summarize that, and this is just a snippet, there are other reinforcing loops that I took out just so I could tell a story in a short period of time. By counter-intuitively, at least to me, by focusing on costs, costs were increasing. Our system, our organization, was almost designed to make the IT estate more complex over time, because we were incentivizing not fixing problems, and we were not pruning the IT estate, we were deferring it. And what that meant was more instance, many customers go elsewhere and our margins reduce. And it meant that we need more IT operation stuff. And any upgrades and decommissions that do occur were more expensive. So our costs increase. So I had a question, which is, where is the common underlying cause if you could only focus your efforts on one or two things here? Where would you focus your efforts? Open up the chat. If there's anything else coming up for you as well, throw that in. But I'm curious, where is the common underlying cause? What is leading to all of this? Lucendiary. Understand the effects together, but address the causes one by one. Yes. Yes, to a degree. So that's a really good question. So generally when I've looked at this, there's generally been one, at any one point, there's been one cause to tackle. And but that's not to say that once you've tackled that cause, that you then don't need to focus on something else. So it's like a bottleneck and a pipeline. At any one point, there's always one narrowest part in a bottleneck. And if your aim is to increase flow, you want to increase the diameter of the bottleneck. But once you increase the diameter of that bottleneck, you're going to need to shift your focus elsewhere. Obstacles will appear because there's another bottleneck elsewhere. So at any one time, there tends to be just a few underlying causes. But once you tackle those, there's tends to be other things that will get in the way later that you'll need to tackle. So yes, and your question's really astute. I really like it. Any other questions, comments, or any insight into where is the common underlying cause? If you could only focus your efforts in one place, right? At this point, where would it be? If you're a part of Wayland Utani? Also, 8 to 20 rule. 80-20 work, so Pareto's difficult to say with the complex diagram. Yes, you're right for deep, sorry. But I'm grateful for you trying. So, Sundari, the Pareto principle works well when the system isn't interconnected. When the system is interconnected, it's more like 99 to 1. So 80-20, if you don't have that interconnection, where different problems are interconnected, that touching one part of the organizational system won't impact the other. But when you have those interconnections, where an action over here will have an impact over here, it tends to actually converge and become more of a 1% to 99. I want to understand from me like Aldera. It's a really good point. Really relevant question. Fixed the upgrade and decommission issue. Oh, interesting. Oh, interesting. So what I like about Shaven, what you've done there, is you've put a stake in this end. And I would take it actually just a few clicks before you're suggesting. Because I think you're suggesting perhaps something around here. And I completely agree with that, because it means that the IT estate won't grow in complexity anymore. But what that still leaves is that the operation staff aren't incentivized to fix existing problems. So I'd actually go one step before and say, let's not focus on reducing costs. And that sounds so counterintuitive, as I say it, but I'll add more to that. But Shaven, I think you're exactly in the right place. But I just go a little bit earlier than you were in that. So many times we look for workarounds to have a quick fix, which keep adding and creating bigger problems spot on ration. Okay, right. I'm going to jump back in. So I'm seeing the time and I want to make the best use of what you give me. All right. So I love what's coming up. So I'd say, actually, I'd say it's here, actually, by focusing on reducing costs, costs are increasing. And empirically, we've seen that's untrue by focusing on costs. We're trying to incentivize IT operations to do as much as they can in a given period, which means that they're not effective. They're not actually fixed. They don't have the time to fix centerline problems. And we're deferring something that really matters, which is the decommissions and upgrades. And theoretically, John 7 shows us that this is untrue. And he says by chasing efficiency, by managing costs, costs actually increase. And we actually undermine effectiveness in the eyes of our customers. Who's losing out? The customers. They're leaving as a result. So counterintuitively, by focusing costs, costs increase. And what we need to look at is effectiveness in customer terms. So problems are often interconnected and best understood and tackled together. It's kind of like the paradox of the elephant. In that, we don't want to just, we don't want to, we need to not just know that there's a tail, there's some tusks, there's some big ears, there's some legs. We need to understand that it's an elephant. And by doing that, by causing effect thinking can help us do that. It can help us understand and find a focus, our efforts on the underlying causes to eliminate the effects. And we can understand why focusing in the rails that isn't underlined cause leads only to temporary improvement. In this case, by focusing on costs directly, it was leading to a growingly complex IT estate. It was slowing delivery, increasing costs, reducing profits as customers went elsewhere. Have an exercise. What I'll do is I'll give you one more example. If this time, I'll give you the exercise now. If not, I'll go to it at the end so you can do it offline if you would like. But I just want to make sure I don't, given there's 50 minutes left, I want to give you as much of an example as possible. So this is where it is. What I'll do is I'll just paste this in chat so you can always get to it. Copy link address. So you can always get to it if you want. There's a public mirror board. The instructions are there as well. But it's basically giving you the opportunity and these are some, what you'll find on that board is some, let me go there now, is you'll find all these canvases are exactly the same. Pick one, have a go. I can see some of you already there. And what I'd love you to do is just connect them in terms of cause and effect. And you can do that just by clicking on a post-it and clicking on any of these dots and dragging and saying, okay, well, there's more difficult confrontations. Maybe that will lead to trust reducing. So if then. And if trust is reduced, I can't remember. I don't know the answer. If trust is reduced, then maybe staff will feel demotivated. And the great thing by going through this, what I'm looking for the whole reason we do this is to work out where do we focus our efforts? If we focus directly on staff are demotivated and run workshops and things, maybe we'll tackle this temporarily. But if we go for understanding why there's more difficult confrontations and tackle that, we kind of get a three for one. We get buy one, get two free. We can tackle this. And in doing so, tackle this and this. So by what I'd love you to do, if and when you have the time, if you'd like is to join these in terms of cause and effect. And in doing so, work out. Given I've now mapped this together, where are the few things that I'd spend my limited time and effort to help this organization as CEO or chief happiness officer, whatever you want to call it. We'll come back there at the end of this time. But please, this is always open to you. I'd love to see what comes up for you. In the slides, I have an example solution. Purely because I was part, this is based on a real, real-life situation. It was the solution for them. That was not necessarily the only solution. I was going to skip past that. So you can come back to it later if you like. But that's the current reality tree, working out where should we focus on limited efforts to create the most benefit. I want to tell you one more story of unhappy stuff. And this comes from Tyrell. Again, codename, but an amalgamation of two stories, two real stories. So Tyrell had two parts of the organization, particularly that were struggling, human resources and project managers. And human resources were seeing that staff weren't able to grow the skills that mattered to them. And as a result, they were quitting. And project managers were seeing that projects were moving slow and unpredictably, and work was often getting stuck between teams. And so they were thinking about solutions and human resources thought, well, let's purchase on-demand learning content so our staff always have access to learning, no matter where they are. And project managers thought about a new project tool with better forecasting because they felt that would allow them to better coordinate the actions of teams so work doesn't get stuck between them anymore. And teams would know when work is coming to them. So are these good solutions? Answers in chat. I'm gonna keep going with the story just because of time. But, I know what comes up to you. You know, I'll have a look at the chat in a second. But I'm gonna go straight into the current reality through the cause and effect diagram. You know how to read this. Feel free to sing along with me. So these are all the obstacles that Tyrell had that I said on the previous page. There's also two others, which you can infer as well, which is that staff with PMD motivated and an issue in one project will ripple across others. these are things that we observed. And again, we can always start to see some cause and effect relationships even between these these obstacles. So for example, if staff feel demotivated, it may lead them to quit. It may lead them to quit. And also if work is getting stuck between teams, projects may move slow and unpredictably for that reason. But also if an issue in one project will ripple across others, that could lead to unpredictability of projects progressing. And as HR had correctly inferred, if staff are unable to grow the skills that matter to them, that had motivation depends on mastery, depends on growing the skills that matter to you as an individual, staff may feel demotivated, may feel demotivated, may not have the conditions to feel motivated, as Daniel Pinkholms has understand, and therefore may quit. Because they want to grow in in their career, they want to grow in the skills that matter, and they may move to an organization where they can do just that. But what we also saw was that staff were assigned to multiple projects, and I'll come back to the reason why in a second. And that led to that led to team members being overutilized. They were generally very very busy. And that led to two things. The first thing was that if team members were overutilized and learning takes time, they weren't able to grow the skills that mattered because they didn't have the time. And therefore they felt demotivated, they quit. And then there was less staff left at that point, meaning that the remaining staff were spread across even more projects to try and keep the projects afloat. And so they had even less time to learn. And also if team members were overutilized and teams are interdependent, work was getting stuck between teams. And what I mean by that was teams are often teams are interdependent. That's why we have an organization to allow us to do more than any one person or any one team can do in isolation. And like a development team, even the best development team, even the best developer, often depending on how you structure organization, needs great, you know, needs some help from QA, needs some help from products, user experience design, et cetera. So there's going to be handoffs. And in this case, if all the teams are very, very busy overutilized, it means that they don't, when they receive work from another team, not only do they need to finish what they're working on first, they probably have a queue of work before they can get to what you've just given them. And so if teams are interdependent, i.e. they need to hand, they need to be handoffs. And all teams are fully utilized. It means that work is just getting stuck in a queue between teams and sitting there for quite a long period of time. I hope that made sense. And of course, I think this is a fact we can all agree with, particularly recently, that the world is not predictable. And a project may face urgent issues. And if a project may face urgent issues, and what we've done is we've assigned staff to multiple projects, an issue of one project will ripple across others through that individual, through no fault to them. What I mean by that is, if I'm assigned to multiple projects, Simon can only be in one place at any one time. And that means if this project's on fire and I go over there, all the other projects that I'm working on will be staffed. And they'll have, they'll be, they'll move forward in an unpredictable fashion. So in a way, like the individual person assigned to multiple projects is a conductor for the unpredictability through no fault of their own. And if projects move still in a predictable way, and we don't want staff to twirl their thumbs, then what we'll do is we'll assign staff, sorry, we'll assign staff to multiple projects. And that's because we believe that maximizing staff utilization increases throughput, i.e. by making sure that staff never sit idle, we can deliver more projects in any given period, or therefore assign staff to as many projects it takes to make sure they're fully utilized. So again, I'll ask that question, but I'll, and thoughts are very welcome, which is, where is the common underlying cause? What is the one thing that we could focus our efforts on that could start to tackle a number of these obstacles and won't go? Can I open up chat? Because I know I've asked two questions now and I haven't looked at your thoughts. Thank you, Sundari, for resharing that trick. I realize I probably, I've probably thrown another complex diagram in you, and it's, it's hard to go where to find somewhere to focus here. That will probably help a little bit. I'll keep playing the story. I'll keep playing the story, but keep the questions coming in. Cool. Sarah, creating a dedicated multi-disciplinary and make them go at a sustainable pace. I think you're on to something. My gut feel is even a multi-disciplinary team will have some handoffs. So I don't disagree with that. I don't disagree with the helping. But what I like even more is what you say after that about the sustainable pace that, that really resonates with me. So yes, I think you're on to something there. Cool. Let me jump in. Having the right skilled staff. How can this, oh, that's interesting. How can we help have the right skilled staff if they don't have the time to learn? And knowing that, especially in the technology space, you know, skills become quite obsolete quite quickly. I think so, so Shama, I like what you're pointing to. For me, it's almost how do we create the conditions so staff can become right skilled with their own accord? How can we create the conditions so they have the space to learn? So what you're pointing to is important. I see it slightly differently, but it's a very important point you're making that cross functional teams could help. I agree. I think there's still handoffs needed in all organizations, but it will help. It'll just push the problem out. So we don't, we have it less often, I think. So I agree with that. Sorry. But I think we'll then still have. So what you're, what you're all pointing to there with the cross functional teams, I really quite like, which is kind of around here, right? So it's kind of, it's kind of here. We're trying to remove the interdependency between teams. And what I think that would start to dissolve is if teams are no longer interdependent to the same degree, then work will get less stuck and projects will move less slowly and more predictably. So yes, I think we'll erode the left hand side of the diagram. But what we want to road, I believe and do correct me here is the right hand side, because team members will may still be overutilized if we're trying to force them to be fully utilized. And so they won't be able to grow the skills that matter to them. And won't to Sharma's point be able to have the skills that we need in the future for our organization to be successful, because they're so busy. So what I really liked in what was said was, where is it? Sirath saying, you know, you kind of, you had two points there, which was multidisciplinary and sustainable pace. It feels like that's kind of left and right side of this diagram. I really like it. Do you know I signed staff with two multiple projects? Yes. Dedicate time for upskill learning? Yes. Yes. Enough relevant trainings. There is, that's interesting. Yes. Yes. I think the time is the constraint here. It's not that there isn't enough relevant training. It's the time. So yes, limiting work in process. Ooh, I love that. Rashmi, staff overutilization needs to be looked into underutilization to promote learning investment. Ooh, I love where you're going. Yes. Yes. Okay, great. I think we're all seeing from the same hem sheet. So yes, this thing here. So actually I'll go a little bit deeper just because this thing here is really interesting. This is an assumption. It's maximizing staff utilization increases throughput, but what we've seen from this diagram is it's not true. Although we conditioned to think that, and I was conditioned to think that as a manager as well, I was taught, you know, this feels intuitive. It feels right. It's not. We can see just from this diagram, empirically, it doesn't, it's not true because then we work, spends more time and cues between teams, as opposed to, you know, flowing across the teams. And it means there's not enough time to learn. And so we lose staff and therefore we have less people to do the same amount of work. So empirically, it's not, it's not true. And theoretically, it's not true as well. As we know from the Kingsman formula, the Kingsman formula saying that as we go above 85% utilization of like a CPU or resource or person, the queue length, depending on variability, will start to approach infinity. So actually by fully loading our staff, we're actually causing our system to block up. And my friend or mentor kind of does this really well. He says, well, if above 80, 80, 85% utilization theoretically from the Kingsman formula will mean that work gets stuck in queues for a very, very long period, what we should do is perhaps consider planning work to 40% of people's capacities or team's capacity, knowing that we'll need 20% for improvement efforts like we saw from the previous example with the IT estate, and 20% for unplanned activity, things just happen. And that means that we'll never be above 80% utilization. So we can always swap this around and redesign how we utilize staff based on this new assumption. Given now that we've disproven the old assumption, it's no longer proving helpful to us. So what be the impact to the original solutions? Well, new project tool of better forecasting is starting with the assumption that our data is wrong and better data can help us better coordinate. But what's really happening is it's to do with staff utilization. That's the whole reason it works getting blocked. And also with the purchasing on demand learning content, the assumption behind that solution is that staff don't have access to the content. But it's not that it's that staff don't have access to the time. And Russ Leicoff says we fail more often because we solve the wrong problem than because we get the solution to the right problem. And I've been on the wrong side of this so many times, I've solved the wrong problem, as you can see from my working screen. Wrong. So what's the summary? So problems are often interconnected and best understood and tackled together, cause and effect thinking like a current reality tree can help us understand interacting problems so that we can find and focus on the underlying causes to eliminate many obstacles, often due to an assumption that we need to recalibrate. We can understand why it changed anywhere that isn't underlying cause will lead to only temporary improvement. We can accept why previous attempts to improve things may be non-successful and improve future attempts. Now what? So here are the books. This is all thinking that comes from Eli Golderat, from John Seddon, from Steve Tendon. But here's some books and Russell Leicoff and Deming. So these are all books that I would love. I would recommend based on that if you want to read a little bit more. And this is what we do as in terms of open credo. So we assess and advise, we try and find where can we focus our efforts for the maximum benefit in the business when we're going through transformation, amplify agile coaching. So improving any one part of the organization doesn't necessarily improve the whole. So we try and help agile coaches kind of work across teams together to kind of amplify their impact. And we, of course, engineer solutions. And that's everything. I'd rather be like one minute before the end, but anything else that's coming up for you, if there's any final questions, open to now in the last minute. Also, I'll be in the hangout. I look forward to meeting you more. Thanks Simon once again. Thanks all participants. Thank you. Thank you very much.