 All right, thank you so much. I'm just going to play this for a second while I introduce. Hold on a second. I don't need their music, OK. This is called a murmuration. And the birds organize themselves. There's nobody saying, you fly here and you fly there. Let's watch this just for a second. I've timed my talk. I have enough material that by 7 or 8 this evening will be done. But watch these. This is a kind of a low resolution. I'll put a button on here to make this point better. Maybe I'll lower that down a little bit. There we go. That might be better. I don't know. Why do they do this? Does anybody know? I've read a lot of science about this to try and figure out they think it's to avoid predators or to keep warm in the winter. They actually, it changes their microclips. I think they do it for the fun of it. They say, hey, this is fun. And they like to make big shapes in the sky so that we all can see. We can look up and say, hey, that's an elephant. No, that's a walrus. No, it's a drone. Yeah, exactly. Watch this. Isn't that amazing? Simple rules, very simple rules. This seems awfully loud to me. Does this seem loud to you? It's OK? OK. So we're going to shut that off because I have so much stuff I want to cover. I time myself. I think I can get through it. We'll find out. I went to a talk a little earlier today. Jules Kim from the Cognitive Edge. And I think she had like 15 slides. And I think I have 200 slides. So listen quickly. OK. So I'm going to give a very rapid introduction to mob programming. So rapid you hardly understand any of it. But I start every one of my slides with this quote from Peter Block. I can't tell you what to do. It would be ridiculous for you to ask me what should we do. I'm not in your organization. I'm not in your situation. But I like to share the things I've done because people ask. When people ask me to share, I feel compelled to share. Because when I was first learning this stuff 25 years ago, other people were sharing their ideas. And I wouldn't have learned anything if they hadn't have done that. Try to keep an open mind. That's all I ask. So you know what? Standing in such a way that I can't see my screen, so I'm going to move this. That might help me a little bit. We'll see. So this is a really rapid introduction. I used to call this mob programming. I'm calling it software teaming. It doesn't matter what you call it. I changed the name because some people think mob is a little too aggressive or negative sounding. I didn't think it was just about programming. It's about creating software. So that means it's not just for programmers. So it just seemed to work well to be software teaming. The word teaming comes from Amy Edmondson. And she wrote a book on teaming about a year after we had started mob programming. And I read her book. And I said, that's what we're doing. So I kind of like the teaming name. But it's all the brain and minds working together on the same thing at the same time, in the same space, and at the same computer. Now, should I stand closer this way, or it just doesn't matter? This is fine. OK. If we can gather together all the skills and all the capabilities that we need, and those people can sit and work together, something really magical can happen. This allows us to work through things straight from beginning to end without inventory and without queuing. Now, understanding what inventory and queuing is isn't something we're going to go into today. But it looks like this when you're sitting together. That's shortly, maybe within a year after we started working this way. This would have been 2012. We started mob programming in 2011. Other people were doing similar things. We didn't invent anything. But as we started doing it and bringing it forward, people seemed to be interested in it. And it kind of became attached to us. It can be done remotely. And it's being done remotely all over the world now. I don't know why. For some reason lately, people have been working remotely a lot more. Sometime in the future, you know what? Why does that arrow still keep showing up? Sometime in the future, people will look back and not understand what happened. But we all know what happened. It's not five people watching one person working. We follow some. I'm going to go through these slides so quickly. If you want to take pictures of the slides, we're going to be in trouble. But we need some sort of techniques to do that. And we use this thing we call driver navigator that came from the old days of para programming. And we follow this one rule that I got from Llewellyn Falco for an idea to go from someone's head into the computer, it must go through someone else's hands. That was a para programming technique. It forced us to have really complete and natural sharing of information. And it kind of locked us out from the idea that one person's coding and somebody else is watching them. It's not really what the experience is about. But this seems crazy. And yet it's being done all over the world. And quickly, these are places all over the world. People are working this way. When I was six years old, I went on a consulting job for Grace Hopper when I was six-year-old and told them they need to get some big monitors. Why don't they have big monitors? That's just a silly joke. I've never met her. I would like to have met her. But yeah, I was not a child prodigy. At best, I was playing in the mud in my parents' little farm they lived on. So people are doing this all over the place. So let's move on to what do I mean by advanced? What I'm talking about is the techniques and ways we can work to collaborate well. That's not what I'm interested in in this talk. This isn't about the techniques of working together. This is about the thinking that I had put in place for myself by 2011 that allowed me to realize that what was important was to have an environment where people can do the best they can do and they will discover the techniques they need. They will discover the way to work that they need. My very first job when I was, I think I was 13 years old. I've been trying to figure that out. I started working in pulling weeds for neighbors when I was really young, but I got my first real job, I think, when I was 13 years old. And I was hired to water plants in a nursery. A nursery is where they grow plants, usually in little containers, and you got to bring water to them. And my boss on the first day took me aside and said, you have two responsibilities. Now, my memories of this totally are not clear anymore because that was an extended period of time ago. Matter of fact, there was still dinosaurs at that time. And so, but this is what I remember of the experience. He said, your first responsibility is to water the plants. The plants cannot get up and go get a drink like you can. You bring the water to them. Now, you could use sprinklers and stuff, but that's very wasteful. So you use a watering wand, and you water each can, and you put just the right amount of water in. But each plant is different. So he said, you're going to need to keep the plants alive, but not only that, you want to give them an environment where they can thrive. Now, this was important to him. And he was sharing with me how important my job was. Because if you don't water that plant in that can even once or twice, and it dries out a little bit, that plant will never probably do very good. It gets stressed out, and it gets growing patterns that we don't want to have. So he was telling me, I have an important job, and I have a lot to learn. I need to learn what the water need is for each plant. But he told me you have another even more important job. The second responsibility is pay attention. Pay attention and look for things we can do better. And at the end of every week, you come and tell me, what are those things? And we'll figure out what we can do to make it better. Now, he was expecting me to take action, not just to bring the idea to him, but to go and fix the thing, whatever it happened to be. The first thing I noticed was the hoses that we use for watering had leaks in them. You've seen a hose leaking water, and that's very wasteful. And in our part of the world, that's really difficult because we don't have a lot of water. So I mended the hoses. I was a farm kid, kind of. We lived on a little bitty farm. I had already been taught how to mend a hose. So I fixed the hoses. This is probably the end of my talk. We don't need to cover anything more if we understand this. He understood, his name was Larry Smith, he understood that tiny improvements over time have a compounding effect. So he was saying weekly, but what he was really saying is continuously, always be looking for ways we can do things better. And I found it's in a book just a few years ago, this guy named James Clear wrote this book, Atomic Habits, and he shows, if you just have a little bit of improvement every day over a year, it's quite a bit. So he says 1% per day increase in our capability is 3,778% improvement. If you could do that with your retirement investments, you would do that, right? Because you could retire like in two years, you would be a very rich person. And of course, that's the same thing as doing software development. You make a lot of money that way. But I put this into Excel to prove it and he was right. So that's my print of my Excel spreadsheet. It doesn't matter how quickly you do your compounding, but let's say it's weekly, then this will spread out over more years. But if it was daily, if it could be done daily, I'm not sure it can be. But it's the spirit of the thing. It's the spirit of the thing. So let's just have a tiny improvements habit. The problem is, this is hard to get and there's things that get in our way. And this little icon of this little girl sticking her tongue out, she's kind of a, I don't know, an elf or something, at least imitating an elf. I like to put her in here when I say this is hard to manage. So she's telling us, yeah, this is tough. This is one of the reasons things are hard to manage. So I usually do this as an exercise, but I time this through and we don't have time to do it today. But I ask this question in my workshops often. I think we might have even done this in the workshop I did earlier this week. Over the last few months or a year, what are the things that have gotten in your way of you being effective in your work? Now, when I do this with say 20 people, I usually come up, they'll come up with 30, 40, 50. This group came up with 50 items. It looked like this. I wrote them all out. I didn't group them or anything, but just needless meetings, workflow interruptions, technical blockers, multitasking, unclear requirements, not knowing something. All of these things make it hard for us to get our work done. But this is what I've noticed. I've done this exercise. I know over 500 times. I tried to calculate the other day. I think going back to something like 1999 when I did my first version of this, I think, and I could be tricking myself, but I think that's like 1000 times I might have done it. This is what we've learned over the years is there are many of these problems. They stay with us and they're everywhere. So I've done this at, I know at least 500 companies in the last 10 years, and what I've noticed is that everywhere I go, they come up with a pretty much the same list. And this is what I'm seeing. They're profuse. Why are they so profuse? Why are they so persistent and why are they so pervasive? And to make it really clear, if I go to a company that I visited five years ago and they made this list for me and I go back now, they'll make a similar list for me. Why are these problems sticking with us? So this was the beginning of me understanding it. In 1999 I worked at a place where we would do a reflection time like we call nowadays a retrospective. They called it a lessons learned every six weeks. At the end of the first six weeks they found their estimates were off, the requirements weren't clear when we started, and the requirements kept changing. And they figured out how to get better at it. They brought in some trainers. There were 200 of us developers and it was a brand new project and all this stuff was going bad. So we charged off to do our next six weeks of work because we were doing these every six weeks and then the next iteration, same problems popped up, okay? And the same way to solve it popped up. And then we went again. The next retrospective or whatever you would call it, same problems. We should have a mindset that would help us out to figure out this isn't working for us. But in that particular case, they just kept doing this. And so I did stand up in a meeting after the third one of these and I said, hey, don't you notice there's kind of a pattern here? But it was hard for me to get them to see the pattern. But I gave the pattern a name and I called it, this is a cycle of continuous no improvements. This cycle I've seen over and over. I started taking notes in 1999 at every place I worked to see what patterns were recurring over and over again. And I saw this one. And this is my observation of it. Are we dealing with problems or are we dealing with symptoms? And I suspect these are all symptoms, not necessarily problems. These are the things that are an indication of a possible problem. And in this particular case or in many cases we can't solve problems. If you've got a cold and you've got a headache and a running nose and a cough, you can take some aspirin or something. You can take a decongestant. You can take a cough suppressant, but you're not dealing with the cold. What you're dealing with is the symptoms of the cold. Now you feel better and you're gonna go into work maybe. However, you're now carrying those germs around to everyone else and at the end of the day you're gonna be really worn out because your doctor would have told you, just stay in bed, drink plenty of fluids and rest and you'll get over your cold. So what happens is we hide the symptoms. If we deal with the symptoms we're gonna hide the problem. But there's a bigger conundrum that I wanna discuss. And that's this, can we actually solve problems? Now this has to do with what domain we're in. And everybody talks nowadays about domains from the Kenevan concept and that's what I'm talking about here. So if we understand the domain we are in I don't think it's universal that all problems can be solved as such. So often in our world, today's solution becomes tomorrow's problem. Whatever we set out as our solution it becomes a problem for us. This is a big issue and I call this the problem with problems. Is we focus on our attention on the problems that come forward and instead of paying attention to something else which we'll talk about in this talk, turning up the good. We probably need to do both, but so things are hard to manage because we focus on solving problems and that leads us to one of the biggest problems I've seen over many years is what I call the misplaced focus of management. With the misplaced focus of management managers are focused on solving problems. One of the big problems that they see it's hard to manage things. So this is exactly what they set out to do. Let's make it easy to manage things. Let's get some tools, we'll get some trainers, we'll get schedules, we'll use these charts. We're gonna just make it easy to manage. I don't think this actually works. So there's a quote that is often attributed to Peter Drucker. I have not found where he actually ever said this. He was quoting in a book, I think back in the 70s or 80s having said this, but there's no where I've found that he actually says it. Here's the thing, if this is true, whoever said it's pretty brilliant. So much of what we call management consists of making it difficult for people to work. Why do we let this happen? So the managers are making it easy to manage and they don't release, they're making it difficult for people to work. That list that I showed you a little bit ago, that exists because we are automatically making it difficult for people to work. We separate people into separate departments, separate teams, we put people on one floor over here and then in another floor over there. Fred George talked about this in his session. So why do we let this happen? And that's what the rest of this talk is about until we get to some practical stuff. So remember, this is about mob programming or software teaming, as I'm calling it now, but how do we have the thinking and the environment in place that allows things like mob programming to bubble up, to become a reality? So we'll start with beliefs. I love this book from Dave Gray. I read it quite a while ago, but before I read the book, he had shared this little drawing. I saw it somewhere, maybe in a talk that he gave. And he talks about reality, reality is everything. It extends all around us in all directions. We have no way to fathom what that is. But on top of that, we have our experiences of our life. Our experiences are what allow us to be exposed to a small amount of reality that we get exposed to. And we pay attention, though, to just a little bit of it. We can't pay attention to everything. Even in this room right now, I can only pay attention to a little bit. And the rest of it's not gonna get stuck into my brain somewhere. On that little thin thread of attention, we build our theories. That we want to try to understand what's around us. We start making judgments based on what we've seen and what we experience. And that turns into our beliefs. And then we will say, hey, this is obvious. This is the obvious thing, all right? But the problem is that all of this stuff, let's see how my clicker works, all this important stuff is based on that thin thread. That thin thread is all that's getting into us. So this is a big problem. So things are hard to manage because what we believe is based on that thin thread. And we need to have the beliefs. We would use up all of our power, all of our energy making decisions if we didn't have that. I learned that reading coniment and other people like that. But these things limit us. So we'll come back to beliefs in a second because we need to talk about biases, too. Now this chart I found, I think, in Wikipedia, which is really the only, the one true source of information in the universe. So always go to Wikipedia. And that's not really true, you know that. Okay, there's like 150 or something biases here. I only want to talk about one, but mind the biases. You see that on the train, it says mind the gap, do that too, but mind the biases. Because these biases are what's tricking us. Confirmation bias, the only one I'll cover, you all know what this is. We're biased to want to confirm the things we already believe. And we'll do things like search for information in a biased way, we'll filter our search in a biased way, we'll interpret the things in a biased way and our memory will be biased to be the thing we want to have seen. None of this is very helpful to us. So things are hard to manage because it's human nature to want to confirm the things we already believe. But I think there's something a little worse. If somebody knows what this bias is, I'd love to hear it, I haven't quite identified it yet. It's human nature to believe what we want to be true. That's a little different than what we just said. We want to believe the thing that we want to be true and so we find excuses to explain for ourselves why this stuff is true. That's why my first slide said, hey, I'm just here to share some of my thinking and ideas, I can't tell you what to do. My truth is my truth, it's probably not gonna work for you. But here's an example of what I wanna talk about. So we believe when we've succeeded that it's because we are talented or capable or did the right things. Is that true? Well, of course, Kahneman, I think Kahneman's a Nobel Prize winner or something, right? He's a bit smarter than I am. Probably like exponential scale or whatever above me. But this is what he says. Success is talent plus luck. I've got some talent, I've had some luck, sure. But great success is a little more talent and a whole lot more luck. And if that's true, we should stop taking pride in the things we've done as that's why we succeeded. And I'm really cautious about this. I wanna make it really clear. Mob programming exists maybe partly because working as a team was sticking with me for decades, a couple of decades anyways. But I didn't cause any of this to happen. I just was along for the ride more than anything else. So things are hard to manage because success is about the luck. But we believe it's because of what we did. And then we wanna continue doing what we did because we know that brought us success before. But it's all chancey. I'll share Brian's first law. Has anybody ever seen this? I think this is really, really rich. At some time, I'll read it. At some time in the life cycle of virtually every organization, its ability to succeed in spite of itself runs out. This is the, and I've seen three or four talks that refer to this concept. There's this arch or whatever you wanna call it. There's a cycle. You get the idea. The weight of running the organization usually ends up having it collapse. This can be seen really quickly in modern businesses. But this happens to civilizations as well. I've been reading several of Margaret Wheatley's books recently and I've seen her quoted in other talks. And she kind of explains this, that there's a pattern that this stuff follows. It's some kind of a cycle. So if this is true, we are tricking ourselves to thinking our success is because of what we've done, but it's really because everything lined up well for us. And somebody else maybe didn't have this luck that we had. So the next thing I wanna talk about is the failure to communicate. All this stuff is making it hard for us to have that tiny improvements happen. I'm gonna share Wheels' Law. Is anybody familiar with Wheels' Law here? Wheels' Law. When this was first exposed to me, or I was first exposed to it, they never showed Wheels' Law to me. I was taken aback. I thought, wow, this is so close to the way I see things. And so here I got a chance to confirm my biases. That's pretty powerful, right? You don't wanna do that, but when I saw this, it was explaining stuff to me that I thought I was seeing and I think this might be true. But if this is true, what are we gonna do about it? Communication usually fails except by accident. What if that's true? Now communication usually doesn't matter that much for daily life. Things can be pretty garbled, but when it's really important, maybe it can't be. If communication can fail, it will. If communication cannot fail, it still most usually fails. Well, this is really broken if this is true. Do you like the cat picture there? I kinda like that too. If communication seems to succeed in the intended way, there's a misunderstanding. If you are content with your message, communication certainly has failed. I've been in organizations where the boss spoke in front of everybody and told them about something that's coming up and when we all leave, we have all a different impression of what he said. I remember one team, I worked with them going, hey, we're gonna be on the new project. I said, no, he was telling us we're gonna get fired. We did end up getting fired, but I knew that because I was older than the rest of them. I knew the signals that he was saying. So you're like, he was gonna cut some of the teams. Yeah, okay. This last one I think is a lot of fun. If a message can be interpreted in several ways, it'll be interpreted in the manner that maximizes the damage. Have you ever seen Twitter? This is Twitter. This is modern media, okay? So this also is all related to this. We have this failure to communicate because my truth might be a little bit different than your truth. And then it's really difficult for us to get aligned on anything because we grew up in different parts of the world maybe or in different families. We are paying attention to different things. Our experiences are different, therefore our judgments are different, our theories and so on. How many of you have a family with more than one sibling, our brothers and sisters? I had five brothers and sisters plus me made six. I'm not like any of them. We all think very differently from each other, but we grew up with almost the identical situation. Yeah, this is a problem. So the next thing I wanna discuss is systems and domains. I'll dwell on systems a little more maybe than I should, but I think this is really important. I'm not sure when we're supposed to be done here. When are we supposed to be done here? What's that? 15 minutes, oh my goodness. So a quick definition of systems. It's just an interconnected and interacting bunch of parts that delivers something. It's whatever it does, it's fulfilling its design. It's not, if we designed a system, it's not what we intended. It's whatever it does is the end result. We don't know what that's gonna be. So there are systems within systems. Tanel Meadows talks about this and I look at it this way. The work itself is within a system of work which is within maybe a system of management which might be within a system of purpose. I don't know, I'm not really, this isn't anything important right here. It's just the way I think about we have systems within systems. So when we see some symptoms of problems, we think we can solve them and we can't because when we see a symptom in this system, we can't deal with it there. We have to move out or out or out. And we may not really ever find the cause of the problems. So the things are hard to manage because we rarely consider at what level the problem exists or where we can solve it. Okay, there's also another problem. There are systems all over the place. They're interfering and colliding with us. Now we're not gonna have time for questions and I certainly can't give you any answers. So I'm gonna race ahead here. A bit more, this is from John Gall. A working complex system invariably has evolved from a working simple system. Are these truths not necessarily? Daniela Meadows says a primary function of most every system is to perpetuate itself. It does this by evolving. If you try to affect that system, you will get a temporary good result at best. If this is all true, we really have a problem. So back to that quote, but things are hard to manage because the system is good at perpetuating itself. It does this by evolving. We can't do an intervention. We can't do a transformation. We can't do an adoption. It won't change the way we want it to. Let's quickly talk about domains. I've seen this in several talks here and you play this game of catchphrase, bingo, or whatever when you go to a conference, you'll hear it can even come up. The basic thing is if I want some biscuits, I could buy a can of dough. And if I just follow the instructions, I'll get some decent biscuits, except for if I'm doing the cooking because I'll probably burn them. But you just follow the instructions, you're gonna get it. There are no unknowns. In the complicated space, let's go to a chef who really knows how to make fine pastries. And they have to deal with lots of variability. They don't know from day to day the quality of the flour is the same, the quality of the size of the eggs, the humidity in the room. If the oven is not really consistent, it might be wavering in its heat. They have to deal with all those variabilities, but they know what those unknowns are. In the complex space, that's like molecular gastronomy. It's a process of discovery. There are nothing but unknowns. We don't even know where we're gonna end up. We kind of have an idea where we are when we start, but what are we gonna learn on the way that's what's important. And lastly is the chaotic space. This is my biscuits are burning. It's the way I cook. You gotta just take action, exercise your fluency. If you know what to do when a fire in the kitchen starts, you do it, otherwise you yell to the family, we're going out to dinner, get out of the building. And so this is what we do. We don't, in the middle of this happening, go, hmm, what could have we done differently? What we do is we say, uh-oh, the biscuits are burning, put out the fire, then we say, next time I gotta sit in the kitchen, not go in the other room, I only found out the biscuits are burning because I smell something burning. That's not so good. You get the picture. And then I can ask the family. We can reassess, do you wanna eat this stuff? And they know when I'm cooking, there's a good chance we're gonna go out for dinner that night. Okay, so this is the reason I bring it up. The tactics and techniques we use will vary from domain to domain. And this makes things hard to manage if we don't understand these domains exist. Now I'm not saying this is like truth. These are just thinking tools that we can use, okay? So the techniques we'll use will not fit the domain we think we're in. So here's the things we've covered so far. And now I wanna go to some practical stuff. I think we have enough time. And if we don't, I will cut it short wherever I'm at. I learned that from Mary Poppendick. She told me once, I can stop anywhere because I've already delivered lots of stuff, so wherever we're at, we can stop. So I wanna cover as much of this as possible though. So these are the things I'm gonna cover and I'm gonna do them one at a time. So turn up the good. Turn up the good is a very simple idea. I learned this long time ago and that's really what Mr. Smith at the nursery was doing. But Kent Beck talked about it with extreme programming. In the first book, his white book of extreme programming explained. He said, when I first articulated XP, I had the mental image of knobs on a control board. It's like a sound board for musicians. Each knob was a practice that from experience I knew worked well. I'd turn up all the knobs and see what happened. So here's what he's talking about. He had experience with these things and knew they were good. He didn't read about them in a book. He might have originally, but a lot of this originated with him. So this is what experience is. Practical contact with and observation of facts of events or events. He's reflecting on it. These things are good. What's the value here? Is there anything meaningful? And then he's gonna do an experiment. An experiment's gonna be, let's see how far we can turn these things up. You know, test it. Figure this out. I think this is very important. Now I read Russell Acuff over the years and you can find some things from him on YouTube. And he is just a really clear thinker and he's a lot of fun. He talked about four ways of treating problems. Absolution, resolution, solution and disillusion. So to absolve it, it's just say, hey, let's ignore it, the problem will go away. Like I used to always have trouble with it. Rain, my hair would be frizzy. If it was a dry, my hair would just be like staphful of static. I don't worry about that anymore. The problem just went away for some reason. We can resolve the problem. What he was kind of saying is that we do something that yields a sufficient result and I think that's when we're dealing with the symptoms. We've hidden the problem from ourselves, but he maybe didn't mean that. I can't talk with him about it. Then he says we can solve it. We actually find the issue and we solve it. And he's seeing none of these are really sufficient. What he's saying is we got to dissolve it. Okay, when we dissolve it, we eliminate it by redesigning the system that has it. Now I kind of buy into John Gall's and Delano Meadows' review on this. When we redesign, we are breaking the rule of these things have evolved. So what do we do about it? So I think there's one other way to think about it. Originally I used the word evaporate. I'm looking for something that has solved in it, but evaporates where I started. Rather than focus on problems, let's focus on what's going well. I've talked to many people about this over the years. This is actually a known thing that other people do so I didn't invent it. And I came up with this word. Somebody actually had a conference or a workshop said, well there's a thing called presolution. And I looked it up in the dictionary. It doesn't exist. So pretend I'm Shakespeare and I'm inventing words. Pretty cool. A lot of problems fade away when we use this approach. So remember all those problems? We notice they faded away. Almost everything on this list stopped being a problem for us. And this is a marvelous animation. I made you nobody like oohed and odd so I'm gonna show you again. These things faded away when we started working as a team. That took me an hour to figure out how to do that. So you better appreciate it. So if we turn up the good on collaboration then a lot of problems faded away. We didn't set out to solve a single one of those difficulties. All we did was turn up. We knew collaboration is good from the experiences we had had. How high can we turn collaboration up? This is the power of turning up the good. However, we will get good things we never even knew existed. There's no way to steer this thing that I know of. This harnesses the power of serendipity. Serendipity is good things that happen by chance. The caveat is we don't know where it will lead. I like living that life. I'm here today because of this. I had no idea 10 years ago I'd be standing in Bangalore talking about this stuff and I just, I'm along for the ride. So we can't know where it will lead. Here's the thing. If we have a small improvements habit the turn up the good really fits into that nicely. So we covered that so let's talk about working smarter. There's a paper. You can get this online for free. It's a couple of MIT professors. MIT is just chock full of good brains and they wrote this paper. Nobody ever gets credit for fixing problems that never happened. It's a great paper and I read it 20 years ago and just condense it down. Effort times capability results in our actual performance. So if we work harder we get a certain amount of stuff done but our capability drops over time. If we work smarter initially we'll get a little bit less done but as our capability increases what gets done will increase. So you can look this up. I'm not gonna go in any more details but I think the crux of their discussion is we should be spending more time on increasing capability, our abilities than on doing the actual work we're supposed to set out to do. That's a real important concept. So again, the tiny improvements habit it combines over a period of time compounds. So let's talk about make it easy. This is to deal with the misplaced focus of management where they say we're gonna focus on making it easy to manage. Instead let's just make it as easy as possible for everyone to do their work. That means the end result will be it will be easier to manage but if we focus on the easier to manage it will make it harder to get the work done and things will the system will break down eventually. That's a Brian's first law. So we would optimize for the flow of the work rather than the output of the individual make it easy for everybody to contribute at their best level rather than the output of the individual because the output of the work is what I pay attention to. I could phrase it slightly differently probably. The end result though we're trying not to get the most out of each person we're trying to get the best from each person into everything we do. Okay we're almost to the bottom. The bubble, okay this was my concept when I got hired at Hunter where we kind of stumbled upon this idea of mob programming. The bubble description came from Michael Sahota and as soon as I saw his diagram of this I said that's what we were doing. So because the system resists change what do we do about it? Let's hide the change from the system. So what I'd asked for was for my boss to act as an adapter to the rest of the organization so that we could operate without interference. And I actually just wanted my team they hired me to work with this team to be able to work without interference from the rest of the organization. My concept was if we can grow that across that department and at the same time help others introduce this concept to their departments we would eventually have a kind of a Swiss cheese effect. What would Swiss cheese be like if it was nothing but bubbles? There would be no cheese at all so that means the old system would no longer be there. The new system would crowd it out but this takes a lot of work so we need to introduce the chance for the small systems to start and allow them to evolve and we need to protect them from the people that don't realize that that's what's happening because the system will crush it. So we're gonna go on to collaborate rather than communicate. The failure to communication, how do we deal with this? This is what we found. If this is true, I just wanna bring us closer. Keep bringing us closer. Turn up the good on collaboration. If we crowd this together now we're sharing experiences and eventually we're gonna share some of this stuff. Not everything here but your truth, my truth become our truth. Now that's not worldwide truth that's just about the things we're doing. So as we add people to the team we have more people looking and experiencing our experience and over time we are now hearing different viewpoints about what we're looking at and it expands our ability to have this attention. So I think this is what was happening for us. This gives us continuous alignment, continuous feedback, continuous proof that our communication is succeeding. We're actually pretty much on time so rather than try to get better at communication let's just get good at collaboration and the communication takes care of itself. As long as we, there's a lot of things we need to do to make sure we're working well as a team. It doesn't just automatically happen. The last thing I wanna cover is leading from within. Now you go go here, Beardy, Bookshelves talking or Fred George and these people are working up here to get the permission of the CEOs and the highest level people and they can make this stuff happen. I'm working from down here. So my mode is a little bit different. I had to learn how to lead from within the team. How can we get continuous improvement or improvements at all? Because there's no hero coming to save us. We have to take charge of this. We take responsibility to make the improvements and that takes a lot of guts. There is no hero so we need to become our own hero. If we can become our own hero and influence the things within our team we can do this for a long time and it's relaxed and sustainable manner. If we're always prepared to contribute the right thing at the right time and in the right way we are leading and we expect everyone else to also lead. So we're always leading and we're always following. This is like that murmuration. The simple rules are don't crash into your neighbor but kind of follow the direction they're going. You know that's the basic thing. You become a leader for a little while. This is the idea of Lagom which comes from Sweden I guess. Just enough, not too little, not too much. Barely sufficient. And we've got all the way to the end and I said no time for questions. You'll have 18 seconds to ask a question. I will share this last thing. I learned this when I was in my 20s. I shared this earlier with some people. The object isn't to make art is to be in that wonderful state which makes art inevitable. My goal was not to make the team get better. My goal was to create an environment where the team could become their own hero. Matter of fact, when they hired me, the bosses that were interviewing me, I said, you think this team isn't doing well? They're doing fine. You're not doing well. The blame doesn't rest with the team. The blame rests with the management. The way for them to become better is to stop having management interfere with the team. If you've been involved in a reorg and things like that, all this nonsense they throw at us but we have actually come to the end of the time. So thank you very, very much. I actually hit it on time. How did that? 200 slides. Thank you, thank you, thank you, thank you. Now I'm here the rest of the day for sure and I'm happy to have any conversation you'd like to have. I really appreciate that you joined me here. Thank you. So I'll clap for you. Thank you, thank you. Look at that, I can't believe. I did time myself like I went through this five times. So there we go.