This is the leadership tipping point workshop. Are you all in the right place? I hate it when people, I start and people then leave right after I begin to speak. Always makes me nervous. I'm Pollyanna Pickston, and I'm gonna tell you a little bit about me and my background, then I'll start with the course. I started out with a degree in mathematics right here from the University of Utah. I then studied three years of graduate studies in theoretical physics. I went out and worked on a manganese mining project trying to decide whether it could bring manganese nodules up from the bottom of the ocean. I wrote the data acquisition system in hex without a compiler. So now you know how old I am, and you probably know I went to leadership instead of write code.  I said, those leaders just get in the way of us doing real work. But they persisted, and eventually I caved in, and I thought, well, maybe I ought to develop a leadership style that was better than the one I was experiencing. So over the years, I have developed some tools, and one of them I'm gonna talk about today, about leadership. Right after I worked at Honeywell, I went back and got my master's degree at the University of Washington in computer science, and then I went out into the oil field, bringing, as a manager, bringing some of the first computers onto semi-submersible oil rigs, because one of them had flipped. Okay, wait, now it is, it's back again. Just don't move, I'll just stand right here for the whole time. Oh boy, that'll be hard. Okay, it's right there. So I then worked in the oil field, and then right after that I went to Assay-Abrambera, ABB as a consultant, building control systems for electrical power plants. And it was there I had absolutely no higher-and-fire power. I could give no one a raise. I was a consultant. I was a foreigner in Switzerland. Was working in a country that had given women the vote in 1973, and that's not 1873, that's a 1973. But they were building fixed-price systems that should have taken one year to build, and they were delivering them in four years. So even I knew that business model was pretty broken. But using the tools that I'm gonna talk about today, we managed to deliver eight systems at one year each, staggering them through the pipeline. So I'm not talking about stuff that is theory. I'm not talking about my great ideas that you ought to go out and use, because they're my great ideas. I'm talking about tools that I've used for years and years and years, and that have proven effective. They are just tools. After I worked at Sabra-Abrambera, I went to San Francisco and worked as a product manager, building work management systems for nuclear power plants. And then I went to Switzerland and built the electronic stock exchange for the Swiss banks. It had failed twice before I got there. Once the Swiss tried to build it and it didn't go fast enough. And the other one, those people called Arthur Anderson Consulting, anybody heard of those? They tried to build it. They gave us 9,000 pages of documentation. And we took one look at it and said, ah, it's not gonna work. So we started the process of trying to build it again. And when I used these tools that I'm gonna talk about today, agile practices emerged. So a lot of people have said to me, how did that happen? We saw pair programming, we saw test first.  The functional spec was finished after the product was delivered. So we had customer involvement. We were taking traders off the floor and turning on to an electronic exchange. They were right down the street and we brought them up the street for focus groups every time we needed to talk to them. Plus we had the head of the functional spec team had been a trader himself. So customer involvement. Everything that agile talks about emerged. Now this was in 1994 and then nobody called it agile. So I guess I don't know what it was, but anyway. So when using these leadership tools, agile will emerge and so now we're teaching people to do these leadership tools so you can help support agile. After that I came back to Salt Lake City and worked at First Security Bank as an executive of the technology department. In 1996 I started my own company Evolutionary Systems which takes mid-sized companies about 20 to 30 million big companies, billion dollar companies to the next level using these tools, collaboration and decision making tools. And then I have been involved in the agile community and involved in the conference since the first one day conference. I was one of the organizers here at Westminster and then been involved in every single agile conference so far. This year I'm the chair of the leadership and teams track. So if you don't like it, you can blame me and if you do thank my committee. That's the way leaders get, right? So that's, I'm doing that this year and in the process I've been one of the co-founders of the agile project leadership network which we started with Jim Highsmith and Todd Little and Kent McDonald and a whole bunch of people who wrote the Declaration of Interdependence. Alistair was there, he talked a little bit about that. I'm now the co-president of that with Barbara Wilders and along the way I ran across some very interesting thinkers and I started Accelenova with three other business partners, Neil Nicolaiason, Todd Little and Kent McDonald. And we do collaborative leadership and decision-making tools and provide these to organizations, consult and train. And that's where we ran into IBM, head on, imagine trying to turn that to battleship but we're managing to make some headway. All right, I've been very active in the nonprofit community here. I was in the Utah nonprofit association board and the president of that organization for a year. They teach at the University of Utah in their professional education department. One day courses on the next ones on leading up at the end of this month, collaborative leadership next fall and Agile project leadership also. Any questions? Oh, I forgot the book. We just published a book. It's out the 29th of July, June, 29th of June, first of July called Stand Back and Deliver where you'll find all of these tools in there described and examples in case studies all over the place. Okay, and excelanova.com, we have more articles, more words, more, all these presentations can be found, everything you need. Anything else? Okay, now I guess I'll start teaching the class. Now you're clear it's a workshop, right? That means you work and I talk. That's the way I like to do it, all right?  Sorry about the color, but when you get the real slides you'll notice how they're not really pink, but I don't know, it's some technology glitch here. Okay, let's get started. This is what I call old school leadership. Some people call this command and control. Some people call it transactional leadership.  That's the transaction. About 80% of our leaders are still doing this in our country. It is managers change, nose the answers, bureaucratic. Leader makes all the, and it's authoritarian. Anybody work for a leader like this in your past? I know you're not doing it now. Anybody? How was that a good experience for you? Anybody? Nobody raises their hands. How many of you are still working for that leader? Oh, there's still a couple of them. Well, now I know why you're at this conference. There should be a job board out there. The most interesting thing right now is there's some work done by Robert Sutton. You'll see his writings lately in business week. I find fascinating. Has done some research at Stanford that shows that anybody that gets in a positional power, that means just a little positional edge over another person, stops making decisions based on all the information. So they're making decisions based on less information. So the concept is that leaders shouldn't be making any decisions. It's a shift in the mindset. You come up through the organization, solving problems, you become a leader, now you have to help your teams solve the problems. And they own the decisions. They're closer to your customers. They're closer to the needs. If you've got a process that needs to be changed, who knows why it's not working? Anybody? The people in your organization, right? How many of you know the processes that aren't working in your organization today? How many of you know the people that aren't working in your organization today? Now isn't that interesting? We all seem to know and not much gets done about it. Well, I'll give you some tools today to talk about that. This is what I call collaborative leadership or a new school of leadership. Embraces change. That means when people walk up to us and say, I need you to add this and get it out tomorrow, you go, I'll think about that. Instead of saying no, we're not doing it. Next release. Fosters new ideas in the organization, collaborates, cross the silos, gives ownership, the key fact here, and is influential. So the job of the new leadership is to unleash the talent in the organization to solve the problems inside the organization by using, because the answers are in your organization. We have, at Acceleno, we always have this problem when we go and talk to people about it and they say, why should we outsource our intellectual problem solving to you? And we say, we don't do that. We give you a set of tools to let you solve the problems inside your own organization and help you make better decisions. Does that make sense? Okay. And none of us are as smart as all of us is a very important concept. This does not mean group think. This means that we need to get the right people together in the organization to start talking together. I'm gonna briefly touch on the collaboration model to set the reason why we have to do step up and step back. Collaboration model looks like this. You create an open environment. What's an open environment? No boundaries, what? No fear. What else? That's it? Room to make mistakes? Trust? What else? What's a participatory? No hierarchical structure. Open ended? Something to do with creativity? Okay. Anything else? Lot of communication? Visibility? You guys, I told you you have to work. Come on.  What else? I'm warming you up, there's more to come. Uh oh. Presenting innovative ideas? Presenting innovative ideas, yeah. Willingness to listen. Integrity. Honesty. My favorite, non-judgmental. And safe. Those are some other ones. Alrighty, the second step for the collaboration process is the way to get the right people. That means not just our buddies, we need to get the right people in the room, include marketing, sales, everybody. All the different kinds of people that you're gonna help make. Finance, how many of you get marketing to come to your team meeting? Your decision-making meetings, yeah? Look, there's some here, that's good. All right, it's very, very important. So I'm gonna use, or people that are here in the room. One time I went out to work for a company and they, oh well, it's Headwaters, they're sitting in the room. They put chemical on coal, make it reduce the emissions of the coal, which I think is great. And so they're a green company and they try and go down the value stream being green. And so they decided they would try and develop a product based on this fly ash that comes off the burned coal, all right? So they say, let's develop a new product for that. So they go out and they develop a thing called aerated concrete. And it looks like the stuff on the back wall back there. Looks quite cool, architects like it. It's interesting, you don't have to paint it. It's kind of, can be strong, all sorts of things. They go out, they build a plant and that first stuff comes off. The first pieces of this aerated concrete come off out of the plant. They put them on trucks and 150 miles away from the plant, they deteriorate. And then they're telling me this story and I go, how many people were involved in designing and doing and building this plant? And the CEO standing right behind me and he says, one. I said, really? It was very hard for me not to say, what were you thinking? But that's why I was there to help them be more collaborative and do it. So they now work with everybody in the organization to talk about with finance, marketing, sales, and customers. Is that true, you guys? Yeah, they're nodding their heads, I didn't lie. All right, foster innovation. That's creating the conversation, beginning to have the conversation. We use a collaboration process. People write sticky notes, they brainstorm. You've seen this all over in the Agile community time and time again. And finally, the last step for a leader is to, in collaboration, is to step back and let people do their work, right? And let them go after the work. In other words, let them have the ownership. Out of all these steps, which one is the hardest one for leaders to do? Step back. I guess that's why you're all in this class. Alrighty, because that's what we're gonna talk about. We're gonna talk about how to step up and how to step back. We call this the leadership tipping point. In other words, we have to step up without stifling innovation and we have to step back and keep the focus. In our line of business, we call the leadership two-step. Right there on the right.  Do not do this at home, in other words. So that's what we're gonna talk about. Let's start with the side that says how to step aside or step back because it's the easiest one to do, all right? So we have to have leaders to unleash talent, increase productivity, develop great solutions. They can't just be good anymore, we're operating with less. We have to be innovative. You can take all those lean classes, they'll give you more resources, help you be more productive. Now we have to unleash the talent to be more innovative and in great solutions. And how do we do this? I believe we do this by giving ownership. Truly giving ownership and not taking it back, all right? Soon as a person walks in your office with a problem and you say, have you tried this, what did you do? Hmm, pardon?  By giving him the solution, you take ownership. Asking for status reports, you take ownership. Asking for design reviews and approvals on your designs takes ownership. It's a fascinating concept, the way we've waltzed right into this process. At IBM right now, there's an architect there who will not approve the designs from the team. Because when he does, he says, I take ownership. And what happens? The team members are disenfranchised, they don't own it anymore. And when they build it and it doesn't work, they say it's my fault, you told me it was okay. They don't take the ownership back, all right? Very tricky. Now, he has open hours, he'll spend all the days they want to talk to him about it, anything they wanna do, but he will not approve their designs. They own them, they deliver, they make the results happen. Very interesting idea. All right? I use the three Cs from Alfie Cohen in his book, Punished by Rewards, what I call his work. The three Cs of how we can motivate people. People are not motivated by money, right? Everybody agree? I don't wanna go down that pathway today. If you wanna argue about this, there's a break right after this. I worked with a very, very pretty large architecture firm of 120 architects. And there were seven principles that own it. And I sat down with them and I said, people aren't motivated by money and they said to me, well, that's not true, they are. I said, really? I said, I'll seven of you make pretty significant salaries by owning this company. I said, and if I asked you to double your salary but you would never be able to draw or design a building again, would you do it? Not one of them took the deal. So people aren't motivated by money. I believe they're motivated through things Alfie Cohen talks about in his book. You can read the only one chapter you have to read. It's called, it's chapter 10, page 181. So all you need to do is read that chapter. Don't get hassled by the first half because you'll probably find that very interesting anyway because he talks about how to decouple evaluations from pay. How you do it and why it doesn't work. It's totally documented. If you're having HR problems with this issue, you can use this. But the second half of the article of the chapter talks about the authentic motivation that 3C. The first one is to foster collaboration in your organization. You need to let people make their own decisions. As far down in the organization as you can get them. Now I'm a total participatory leader. I don't make any decisions. When I built the electronic stock exchange for the Swiss banks, I was technically dead. I couldn't tell you what language to use and why. I couldn't tell you the interest, it's a broadcasting system, nothing. I'm technically dead. The whole project, I made one decision. And that was, one of the team leaders came to me and he said, if you don't get Andy off our team today, the team is gonna throw him out the window. I said, good, I'll take care of that for you. That was the only decision I made for a full two year and a half year project. So I can't make decisions anymore. I have to let other people, now I own the decision process to make sure they make a decision but I don't make decisions anymore. So they had the option to build the workstation from scratch or to build the workstation, buy it and modify it. In other words, you could build the Rolls Royce or you could take a Volkswagen and upgrade it. That's what I was thinking. They were having a tough time trying to decide what to do. They were very nervous. There hadn't been a stock exchange built in 20 years. So all the new technology hadn't been in practice. I mean, when they built the other ones. So we could use any new stuff we wanted. But they were still nervous. So I saw them in their debating and I walked by and I said, look, I believe that you will succeed at either solution. But do not make this decision based on fear but make it and let's move on. And they decided to build the Rolls Royce and they did a fine job of it, actually. The second C is to let people choose. This is the biggest problem we're starting to see in organizations. You let people choose how, what, and when. Now the how is a little one here but that's the big one. Was it Drucker who says we hire the very best? Right, anybody? Anybody feel that way ever in your lifetime? At least once. So what's really going on is that people, we can't always pick what. And we do know that we're kind of boxed in on some of the time. When it has to be delivered. But we can pick what's going on in that timeframe and then we need to stop telling people how to do stuff. They know, why did we hire them? What are they thinking? So I worked with a focus group inside IBM when we started working with this class and I met with these mid-level leaders, senior project leaders and they said, we're tired of being told what to do and how to do it. It's rampant in their organization. Then I meet with their directors. What do they say to me? I'm tired, no, what they say is I'm tired of being told what to do and how to do it. So they are propagating the whole concept right down through the organization. And I went, shh, somebody should stop. So it's very important on how to do it and by when. You know that they're absolutely missing something. They're absolutely missing something? Missing a part of the project or some part of it that's really important. That's really important? How did they miss it? Did you ask them? Yeah. What I would do is I usually get everybody together and agree to the purpose of the project, goals and objectives. I have everybody write them down on sticky notes and put them up on the walls to see how in line everybody is. Then we have a conversation about getting in agreement and what the decision filter is for the project. How are we going to decide what needs to be done and not be done? Is it parody or differentiating? Those kind of concepts. Are we trying to gain market share or are we trying to hold market share?  Eventually when they start down the pathway they'll find the missing piece. I have to trust that they will and I do. Any other questions? Alrighty. The last one is content. People have to have interesting work to do. Now I don't think we have this problem in the IT world. I think we have plenty of interesting work to do. That's what we all are attracted to in this place. It's interesting work, keeps the mind going, problem solving, logic, will it work, won't it work? How do I da, da, da, da? It's quite interesting. When I worked with this architecture firm, I got together with the middle level leaders and they said, we have this problem with our drafters. They keep watching TV on the internet and doing their emails during the day. And I said, what does that mean? They said, well, we don't think they're doing the drafting work.  And they said, well, let's turn the internet off. I said, really? What's that message if they turn the internet off? We don't trust you, loud and clear. If you don't have trust, your team knows it, trust me. They'll know it and then they will not probably be at high productivity.  And they started tossing around some ideas of what to do and I said, you know what? I finally got a little frustrated. I usually don't volunteer and advise. I said, look, you guys aren't giving them interesting work to do. And their response was this. But they're drafters. I went, what? So you guys obviously think they're not important. I said, could you do your job without them? And they go, no. So I said, how about you involve them in the design process so they can see their contribution and they understand your vision so that when stuff comes down to them, perhaps when it comes down to them, they will be able to act as a participant in the decision-making process.  That's what they started doing. This is a company that, using these tools, saw a 90% increase in revenues in the first year. Just amazing. Little things like that kept going on. All right, you have to trust first because suspicion is a permanent condition. How many of you trust everyone on your teams today? I always had this. Nobody raises their hands. One person. Your team knows it. What have they got to do to earn your trust? How long have they got to try it? How long have they got to work at it? Maybe. But how many times have they got to prove that? Before you'll totally trust them. How many of you have ever worked, yeah, right. It depends.  One, two, two people. Yeah, if you're lucky you'll get one in your lifetime. It's a very interesting phenomenon because as soon as you put them together, they have trust because you trust them. They build trust. They form a very quick team. They move quickly. But we don't get to do that. So you have to build a culture of trust, all right? I do teach a whole course on this. I think it's coming up soon. But I'll give you the basics. I believe that you can't make people trust each other. Give it up. You can't change people. You can only change processes. I guarantee it. So that's my best leadership tip for the day. I believe that you can create a culture of trust as a leader and that's all you can do. It will foster trust in the organization. You first have to resolve the trust. If there's broken trust on your team and I believe you have to, if you should remove them and unless the team needs them and you'll keep them there and work with them as long as the team needs them.  Broken trust is like a rope that's been cut. It's gonna take a long time to put all those threads back together. And is that rope ever as strong as it was before? Anybody? Is that rope ever the same? No. So as a leader, you have to realize that price tag if you're going to rebuild the trust in the organization. Fixed broken trust among the team members. What I like better is to get a hold of a team that does not build trust yet. And I start working down the pathway with things like removed, debilitating fear, let everybody understand why they're all contributing, put them together and give them a task to work on immediately that involves everyone, give them positive feedback and continuous feedback and get out of their way and let them do their work. So, but the remove the debilitating fear is the big one. All right, so there's more about this. I wrote an article about this in Better Software last September and it's out on the website. I'm more detail on this topic. Okay, so what are my step back tips? Hmm, my first one is to let the teams figure out how. If you can't stand it while they try and figure it out without stepping in, leave the room, leave the building, go on vacation, do anything you can to get out of the way. They have to solve the problem. Create a safety net. In my architecture firm, all the seven principles had to sign off in the design before it ever went to the customer. Now, at 120 Architects, you can see where the bottleneck is and Agile talks about bottlenecks. This is not good. So I said, well, we can't let it get out to the customers without it being approved. I said, really? So what they did though, they started to build what they call a design charrette or design walkthrough or review and then the principles show up if they want or don't want. Okay, so it's a little before they developed, delivered to the customers, they have the internal people come in and walk through the designs. It's a very effective piece. If you have to get the right people and the right seats in the bus so you'll never be able to stand back, which also means the corollary. Have you all read this from Jim Collins? Anybody read this book? Good to great? Great book. All those that haven't, you're in for a treat. It's a great airport book. One chapter talks about seven principles that made great companies and then there's one chapter for each of those principles. It's a great airport book. So get the right people and the right seats in the bus. Jim Collins says, and let them drive that. I don't go down that pathway because that's too scary for most of us. But it's true, it will work. But the corollary here is get the wrong people off the bus. I talked to executives and they tell me, I said, how long does it take you to get rid of people in your organization? They say, 18 months. I said, are you joking? I said, that's terrible. Teams will self-select. Teams will tell you what's the right person to be on their teams. But if you don't take care of it for them, they're gonna really be mad at you. So I had the case where in the stock exchange, one of the teams had hired somebody. They picked their own people. I certainly can't. I'm in no position, I'm technically dead. I'm in no position to decide what kind of person they need on their organization. So I said, they picked this person and I'm sitting in that cafeteria and this one person, a couple of layers down, said to me, how long are we gonna have to cover for this guy? I said, what do you mean? He said, well, we gave him six weeks learning curve because the stock exchange is a little complicated. But, we're now going into the six, seven, eight, nine, 10th week. He's a good guy. He's got great skills. But he's not for us. Is there another place he can go in the organization? Because he understands the system now. So instead of backstabbing him and trying to diminish him, they just said, look, it's not for us. So we moved him into another seat. They got another person and everything worked out great. Delivered the system. Okay, so get the wrong people off the bus and as everybody knows, if you can't get them off the bus, sideline them. I'm not very happy when I can't get somebody off the bus, but it doesn't happen very often. So, but, I'm not happy when that happens because they're not very passionate about what we're doing and motivated and that and that. I'm not gonna fall into the 80-20 rule. 80% of my time being taken care of, 20% of my team. I'm not gonna do it.  So that's what I let him do. And if they're a developer, I let him comment code. We still do that, don't we? Still commenting code, everybody? Maybe? No, no. You don't need it, yeah, it's Agile. Agile code, no comments. Good job, I like it. So, that's all good and well, however, to step back. But, what if this happens? Anybody ever have this happen to your project? It starts going off the cliff on time, on budget. Somehow, it's going off the cliff. We have seen Agile projects. One of the things that started concerning me a couple of years ago is we're seeing Agile projects come out using Agile methods just great and deliver and still the wrong product. I said, what's wrong? So we have to be careful when our projects start running off the cliff. So the idea is, when should we step up? So I want you to take a minute, because here comes some more of the workshop part, and write down what are the red flags on your teams today when you know they're struggling and they're kind of having a tough time. What are those? So take a minute and write down all the ones. Everybody got at least one? That's seminar speaker you've done yet, you know? Everybody pointed out to me, I started getting seminars. You're supposed to say if everybody got one. Okay, anybody? No updates. What else? Silence. Ashen faces. Pardon? Ashen faces. Oh, ashen faces. You know that, I find this number absolutely phenomenal is that 93% communication about emotions with body language. I just, 93% find that really surprising. Okay. Non-participation. Non-participation. Okay. Change is a number of hours worked. A lot more hours, fewer hours. Change is an hours worked. Worked. What else? Lack of common goal. Lack of common goal. Closed or discussions? Oh, no. Retrospect. What else? Working on wrong things. Working on wrong things. What else? I hear the same questions going back and forth. Same questions. Lame or? Like deflection. Pointy name? Tatl-telling. Oh, tatl-telling. That doesn't happen. Tatl-telling. I thought we gave that up. Constantly waiting on somebody else. Constantly waiting. Someone else. Right? Really small tasks taking really long time to accomplish. Small tasks. It's taking long time. Scope creep. Scope creep? I thought we'd get rid of that word with agile. Didn't we would place it before an agile? Scope creep still happens? I can't believe that. People pitching on other projects into the faster. No. People pitching about the disaster. Edgy knows me. Edgy, communication. What else? Complex design. Oh, complex design. Over-engineering. What else? People complaining of being spread too thin. Oh, spread too thin. After they volunteered, right?  You let them volunteer, correct? Anything else? Well-tried homie. Pardon? When they tell me. They tell you. They don't try to improve. They don't try to improve. We're getting enough thanks. No improvements. What else? When somebody else tells me. Someone else tells me. Yep. Someone else tells you. That one spoils the barrel. Bad apple. That's a lot of them. Shootski. Now we got them, what are we going to do with them? You think we could just leave now and you could go home and say, what did I take that class for? So what do we do? First, we've got to get the team back on track as a leader, right? As well as maintain the team integrity. We can't take away their integrity. We can't solve the problems for them. We can't take away the problem-solving ability. So how do we do this? Let them do it, right? So this is what I do. I don't ask them what's wrong because what happens when I ask them what's wrong? Pardon? Right, they're pointing fingers. What else? What are they going to tell me? Nothing's wrong? Nothing's wrong. Right, nothing's wrong or I'm going to get everything, correct? One or the other. I also don't ask them where they're stuck because they'll say, what do you mean I'm not stuck? Right. Alrighty, so I asked the team to describe their work, their approach, the pathway they went down, but mainly why they chose those pathways and those approaches. So I'm really trying to get them to discover a new view of the problem.  Has anybody heard about this?  Now I've done this on projects. I cannot do it for myself, my own team, but I can do it for other teams. So you bring it and it's fascinating.  So what happens when you do here? What happens when you go there? What happens when you go there? It's like a mini walkthrough of the project. And it's very fascinating and it really helps people see what's going on. So there's a problem you said, well, somebody left something out. A zero gravity thinker can help them find it. So the idea is to help them discover a new view. So what are step up tips? You have to reinforce ownership by not giving them the answers and not giving them the solutions. You might not have the right solution anyway. They may have a better one. So the idea is to help them keep the focus. I sometimes tell stories. Other experiences that happened to me in my way deep past now. It's really hard to explain stories about writing in hex, but sometimes they get it. I actually do know how to write in PHP, but oh, that's boring. You have to ask questions that help people discover the solutions, not give them the solution. Alrighty, this is my favorite question is how would you like to solve it? When they come in my room, they come and ask me for a solution. The other one is Niels, which he said, what would you like me to do? His worker bees back there shaking his head. Yeah, I get that all the time. It's really fun. So what would you ask? So what I want, I didn't know this is really easy for people to do. So I'm going to let you practice. Here comes the workshop part.  So I want you to practice. I know it's so easy to do. It is really fun and then after you've done that, then switch and try it again the other way.  So remember, the worker bee wants to get the answer out of the leader and the leader is going to make sure they don't give it to him. Alright, so pair up around, find somebody to work with and try this out. Because it's really easy to do. You all just went, no problem. Okay? How easy was it? On a scale of 1 to 10, anybody find that difficult? It gets easier. If you practice. Anybody have any good questions that they use right here? I was just wondering if the girl got a question this morning about the different cultures. Have you worked with a control culture? How does that influence you? I can't get more. Our project. I could have looked down and said just give me an innovative product and get it to market. That was it. Okay, alrighty. They went off and he trusted the team and he trusted the leader and the status report was a phone call. How's it going? Everything okay? Okay, thanks. That was it. You remove obstacles. Status report. Results. I want results. I don't need status. Any other questions people had? Right there. This wasn't exactly a question, but it occurred to me that you can be directive this way by choosing when to stop asking questions. When they get the right answer. That's true. You can do that too. Or choosing a story is a problem. Yes, choosing a story. You have to be very careful how you use this. It is so tempting when you know the answer. If they're looking for something very specific, it's very tempting to give it to them. But the problem is that they keep coming back to that well over and over and over again. But it's in our dialogue. It's so tempting because you know the answer. You know what they need to do to solve the problem. You just want to give it to them. Without letting them think it through and figure it out. They know how to solve the problem rather than you think it through. All right. This is very tricky. I kind of have this general approach. Mike drives my family crazy of answering questions from questions. The thing I find difficult to tell when or how to deal with the situation where it's pretty clear the other person is now frustrated with the fact that we won't give them the answer. And so now the discussion begins to deteriorate from helping to find the answer to whether they aren't interested in anything to have to say anymore because they've just decided they're not going to do anything for it and try to redirect that kind of situation. That's one of the toughest things. Here. I noticed, I was surprised how dynamic the conversation was and how there was less tension. Because a lot of times if I provide a solution and then I get the sense that somebody isn't going to do it or doesn't like it or whatever, then there's this sort of... Now we're starting an argument instead of this. So I was really kind of just surprised at how dynamic the conversation was because before I thought that if I were to just ask questions that I'm almost playing a game but we actually came up with some solutions to things that I wasn't expecting. Wow. That's good. I've been learning a lot recently about anchoring and when a leader makes a decision or whatever how people tend to... That's the anchor decision where people tend to migrate towards that whether it's a good solution or not. And so again, it's tempting because when you make a decision whether or not it's a good decision or not people are going to want to try to talk because that's now the anchor decision. They're going to base their decisions and migrate towards whether it's right or not. Yes. Very tough. Okay, so Mr. Neil Nicolayson is going to come up here and do this piece. Oh, Neil. This is his tool. He just showed up today to make sure I gave him credit because usually I try and steal it from him. Now he developed this micro... what we call the macro leadership cube as opposed to the micro leadership cube. So it's a tool to help you about stepping up and stepping back. Okay. So you go out of here and have something to do. So it really looks like this. It's a cube made up of different elements or what sometimes we call boundaries of a cube. Purpose, the number of people, considerations, market window, budget, but very... at the very top is the results that you must achieve. All right. So you build this cube with your teams together, collaboratively. And when they work inside the cube, you leave them alone. All right. And remove all the barriers that they're seeing or that they keep asking you about. That is one of my favorite questions. What's getting in your way of getting your job done? What's getting in your way of reaching, you know, the end of the iteration or whatever is bothering him? To help teams grow, we use this by making it a bigger cube. So as they get, so they reach for more and reach, do more things and have more responsibilities, considerations, purpose. And we stand back even further. And I love this part. But when they start coming out of the cube, that's when you step up. And when they start vibrating, bouncing, coming across here, one of them would be when they start thinking about something being differentiating instead of parity. When they start over-engineering something, that's parity. That's the biggest weakness we have in IT. 64% of features are rarely or never used. And we over-engineer stuff. Remember the old days when developers would sit around and say, oh, just let me add this one more feature. My users will love it. Just one more feature. My users will love it. Remember that? And then all of a sudden, you'd miss the market window. What's the business value? Zero. You know? So you have to be careful. So when you build this cube, you define these boundaries. And when they start stepping out, you make it a smaller cube for them. But when you start building these cubes, you must quantify and be able to measure what goes on each one of them, okay? So for example, my contract with IBM. It had a fixed budget. We had to do so many pilots. We had to reach 90% acceptance rate inside the organization. We had to do 15 pilots. We had a certain budget. It had to be done by the end of June, all right?  We did Italy, Germany, England, California, New York, North Carolina. We reached a 98% acceptance rate inside the company. So we achieved our goals. But we checked those evaluations at the end of every class all night long, reading to see what we were doing right. So that would be my cube for my contract or Neil and I's cube for our contract with IBM. So I want you to take a minute and write down what your cube is right now. What you think your cube is or your cube is for your teams. So take a minute and write down the edges of your cube. It can be anything. It doesn't notice we didn't put only one that I need you to have for sure as results. After that, I don't care. Budget, people, considerations, parity. You're doing a differentiating project, a parity project, a legacy conversion, whatever you want. Make your cube for yourself or your team, either one, and make it quantifiable and measurable. How do you know you're successful? How do you measure success? Okay? So we had a project where we had to open up 11 new sites, which means we had to get network connections to 11 new sites. And our sites and our business are in the middle of nowhere, with addresses like turn right at the chicken and go 6.5 miles and then turn left and go across the ditch. And so it was a challenge to get our network connectivity to these 11 new sites that had to be done during 2008. The drop dead date was December 31st, 2008. If we had the network connection lit up on January 1st, 2009, it was too late. And so the walls of the cube were things like internet connectivity at each location, working by December 31st. Didn't have a budget. The budget was determined by each site manager at each plant. How much is the internet work? These are the options. You pick which one works for you. And that was pretty much it. The network manager figured out how. As the leader, I didn't tell him, I think you should use satellite connections. I think you should use YMAX. I think you should use cell phones. I didn't tell him anything. So just go figure it out, whatever you got to do. I didn't tell him how to communicate with the plant manager. I didn't tell him how to define value for each site. Does that make sense? He figured that out. So the how I left to him, all I cared about is, no later than December 31st, 2008, every site has a working internet network connection. And that was all we evaluated the wrong. When there was a problem, we had one site to go. We were counting on and the scheduled installation was December 19th. And I thought to myself, I've never yet had a telco provider hit a date. And if they miss the following week is Christmas. The following week is New Year's. We'll miss it. So I saw my network manager heading towards a cliff. So I could sit and tell him or asking him, what's going to happen? What do you do? What's your backup plan? I just asked him. What happens if Verizon, in this case, misses their date? He said they won't, is it? Okay. So just tell me what if. Just do a what if for him. I didn't tell him what I would do. So he went back and figured out what to do. What he did is he put in a mobile satellite station just in case. But I didn't tell him how. All I cared about is all 11 sites have a network connection by December 31st, 2008, that the plant managers are happy with. That was it. Results. They actually did. I was fine. But the mobile satellite was fine. But he figured that out himself too. My solution would have been to get AT&T on the phone, have Sprint ready, whoever it is, I want an alternate provider in there. He came up with a better solution because I didn't tell him how. Okay. Anybody got a cube you want to talk about for a minute? Sides, right here. So my sides are at the top is user acceptance. Right. And that's measured by did we accomplish something. And the sides are technology. Is it a standard technology? The cost or the estimate? Did we meet the estimate? Does it meet the requirement? Was it efficiently tested? Was it efficiently deployed? And did we consider economies of scale? Okay. Anybody else? You have one? Yeah. The client being satisfied with delivery and all agreed upon visibility, artifacts are updated in present. Do you have a budget? Well, that's the client is determining the budget. Okay. So sometimes they increase their scale. They increase the budget. So the way it would be measured would be with you know, regular contact, contacting customer regularly and asking, are they okay with what you're doing? What you're doing, yeah. Contracting shops. Right. So those things can change. Okay. Right. Perfectly results. Do they have it on there? Customer satisfaction, quality, commitments met and the development team satisfaction. How do you measure those? The results? Results, based off customer satisfaction. Okay. So you get a survey from your customers and how many of them have to be happy? Good or excellent? Right. So good or excellent? What percentage of them have to be good or excellent with your customer? You better define it so you know. IBM, I'm not going to wander around saying you have to have how many people think this is a good or excellent class? Right. I'm going to try and reach 100.  90. My own satisfaction number for teaching a class is 80% of you will stay awake to the end of my class. That's for me a success factor. I'm a happy camper if that happens. I'm not worried about outliers. So I don't care what you write in the evaluation form. I do too. Anything else? Anybody else? So you need to figure the number out and share it with your deems so they know the number, right? Right. Okay. So we just talked about how you know when they're out of there. The other one is that your cube, their team's cube, should be inside your cube, right? What happens when they're shutting out over there? Maybe they're doing something you shouldn't be paying attention to. You should be paying attention to. All right. I also can use this tool for leading up. Talking to your manager.  I mean, you don't have to write it that way. You know, they'll go, what planet are you on? Oh, I took Polyana's class. Polyana said, Neil said, we do it this way. So anyway, talk about the results, purpose, considerations, anything else that you've got that you think. Agree with them and then just say, okay, now I'll go do the work. I'll let you know how it's going. So this is a very powerful tool for managing your manager. What happens here is this line right down here between stepping up and stepping back is what we call your leadership tipping point. You need to know what that is. When you step up and when you step back, practice. Not giving solutions and taking ownership. All right. So I want you to take a minute. Here's the hardest one. Some of you have already talked about this already.  Take a minute and think about what those might be. Those flags that tell you, I want to step up, but I should step back. What are they in your own life? Because I can guarantee you're going to hit them on tomorrow. Great. One of you is going to hit one of them tomorrow. What are those flags? The step back red flags we call them. When you want to step up and you should step back, set your intentions in other words. Anybody got one? Here. You actually gave us a very good one. That is, and I felt this many times, a feeling of anxiousness about what is going to happen. They fail. You might see that they're going to fail. Yes. You want to relieve that feeling of anxiousness immediately, but it's not such a good idea. Yeah. We're moving the anxiousness right here. When you start getting too many questions from your team, do you require them to make decisions? Oh, and they're asking you to make decisions. I'm sorry, we can't hear you. She said you get too many questions from the team asking you to make a decision. Too many of them. Yeah, of course you want to. You get tired. You go, oh, I'm tired of hearing the same question. Let me tell you the answer, right? Right here. When I'm too rushed to take the time to go through the process of asking a question. Yeah, when I feel too rushed, I'm under stress to go through the process of asking the questions. Here, Michael. When there's a voice in my head saying, they're not getting this, and I think there's two paths to that. One is I feel calm about that. Like, okay, well, that's what's going on. I can just be with them. The other one, I feel anxiety about that one. I feel anxiety about they're not getting this, that's the problem. Right. Okay, it's fine. You can step back. When I feel anxiety about stepping back. Right here. Applying your current standards that you have for yourself to others. Applying your old standards to someone else. That's a big one. Right here. Certain personalities. Certain personalities. That's great, but it seems like I'm already disagreeing. Like, that person you don't trust comes in your office? Right. Oh, yeah, that's a good one. Anyone else? Yeah. If I don't know the risk of their failure, sometimes I'll be afraid of allowing them to fail. Okay, afraid to let people fail. So I don't know the risks. When you do know the risk of failure. When you do know the risk of failure. Yeah. Tough one. Build that safety fast. Building it as fast as I can go. Okay, anything else? When you stop seeing results. When you stop seeing results. Yeah. When you see that your team are constantly exchanging emails leading to nowhere. Yeah, right. And you get long CCs and BCCs and blah, blah, blah. Oh, yeah, I love that one. All right. So in summary, let's talk about this. We talked today about stepping back. We talked about the three C's from Alfie Collin, Collaborate, Choose and Content. We talked about fostering trust and letting your teams find the solutions. And stepping up, we talked about free-focusing the ownership, not taking it back. Help them focus through questions and we talked about the macro leadership tool. Here's our information. Now, I should announce that we talked about the IBM class here. We will teach this in Salt Lake City publicly on the 21st of July. We'll teach all four modules. We will only take 20 students. So you'll be able to sign up for this on Monday on excelanova.com. Any of you are interested? That is the decision-making, better decisions module, how to collaborate in collaborative leadership, how to build a culture of trust, and how to step up and step back. Plus problem-solving using those tools. So we'll do one of those in town, just so you're interested. And that's where you can find me. If you have any more questions or want to talk to me, ask me stuff. What else? I have time for about one more question. One right here. Question. So what do you do when someone doesn't want to take ownership of the problem? They can see maybe the risk involved and they want you to take it because they don't want to put their butts on the bus. Probably wrong bus. I got them on the wrong bus and the wrong seat on the bus. People want to work. That's the other thing that I did. I talk about this in... I think in the collaborative leadership class is people do what they're passionate about. And then I look for the best fit in the organization or they look for their best fit in the Ricardo Samuels book. He lets them find it. And then the organizational fit. Where they fit in the organization and what they do best of passion. And I want all my team members to be operating right there. Including, and if they're not. They're not motivated. You can't trust them. They're not going to take ownership. But if they're there, they are. Now I can fix, fix. As a person, I use this. I have this sticky notes for these inside my door, my closet, my living room of these. I can do something here and I can do something here. I can't fix this passion. I got to be passionate about it or not. So that's my wrong scene on the bus. Anybody else? Okay, that's it. Don't forget to fill out your evaluation forms. Everybody wants to know what to do next year if we want to do this next year. So was this useful? Okay, alrighty. Thanks for coming.