 So I'm going to talk to you about our experience in putting lean process into the area of genetic labs. If lean and agile are not clones of each other, they're certainly brother and sister or brother and brother because they're the same thing. So the two points I will put across in this little talk is number one, if you're putting agile into your process, it would be worthwhile for you to put up all the work on the system. The Toyota production system has talked about almost everything you have in agile in different contexts, but they've talked about almost everything. And just like lean, people think lean only belongs in production. When I talk about putting lean into IT and putting lean into finance, they all ask me, and say, that's just production. It's like agile. Everybody thinks agile. Agile only belongs in IT. You guys only know IT stuff. How can agile be effective in any other part of my business? However, that's absolutely incorrect. They both belong in the whole organization. The second point I want to make sure that everybody gets is that if you're trying to put an agile or you're trying to put in lean, you need to change the culture. You need to get rid of the mentalities. You need to have all of the old stuff you have because they can't feel trust and make sure you're going forward and all have the same direction. You'll never be successful at implementing either process. And they have great value. So let me tell you a little bit about mirror genetics. I'm not sure how many geneticists do I have there. Anybody? Which are you mirroring before? OK, a few of you have. OK, so for those of you who have heard of mirror, you know, you don't have to stop me. In any case, here is the world's largest genetic testing diagnostic lab. We do about 10 million DNA bases a day. We run a six and a half day weak shop 24 hours a day. Our results have profound impacts on patients' lives. So when you send a test into mirror genetic labs, it's probably because someone in your family has had early onset breast or ovarian cancer or colorectal cancer. And you're worried that there's a mutation in your genome that can be passed on to your children. Or you need to make a decision because you're the brother or sister of somebody or the daughter of somebody who has a mutation. So our results have to be perfect for a medical diagnostic company. So everybody knows who doesn't know anything about genes. Genes are a DNA sequence. DNA sequence codes for everything that is you. It's not binary, but it's the four-bit language of all life, right? So when there is a mistake in the DNA, it causes proteins that don't work, which causes you to have problems in health, such as, in the case of BRC1 and 2, it leads to early onset or breast or ovarian cancer. So what we look for every day is we read about 10 million bases of DNA. And we're looking for a one-letter change, a one-small change that holds 10 million bases every day. Frankly, we see about 20 or 30 changes every day. But it's like editing a dictionary every day and finding every typo in there. And for those of you who write code, I imagine you spend a lot of time looking for the little typos and things that happen in your stuff. Well, we can't make any mistakes on that. So our results have to be perfect. We're also informatics junkies in my group. We don't get enough automation. We can't have enough automation. We can't have enough computer programs to help us in our process. So we use a lot of informatics. And we use informatics to track our whole process. This is the laboratory process I run. It's actually pretty straightforward. It's 25 steps to get everything done. And each of those more than boxes represents a different team member who has to give results to the next person. In the end, we get samples come in the door from FedEx and they go out the door in shipping. So our dilemma. When I came to my area back in 2006, they already had world-class service. World-class service in DNA sequencing was about a month turnaround time. If you lived in the UK, and you put a sample in, and maybe six months later, you got your result back. So those of you who have ever had any medical tests done, I imagine you love waiting day after day after day for results to come back. Especially when it's an enforced result for you. For me, yeah, I go to get my yearly physical. And I'm waiting three days after for my blood results saying, if I don't get them, I'm dying, oh my God. The doctor goes, I want to tell me something. Well, most of these patients have that feeling, so we did not. We weren't satisfied with 28 day turnaround time, even though it was world-class. I guess that's one of the things I've got to ask this morning, but well, how did you get people to change culture? One thing to get culture to change is to create a sense of dissatisfaction with what's going on. If everything's working fine and you're satisfied with everything, why would you change? So the first cultural thing is to create dissatisfactions. So we knew we had dissatisfaction. Pretty easy to tell people, you know, we got an appropriate result, but we want to have results going out in time for people to make surgical decisions. And for the case of BRAD analysis, if somebody has a mutation in BRAD, it's simply inverse for a lump-ad to me and then being told you have a BRAD mutation, now you need to go back in and have a bilateral mastectomy. Oh, and by the way, then you have reconstruction. Here's three surgeries. It's much better for the patient if they find out before the surgery. You've got a mutation. The quality of care suggests that you have a bilateral mastectomy. With reconstruction at the same time, everything's done. It's much less psychological problem for the person. Similarly, if you're going in and you have colorectal cancer, going in for one surgery, doing the right surgery is better than going in twice. Okay, so of course, you know, we talk about quality cost and delivery, but cost is keeping marks is going in the right direction. Of course, I want quality and turn on time being important, but my CFO and my CEO both require that I don't spend more money. And we really haven't looked at cost in our process, but it's come along that way. So I'm going to give you the bottom line for what we did in three years. Okay, and these are all based on lean process approach, which is the same as agile. And I will tell you, you can do the same thing. Reduced our turn on time. We went from 28 days. Yesterday, our average turn on time for BRAC analysis samples was four days. Oh, this is over a 75% reduction in turn on time. We reduced our cost by 63%. Our business has been growing at about a 50% rate every year, which is a phenomenal rate of growth, which we're lucky to have. But making changes, we kind of like it to change the tire on your car while you're still driving it. So we're making all these changes at the same time that we're still accelerating down the highway. Reducing cost by 63%. Reducing rework by 67%. So about 20% of our samples when they came through, we'd have to rerun them to the whole process. We satisfied with the quality of the results. We're now down at this, yesterday we were at 7%. And I can tell you a daily result because we measure on a daily basis. So this is the bottom line of what we've got. Lean transformation, what is it? Okay, we focus on lean time reduction through elimination of waste. Everybody goes, well, what is waste? Well, waste is waiting, first off, what is lead time? Lead time is from when you start to when you deliver something out the door, right? It's something the customer wants. Well, most of the time in lead time is things waiting in a pile for somebody to do it, waiting on a decision, as Alster would say this morning, we're waiting on a pile of decisions here. It's at the top of the stack, or it's at the bottom of the stack until it gets to the bottom of the stack. You're waiting for a decision. Well, customers are unwilling to pay for you to wait for that time. They only want to pay for things that add value to them. So that's a waste of time. So we don't want that sort of waste. We also look at things what they're not gonna pay you to walk around or to get on the telephone to call somebody else. They're not gonna pay for you to have time to go and install the latest software in case you need to do your work. They want to pay for you actually programming and doing stuff. Same thing for us. No one pays us to sit and wait on time for samples to go from step A to step B. And we have 20 steps in the process. So we focused on getting rid of the waste of handing off from process to process. As I showed you on the slide, we did achieve simultaneously improvements in quality cost and delivery. And the big thing we did was we started employing Kaiser and Breakthrough Methodology. Kaiser and Breakthrough Methodology is a lot like this from Kaiser and Events, or actually they're not a, they're like a cycle that you do, a single cycle that you do. Kaiser and Events are typically one week long events. They're very high energy, very intense events. And actually some people don't like Wellington because it means you start at like seven in the morning and you should get done at about seven o'clock at night. And we typically run them for four and a half days. K was involved in a half day one only. And those are a little bit easier, but these events are very focused on getting something done at the end of the event. You need to implement something at the end of the event and then you have a 30 day homework list. Anything past 30 days, nobody cares about it because it's an idea. And what happens is after 30 days the whole world changes anyway. So anything you thought of at the beginning of the week is no longer valid at the end of a month and a half. So that's all we give them for Kaiser and Events. The other part for us was building a good culture to continue some improvement. When I say continue some improvement, this is dissatisfaction again. When people say, okay, we're doing just fine, they don't change. In this case, we tell people that no matter how good we are, we still have to get better or someone is going to take our lunch money away from us. And we want to keep our lunch money, we like to. And so given that we have people who have changed themselves to understand that we're not as good as we should be, we can always get better. And the other part that we have is sustaining improvements after we've implemented it. A lot of people when they change something, they tend to go back to their old habits. Very easy to go back to your old habits. And so if you don't start to focus on that and say, okay, let's keep driving and we change what we've made, they'll never change and never implement that change. So as you start to go forward in agile systems, you'll have to keep reminding people this is what agile really means and this is what you should be doing. They will try to go back to what they've done before because after all, that was successful for them, at least they thought it was successful. And so it's easier to go back to that comfort zone. So this is how we went through it. So securing executive support. Well, securing executive support was hiring me, the President of the United States, so the headhunter out looking for a new person in operations, the economy working for a company about time medical systems and Tucson. I was not a lean advocate before I had gone to Ventana Medical Systems, but Ventana was a very strong lean company. And I saw all the benefits of it. So for me, my culture was changed by being driven into it by a company that had shown a lot of success on it. So when they brought me in, my job was to bring me into the operations and how to do that. Well, people don't change instantly. So the first thing we started with was book clubs. Like most companies are, a company travels on its stomach. It was really cheap for me to buy lunch. I would get people to read a book, actually think about the process. I bought them lunch. They worked an extra hour each day, more than paid for itself. It was really kind of nefarious in a way that you know, guided people to doing something on their own time that you wanted them to do. So food was the way to it. It works pretty well. I would always suggest to it. Three books that we worked on, one was called The Goal. The goal is actually the classic book on the immune systems. It's a very easy read. If you ever get a chance to read it, it's actually kind of a fun book to read. The Journey to the Emerald City used to be called The Aus Principle. This is a book on culture change. And this is what I got my staff to look at. And I actually think they believe it now, is that people's actions are based upon their culture. Their culture is based upon their beliefs. And their beliefs are based upon their experiences. So our job as managers was to create experiences that told them they should have a culture of lean or agile. And that's my job as a manager, is to make sure they have those experiences. Experiences come in all sorts of different flavors. Some have to be explained. Some are self-evident. If I give you a check for $1,000, it's pretty self-evident. I'm happy with what you've done. If I give you more work after you've done a great job, I might need to explain that a little bit to say that this really is a reward. It's not a punishment for doing a good job. So experiences have to be interpreted for people. The Journey to the Emerald City is a great book to read with us. The last one is a book called The Goal Mind. The Goal Mind is another talk about lean systems. And it actually may have more things towards agile, I think, that's probably a little bit closer to that, but it's another good book. But book clubs are a great thing. The next thing we did was implement a measuring process to internal customers, okay? Measuring people, if you look at this thing, we have about 20 different groups all interacting with each other. And this is what looks like this room. I had a lot of an ashen of tea when I told people that you now have to write it every day. You have to give me a graph that shows me your production, how your production matches the next person's production and process, and how you think you're doing any problems that you have. Most of the people said, oh, well, we can get IT to program these graphs for us into these graphs for us every day. You don't have to do anything. You just put them up. I said, no, no, no. IT is not going to do these graphs. You're actually going to go through the pane and gathering the data and putting the graph together. The premise of that was that if it's not worth getting the data for the graph and putting it together and spending five minutes in your graph, the graph is worthless while you do it. And the idea was to provide people to the figure out graphs that were worthwhile to put it together themselves. Once we implemented this war room, which you call the war room, which you might call a scrum, I guess, we actually identified more areas of dissatisfaction, which primed the culture for people to change to implement these systems. The premise is that you can't measure, you can't control it. If you can't control it, you can't improve it. It's very hard to argue with that logic. And so once I told my staff that they're like, oh yeah, that makes sense. Okay, so we have to measure things. And then we came to that if you can't meet daily needs, you can't meet weekly or monthly goals or any goals. And so the idea is you need to measure every day what's going on. If you don't measure what's going on every day, people fall into traps where they get way behind. We're all procrastinators by heart. We all have other stuff to do. And so if you don't measure every day, people don't keep up on it every day. So our daily measurements based upon supply to internal customers. We started focusing on internal customers. And the reason we focused on internal customers is they were the ones that were gonna be the first to act upon pain. If I go in and I say, you guys aren't developing anything for the external customers, it's kind of an insult. Everybody believes that they are supporting the external customer. In essence, you are trying to support the external customer. Maybe you need to change your focus later on. But for me to start off a cultural change by telling you you're a bunch of idiots, you're not looking at the customer, that doesn't help very much. What it does help is you say, well, let's start looking at what caused the pain internally. People get the what's in it for me. And that's the first part of getting an experience that this works for them. So we focused on internal customers. Every day for 15 minutes, we look at what's been done, what's the goal, any issues that need to be resolved. We don't resolve them there, but we set up a couple of people or three people to resolve that issue that day. Nobody wants to remain with the issue. So they're very happy to get the help of two or three other people to help them solve their problem for that day quickly. And that's how we address the problem pretty quickly. So the next step after we got this board in place was to choose our first hyzen event. Like I said, hyzen events are kind of painful. And so this was actually a litmus test for us to see if we could get people to change their minds and actually do these hard work events. I think this morning when you were listening, but the IBM transition, the part about making it a safety net that you want to make sure that you don't do something that's a real problem. Well, that's really good advice. Your first event needs to be something that has high visibility, has a high level of pain, and a really good chance to be successful. Unless your goal is to torpedo agile and never have to see it again, you should be choosing an event carefully and making sure it can be successful in a high area of pain. The process we chose was in our clean lab, which probably means nothing to you in our clean lab, but I can tell you our clean lab was having a lot of pain. They were working really hard. They were coming in the morning, working like a man. I think it's something done then where they'd sit around and wait for the next thing to be released. Our first event actually just worked on casing to get them to work in their process on an even pace. They suddenly found they were doing more work with a lot less effort. And these people were very resistant. When we talked about casing events, they were like, ah, you know, that's a bunch of quality goods, it's a bunch of, yeah, why don't we go to TQM, how about Six Sigma, how about all these other buzzwords, how about Angel? We could say all those things and they were very, not very supportive of any of these things. Once they got down to their first casing event, they were very supportive. The next thing I found was them running their own casing event and doing compound systems on how to get cards for their process on board. So they took, after they had one event, they took the lead, and then it became, then they started publishing their results to other people. When they talked to other groups, other groups started picking up saying, well, how can I make myself work less and get more done and make me Jeff happier? Well, they all did a very good job of it. Took us two years, but in our annual report, they acknowledged that lead systems was a key to process, to keep process maintain, our value of proposition for our customers. In other words, they're saying we save a lot of money by running through the lead. We're able to do better value for our patients. We made our patients happier, we made our internal customers happier, we made our shareholder happier. If you had bought the stock and married three and a half years ago, you would have bought it at less than $10 a share. Today, it's somewhere around $38 a share. So it would have been a good investment. I still think it's a good investment, but remember forward-looking things for me do not mean anything. The stock statement is that I think it'll be worth more value, but I can't tell you for sure. The other part is we kept our focus to continue to improve. We've done 26 full ties in events right now. We've also done numerous small events. The event that Kay was on was a small event. It was a half a day every day for the week. We've done 26 full events. I can't tell you that they were all successful. There were some that were filled miserably. And the ones that filled miserably were mostly where we did implement something at the end and didn't have a thought of action at the very end where we just discussed things in culture. And I won't just do that on the talk this morning, but I looked at where I got value out of our discussion about culture and trusted things. Usually when we look for getting value, you gotta get something out of it. Something that's concrete to say what the value is. I think the value I got out of this morning's discussion was that it's managed this job to create an environment where you can improve and where you can take risks. And that's the bottom line, but that's what we've been trying to do. And we keep our focus on ties in events. Of course, having great process improvement. Now our CEO is very happy with us. And he gives us stuff that he doesn't give other people. I've never been refused anything that I've asked for from the CEO when I've given him reasons and when I talk about our approach using these systems. So to emphasize again, the first customer focus on, focus internally, if you wanna make this transition, if you focus externally, people will be insulting and they don't know what it's in for them. You can tell them I'll give you the next paycheck, but that's kind of hard to translate to people to themselves. It's better to focus on the internal customer and say here's how I'm gonna make you more successful. You can get a bigger raise. You can work less hard. You don't have to work weekends and evenings. But I can't promise that, but that's the idea where you get towards it. The idea of measurement, the problem with measurement is you get exactly what you measure. So when you put metrics in place, like the guidance is to put a metric in for productivity, but you need to match it with a metric for quality. If you just do productivity, that's what you'll get and quality will go down. You need to put a metrics that are balanced against each other. I would say that Katie's event that she was in, I had put a target in there of reducing the cycle time for a new programmer party to put in. We're on a cut testing time in half. I said, cut testing time in half. I made a mistake in making that metric, but I really meant it as I meant I wanted to implement it in half the time. I didn't want to implement it in August. I wanted to implement it in April. The team, I know they were joking at it, but I came back to my first debrief to tell me what was going on. I said, good news, we cut the testing time in half. I said, so what are we delivering? August, I said, you cut the time in half. How can it be August? Shouldn't it be April? I said, no, you just told us to cut the time in half. You didn't tell us when you wanted it. So I made a mistake of getting an metric that was not precise enough. In the end, they were pulling my leg because they knew it would raise my blood pressure and get me hopping around a little bit. But right now, that team's actually working extremely well on getting our processor, and they've done a great job. And one thing which is balancing and pacing between our developers and our testers, which we weren't balanced in before, and that's the idea of pacing. When I look at my process, sorry if I get up here, when I look at the process in my laboratory, there does be no good to run the data review at the bottom box, any faster than run the middle box or any faster than run the top box. If I run them at different paces, all I do is I build up work in front of one step or another. The problem with building work in front of one step or another is that if there's an error in that work, now I've got a pile of errors rather than a few small pieces of error. So the idea is, and this is what Alastor was talking about, the idea of compounds is making sure that you have small piles in front of each one. That way when you find an issue with something in the pile, you have been built up a bunch of stuff based upon that issue. So you'll always want to keep your work in progress low. You'll always want to keep, a combine is basically a paper card and you decide how many you can have in front of a process. When you're processed, when you've filled up both the combine card and you tell the process upstream to stop, it doesn't do any good. So this could be, if your tester are full, you don't need to do any development work because if you're writing programs where your testers can't handle it anyway, so you're just wasting your time. So that's what combine card. So I would argue that you do need to get that with low as well. Okay, so my take on the success at myriad and I'm pretty happy with it, is we've managed our culture. The animal city will say you can either manage your culture or it can manage you. And in my experience, that's absolutely correct. I was in an organization for the culture. I was in an organization which is now in GE Healthcare, but before that was Pharmacy of Biophagic and Pharmacy of Biosciences and Amersham Biosciences. Then it changed names every two years and the culture there, we were working with a group of people in Sweden as well. And if you didn't understand Swedish people, they're much more like the Japanese and they are like Americans. They all sound like they're Americans, but they're much more like the Japanese. And we failed to manage culture, so we had a lot of conflict divide between the two different groups. At myriad, when I came there, there was a lot of, I should say, infighting. And this is the part I put in my slides, since my CEO looked at this and said, yeah, but there's nobody from myriad here, right? So there was a lot of infighting. People were set up purposefully in conflict with each other, teams competing against each other, and then people would throw things over the wall. So I had a huge group of people who had a victim mentality. They thought, oh, they're doing this to me. When I came in, we said that you or your successor will not have a victim mentality. And I was, a few times, I mean, you or your successor will not have a victim mentality. In seriousness, we talk about people saying, you need to give up your baggage, you need to give up more, because what we've done in the past is not what we're going to do going forward. And that was my job as the manager to come in there and change that culture. We've gone there pretty well right now. There's still some, we still have some victims' times, and there's sometimes what we call going below the line, which is where we talk about things that don't add value and don't make the culture better. And it's okay to go below the line and complain about things as human nature, but you just have to remember, when you're below the line, you're getting nothing done. You need to get above the line to get things done. So, okay. Yeah, five minutes. Okay, so great trust. This is something that I talked about this morning and when I was at GE Health here, one of the best trainings which I had was somebody Dan and Larry from Performance Dynamics, and they drilled into my head that there are very few sociopaths in the world. None of them work for me. So when somebody hurts you, it's not because they're trying to hurt you, it's because they're trying to get something done that they're rewarded for. Now, take a deep breath. Grass is green, sky is almost blue, but take a deep breath and go, okay. They're not trying to screw me over. They're actually trying to get something done and somebody else is rewarding them for it. I can understand that, that I can get them to work on my side to get things done. And even if it's not true, if sociopaths work for you, they're usually easy to recognize and you'll have a better outlook on life, it'll be happy radio. Even if it's a lie to you. But I guarantee it, sociopaths are easy to see. Similar to when you blame a person for a process failure, it's never the first, it's always the process. When a person is the problem, you will always see it every time. I will contend that that person will make more, not just one error, but lots of errors. You just have to watch out. If that person's the only one who does the process, that person will always be the one that makes the error, so don't confound it to the guy. So, if people are trying to do a good job, I think as I said this morning, nobody came in to say, I think I'll do a poor job today with poor quality programming and it makes somebody else work harder. That's not what they come in to do. And then to learn from failures. One of the failures that we had when we started implementing lean systems was everybody had a lot of really great ideas. A lot of things to do. The first year we did about a dozen Kaizen events. Of those dozen Kaizen events, maybe a half a dozen were successful. And the reason being is that we came up with too many ideas for us to be able to implement all at once. So you have to take and see how much capacity you have to make changes. Right. So the issue is to match your capacity to what you get out of these events. And we look at agile events, I'm sure it'll come up with all sorts of ideas. And maybe some of them you have time to implement. But the part that you have to be used would be totally transparent. We tell people, great idea, but we can't implement it. We don't have time. And they say by, ah, we are very transparent. Well, here's the whole list of everything else you want to do. Where would you put it on the list? And most people see that pretty well. So there's something to call for open kimono in these systems. It's not a very pretty picture. And I think it's me, but for most people, the open kimono is the best way to do it. So as a manager, you should be completely transparent. You need to support your group in making cultural change. Don't punish them for failure, remember the process. And it's probably your fault that they didn't make a failure. So that's our lessons to our managers. So as I said, we had a huge process improvement. We had to cut our costs by more than half. Cutting our turn on time basically from 20 to 24 days. Like I said, when you have results like that, that's the experience that creates the culture that people want to be part of. And so I would say, myriad is a long ways along the cultural transition path. And we're still going to get better. My hope is to control my CEO's expectations that I'm not going to cut costs another 75% to turn on my time to zero. The test will never be free and done instantly. So with that, I guess we've got about four minutes now. Oh, you get, yeah. Four? Is that a question for people? Yeah, I was wondering if you could just tell me a little bit more about that Kaizen's event that you did. How did you get people to show up to that thing? Did you make it mandatory? How did you pitch it so that everybody, and then what was the process like? It was a new system. The first thing that was a new system, mandatory, and actually people volunteer. We have some people who understand me and then they take on faith. You don't have to get some faith because they have to have it being worse. And then I met a few people who said, well, you're the owner of the area, it's your area. We do want to be there when they change the process, don't you? So most people, whether they were really volunteer or armed to it a little bit, they showed up that. The process itself starts off, first day is supposed to be a day of training. It's been a half a day with intense training, saying here's where the lean tools are. It's the same thing with agile. Agile really is set of tools that we use. So each time you start an event, you start with a half a day of training just to remind people what the tools are. People need to be trained often on the same stage because sometimes they forget they pick up one or two points of the training. You train them on the same thing again, they pick up two other points. So half a day of training, then you have a day of discovery. The day of discovery is actually where the team maps out what they think the process is. And then they actually go out and observe it. They actually go out there and stop, watch it and take time to watch people doing the process. They get real data, not just, oh, I think I know how the person does it. They actually go out and look at it. Then you have a day of redesign where you redesign to what you want from the last day if you implement it. And then you take a half a day off to celebrate your success. All right, we buy lunch for them. We get these crystal cubes. You can try to make these periods. Like you work really hard. Thank you very much. And they help work very hard. But the real benefit ends up being for that in the end. So in the end, we will go to a similar concept where the red perspective, and I think the goal is very similar, which is continuous improvement. The key there is to encourage some experimentation and kind of save essentially for the experimentation to sometimes fail. Can you share experiences where they came out of those events and they didn't work out? Most of it's when they haven't implemented anything at the end. They lose it, they don't, they pay attention. So we typically recycle those inside. Here's all the good stuff you've done. Let's look at it. But the whole mean approach is you never build your first prototype on a stainless steel. You always build on a styrofoam. So in an operation where it's a lot easier translation, we build things on a styrofoam. We try and then we find out there's a problem but then we make another iteration of it. It's similar to what they had to work with us. You build on something cheap. So you don't build all your features in to start off with, I would say. You build on the core things that have to work and you play with those a little bit. They're on a styrofoam. Then eventually you get a point where you're confident enough to make out a wood and then eventually you make out a stainless steel. A lot of stuff never ends with a stainless steel because you find out that the world has changed and you want to change your process and play it down. But the whole mean system approach is actually just like agile, small, incremental improvements. You can't make huge improvements in a week. You can have a big strategic vision in fact you have to have a vision. I think when Alistair talked this morning about it doesn't have any strategic vision. Lean systems has very strong strategic vision. The whole idea of the Toyota Corruption System, they say plans are worthless. Planning is invaluable. So the process of planning is important but your plan, remember, once you write it down, it's worthless. But you must have strategic vision. You have something called policy deployment. You set a strategy up front and policy deployment is how you interpret your company strategy down to the different groups. At some point you lose a point where you make hard direction is basically saying, I know my goal from the area is to change my turnaround time from 28 days down to three days. Whatever I do for it's changing that. That's the right direction. And that's about as much direction as I do. Was that the goal that you set out with? When you started a 28 day turnaround and you ended it at four, did you set out with that goal or did you reach that organically through these kind of events? Well our goal is to set a 14 day turnaround time for customers period based upon the amount of time that somebody would respond with breast cancer to when they had surgery or how long they'd wait for it. So in the process I talk like production side of it but there's another side of it which is the customer services on side getting, insurance to release the test and all that sort of stuff. Our test is a $3,000 test. We try not to make the customer have to pay any of it. In fact right now we have like 95% of our customers have 95% insurance covered so most customers paid nothing for it. On the average it's I think about $50 for $3,000. But the first step we've had another set of serious events and this is for customer service. They said oh, we need that production. Well we've applied for these principles for our customer service and we now have a group of tests that 95% are released in two days or less. So our whole goal is to get these tests done in 14 days based upon what the customer was or our perception of customer data. It's funny the customer service some sort of just care less but we found the ones that do care with the cost we do the most tests in. Is everybody still awake? Okay, I think any other questions? So is this developed in Japan or do they just like the Japanese names? I don't know. We like that, we like Buda and Kaisen but actually this is more this is more this is Toyota production system it is Toyota they started making new weaving things on looms and that's when they started with the process and then it became the car company. But they're just using extrapolation everything from Den and from here everyone to Japan afterwards. So I have a hard time in it as well when people say agile or mean or six sigma or something like that. I look at those as a series of tools you're pretty together to get to the role. I can care less what you call it. I just have to say what are the goals and how I measure what I need to get to them. It's easier to explain how to manage them when you say we're following the systems approach because then they can look at the group of tools you're using. Right now I'm there just working at six sigma so the next thing is one six sigma so we're doing that six sigma stuff. Six sigma touches on the value of the card and stuff such as how we do the testing and chemistry on the laboratory. But that's the natural transformation is to start with lean and go on to six sigma. Can you be surprised how much waves there is? Do you think you're perfect? Do you think you're perfect? But there's a lot of waves in every process. Any more? Thanks for your attention. Thank you.