Execute & Measure The Results | Dave Kranzler

All right. So that was about assessing and about building a human network, if you will. Now let's— I am going to quickly run you through just a few tools that we use, and this is by no means a complete list, very partial, but a few critical things that I have used in the past that helped me a great deal that may help you as well. Okay. So without going through the detail, what did I say before? A business process, no matter what function you are running, engineering, finance, sales, have a process. Have something that is repeatable. The value of this is you spend all the mental energy thinking about the hard problems and you don't waste mental energy on the routine things. As a friend of mine used to say, make the routine things routine. And then we don't have to talk about them and you save a lot of time. Make a process, write it down. I think that is a great point. I am not going to prescribe one for you. This one has worked for me. It has to fit the needs of your business. A couple of other sort of what do I do every day kind of things. When you have a critical problem, how do you run a meeting? There are all sorts of trainings you can take on running a meeting. It is really very simple. Have something to talk about. You need to have a charter. Whether it is a meeting, whether it is a task force, whether it is a program team, whether it is a product development team, There needs to be some goal, if you will, that they have to accomplish. Talked about metrics before. How do you know how well you are doing? If you have a critical problem that you need to put a task force on, you better know when you are going to be done, otherwise it will go on forever. Who is responsible and who is involved? In other words, if you ever heard the expression about pigs and chickens, one of them is committed for breakfast, the other one is just involved. Quorum are the people who are committed. They are the ones who are accountable. They are the ones who need to be there at every meeting, and if they are not there, you can't have the meeting. Invitees are everybody who may be involved. Sure, you can come, you can listen in, don't distract us. The very simple who, what, when plan. Again, I was well into my 40s before I heard of what one of these things are. It's the simplest thing in the world. But if you need to get stuff done, knowing who is supposed to do it, what they are supposed to do, and when it is supposed to be done by is the most basic tool you can use. A lot of people try and get away without one. Don't. And artifacts. What are the documents we are creating? What are the things that we have to produce? Another thing we did at Cypress a lot of is called precise question and answer. This basically means How can you ask a question that can be answered? And are the people answering the question that you asked? It's a very simple concept. Has anybody wasted time in a meeting or asked a question and gotten a very lengthy and irrelevant response? Yeah. Okay. See, I hate that. There are times in life to philosophize. And there are times to have very long meandering conversations, typically over a glass of scotch. Typically meetings are not one of them. So there is a company called Vervago, I think, that has a PQ&A course. It's not only a way to communicate, it's almost a way to think. And it's a way actually for me to assess. I mean, if I ask a question and someone won't answer me directly, I'm starting to form a little bit of opinion on how good they are. So take the course or read the books. They use it at Microsoft a lot. Saves enormous amounts of time. And it just becomes sort of a way I do my business every day. Now, a couple caveats. In some cultures, it's considered rude. So be respectful of cultures. Some places in the world, it's more polite to give you the context. You should work with that. As long as it doesn't slow you down too much. Also, do not attempt this at home. It doesn't work very well. That's another experience I have. But again, when this is done well, it creates credibility. It saves time. It facilitates communication. You guys are all busy. You can't waste time philosophizing, again, unless the scotch is at hand. When it's done poorly, absolutely the opposite. It's a little bit of a trick. You should try it. Thank you. I mentioned dashboards and Donald Rumsfeld. Again, this is going to sound a little classic to you, but it is really true. What you measure improves. If you get people to think just how to measure it, all of a sudden they start thinking about how to make that metric look better. It is almost automatic. We use a slew of dashboards. Who here uses the Atlassian toolkit? Jira. Fantastic toolkit. Love it to death. We manage all of our tasks using Jira. This is not a Jira course, so we are not going to go through it. But I get these gorgeous dashboards that tell me how many bugs I have got and what stage they are. Burndown charts that tell me where the team is. A dashboard that I create for my peers that tell me where a product is through its development process. Just by thinking about it and writing it down, it almost automatically makes people improve it. Make people write stuff down. Make people measure. This is my favorite bug chart that is laboriously put together. So I'll give you a couple of examples. Anybody here write software? There we go. A couple. There are bugs. Software has bugs. All software has bugs. We classify them: blocker, critical, major, minor. enhancement. We also categorize them: new, resolved, closed, reopened. Anybody know what a reopened bug is? When you thought you fixed it but then just messed something else up. Exactly. Well, almost. That's a regression. So a reopened bug is a bug that I fixed and then I broke it later. Same bug. A regression is when I fix one bug and mess something else— Mess something else up. So we started tracking those. One of my managers had a high number of reopened bugs. We tracked them. All of a sudden, like magic, it started to go down. Now, you telegraph to people what you care about by telling them what to measure. So make certain you choose it correctly. At that time, we had a big reopened problem. I wanted it stopped. We measured it. Almost magically, it went away. Great tool. OK. Different type of tool. I don't know if anyone's heard of this before, failure modes and effects analysis. My God, what is that? This is the best way I've ever found to try and figure out what could possibly go wrong. And you can use this on anything. Typically, we use it with our hardware designs where the tools aren't quite so sophisticated as they are in software designs. But it basically, it's a fancy spreadsheet and you can get a copy of it off the web. But really what it does is it forces people who know something about the problem to sit together in a room and everybody has to brainstorm what could go wrong. How could it fail? It's the kind of stuff that NASA does almost endlessly. And then for each idea, you give it a rating. How probable is it? Can I tell if it happens? And how damaging is it if it does happen? If you think back to the Challenger disaster and O-rings, I know it was a long time ago, FMEA could have suggested, you know what, if the O-rings go, the whole rocket is going to blow apart and everything is going to— and it will be an enormous disaster. What's the probability of that happening and what might make it happen? Not to knock Morton Thiokol. They did their best. But this is a tool that is very, very useful to me and can be very, very useful to you. It's a good practice to get your people, your human network, to think about what can go wrong. Fishbones. OK, this is after it went wrong. Has anybody ever had to debug a complicated problem? Mm-hmm. A couple times? How do you think about that? Have you ever seen anybody get wrapped around the axle trying to solve a hard problem? They almost don't know where to start. It's failing. It fails very rarely. This happens to us all the time. And what I started to insist on is to use a fishbone. Now, I didn't invent this. I think the car industry did. But it's a way to actually logically think through what the root causes could be. You have to divide them into these categories. Is it people? Is it the product itself? Is it how it was used? Is it what's going in? Is it, are we just, is it actually working, we're just not measuring it correctly? Or it's the environment in which it operates. We have a— I have about 2.5 million devices deployed in the UK right now. in a smart metering world. A couple, 3 years ago, we had a huge performance problem. Our head-end system software would wheeze and die every night, and we had to figure out what it was. We actually had to go through exactly this fishbone analysis. There were bugs in the software. There were problems in the customer's environment. The database was really slow. There were a lot of things at play here, but we didn't find them until we actually went through That's sort of the discipline of doing this. And it doesn't just have to be technology. It can be sales, customer satisfaction. What might be the reasons why people are unhappy with us? So this discipline actually is helpful almost everywhere. It's a nice structured way to think about problems. So try it. Thank you.