Host Intro (Gene Kim)

I am so pleased to introduce the next speaker, who has been a mentor of mine. He is Dr. Steven Spear, senior lecturer at the MIT Sloan School of Management and senior fellow at the Institute of Healthcare Improvement. He's probably most famous for writing the most widely downloaded Harvard Business Review article, "Decoding the DNA of the Toyota Production System," which was actually based on his PhD dissertation, where in support of that, he spent six months working on the plant floor of a tier one Toyota supplier. Since then, he's expanded his work beyond just the repetition work of manufacturing to engine design, workplace safety, healthcare, and so forth.

I got to meet him when I took a continuing education course at MIT in 2013 and was blown away by how widely his ideas are being applied by large organizations, which is where he is spending most of his time these days. He's helped pharmaceutical companies dramatically compress drug development times, hospital systems to improve quality of care delivered, and even the senior leadership of the US Navy has made high-velocity learning an essential element of their strategy of maintaining maritime superiority.

So please welcome Dr. Steven Spear.

Dr. Steve Spear

All right. Good afternoon, everybody. Bad news as a speaker, I'm what stands between you and snacks. The good news is you don't get snacks if you don't listen. So, anyway, I just want to really cut to the punchline. I'm going to make a very strong case as individuals and as people responsible for managing other people, our daily objective function should be learning. And the more we learn, the better, the faster, that's great. And I'll just build up that storyline. But that's the key point.

So I often start when I'm working with some of the clients Gene mentioned, with a question about when they get to work or when they go home from work. What's that? Oh, IT audience. Let me rephrase this slightly. When you log on at the start of the day, or when you join your virtual community at the end of the day.

Just kidding. Thank you. But the question at the start of the day is, why am I here today? And the question at the end of the day, what did I accomplish? Now think about that. How do most of you answer that? What am I hoping to accomplish today?

Call it out. Learn more. Learn. Oh, yeah. All right. That's the punchline. How do you normally phrase it, though, right? Because most of us phrase it in some form of, what am I going to make and what am I going to deliver?

So in a pharmaceutical company, it might be, how many molecules do I synthesize today? How many tests do I run today? How much data do I process today? So whether it's physical, literally physical, or metaphorically, figuratively physical, we tend to think about the physicality of our daily activities. What did I make?

What did I deliver? Well, let me make the case that we really should think about, what did I discover today? What did I discover today? And try this when you get back to work, whether people are logging in, badging in, punching in, however you indicate your presence on the job, ask your colleagues, "What do you hope to accomplish today?" My bet is most people will give your equivalent of make and deliver, and almost nobody will give your equivalent of discover, and the same thing on the way out. Now, let me explain why what will I discover today is such an important question and an important objective. So we tend to think about our work having a value stream, and a value stream progressing through time, from way early conceptual to actual construction, development, delivery, and operations.

But let me suggest we're missing a critical dimension here, because our work doesn't progress just our work through time. Our work progresses through understanding. The reason we take on projects, programs, work streams, competency development, whatever else it happens to be, is because there is a need for which there's no solution.

And part of the reason there's a need for which there's no solution is because we may not even know what the need is, and we certainly don't know what the solution is. So our start point is that we're ignorant. And now, where's our endpoint then need to be?

If we're starting off ignorant in terms of needs to be satisfied and the nature of the solutions for those, what we want to do is progress and progress quickly from a point of ignorance to a point of a high degree of knowledge, right?

Because anywhere along this value stream, we're plagued by what we don't know. And just looking at the very end of the value stream where something is even operating, so there's a lot of reference to Lean and Toyota throughout the day. The reason Toyota developed these tools of poka yoke, go/no-go gauges, jidoka, andon, et cetera, is they recognized even after all the effort of designing operating systems and building operating systems and implementing operating systems and actually operating operating systems, there were still things that were going to go wrong because of what was poorly understood. So they wanted quick feedback on that.

Well, if that's true in the operating system, all the more so we want to know what's wrong early on. So long and short, we want to progress very quickly, very aggressively to where we don't know to where we do know. Now, let me just make an aside on why speed matters.

It's not just direction, but why speed matters, hence high-velocity learning rather than just learning, is that getting to the right answer better, faster, matters a lot. So as Gene mentioned in the introduction, I've been spending time with pharmaceutical companies the last several years trying to compress the time it takes to go from one end of the value stream, where we really don't know, to the other end of the value stream, where we know a lot. It turns out in their industry that the rewards for being first with a therapeutic into the marketplace is that you enjoy something like 50% of the revenue on that therapeutic.

If you show up second, you get something like 30%, 30 maybe there's 15, 20%. And if you're fourth, fifth, or sixth, you've waited a huge chunk of money and about a decade. So that relative speed matters a lot. Now we did another calculation at one point to figure out what's a day worth, and turns out the way their patent system works is that when you have an idea, you patent it, and you don't start collecting revenue until you have product in the marketplace, and then your revenue basically goes to zero when your patent wears out. And we started calculating what's the value of an extra day in the market.

It turned out it was like $3 million per day to show up earlier than later. So in terms of the start, you're starting ignorant. Where you need to get is where you have sufficient understanding of what to do and how to do it, and speed matters a lot.

Now let me give a couple of examples of where this issue of getting from we don't understand, we don't have a solution, we don't understand the problem, to where we have one matters a lot. So it turns out June, July are a period of great anniversary recognition. So this month we mark the 75th anniversary of the landing at Normandy, D-Day. Now, it's funny.

It's almost four years to the day from the evacuation of Dunkirk until the return of the Allies on the beaches of France. So four years. Now, here's another anniversary. So next month we're going to mark the first landing of human beings on the Moon.

Now, that was seven years after President Kennedy offered the challenge of, or the declaration, we're going to send a man to the moon by the end of the decade and return him safely to Earth. Seven years. So here's a question.

What took so long? It's not like when the British and their allies left France in 1940, they sat around and said, "Well, we're really in no rush to go back." And the French weren't sitting around saying, "Well, you know, London's kind of nice. We really like the bland food and warm beer."

It didn't take four years to realize, wow, this is really drab f-- just to make the point here. I'm not meaning to insult an entire cuisine and a whole people, right? For an American to insult foreigners, I'll leave that to my president, right?

He's got that niche, let him have it. Anyway, just for sake of example, right? And certainly, you think about presidents, right? So presidents like to take credit for things that happened on their watch, whether or not they're responsible. Probably true for prime ministers also, right?

So ideally, when President Kennedy made the challenge in 1962, he would've said we're going to send a man to the moon and return him safely to Earth by next year. He didn't know about Dallas, I guess, right? But by next year. So why did he say the end of the decade? What took so long?

Why'd it take so long? Four years to come back to France or go back to France, and seven years to get to the moon and come back. Why so long? No one knew how to get there. Right? In 1940 as the British and their allies are leaving Dunkirk, right?

It's not like they're saying, "Well, we're going to wait four years to go back. We know how to go back now. We'll wait four years." The reality is no one knew how to go back, and there's some fascinating military history on this. There was a decision.

Once the US got into the war, do we go back to France in 1942? And as you know, what happened is that the Allies first went across North Africa up through Italy before launching D-Day. And the history's fascinating is that when the US and its allies landed in North Africa, they were horrible.

They had no idea how to fight a war. It was antiquated, it was backwards, it was disastrous. It was disastrous at one-one-thousandth the scale of Normandy. And historians have said had the US and its allies not gone to North Africa first and learned how to actually fight, they would've gotten decimated had they gone to France first. And the same thing can make the argument trying to go to the moon in 1961 or 1962 versus 1969. What took so long? What took so long is that the president and the prime minister didn't have an answer to the question, how do we get where we need to go?

And why didn't they have an answer? Because they were ignorant. It's the mother of all problems. Now let me just pitch this because the reference to Lean and Toyota. Let me offer that Toyota is an organization which has defined its operating system as the relentless pursuit of ignorance to beat it with a club and convert it into useful knowledge. Now with Lexus, they call it the relentless pursuit of perfection, but what they really mean is the relentless pursuit of perfection so it can drub it to death. Now, here's an example.

The picture on the screen is the first product Toyota brought to the US market in the late 1950s. It's called the Toyopet. Anyone ever seen or heard of a Toyopet? Yeah, one. All right. How do you know about a Toyopet? We'll explore the unusual... All right.

But most of you haven't. What does that suggest about the characteristic of a Toyopet if no one in the room, other than this person over here, no one in the room has ever heard of a Toyopet? It was a crappy car. Yeah, it was a lousy car. It was a terrible car.

It was an awful car. And just to sort of quantify, qualify awful, that the Toyopet to go uphill in a Toyopet, the odds, no guarantee on this, but the odds were better if you put the car in reverse. And it was more likely than not on the way up the hill, it fell apart.

And not only was Toyota making a horrible car, but it turns out they were horrible at making a horrible car, which I guess is good. It means there weren't that many horrible cars left around. If they were good at making a horrible car, we'd have a lot of them.

And just in terms of horrible at making horrible cars, Toyota's productivity in the late 1950s was about one-eighth the world standard. Now, at that point, Toyota management had a decision to make, a choice. And the choice would be amongst alternatives as to why they were lousy at making lousy cars.

So they could say, well, it's something unfair about the economy, or unfair about trade relations, or unfair about employees, all sorts of blame things outside our control. But within Toyota, they made a different choice amongst their alternatives.

They said the problem is we just don't know any better. If we knew better about how to design a car, we wouldn't have designed a Toyopet. Why would you do that? It's like you invite guests over and serve the meal that you don't know how to make rather than your specialty.

And they said if we knew actually how to be more productive, we would be. We wouldn't spend eight hours doing what the guys at Ford and elsewhere are spending one hour doing. So with the admittance, recognition, identification of ignorance as the mother of all their trouble, the folks at Toyota said that, well, if ignorance is the problem, not cars, not markets, not GM, not Ford, but ignorance, we have to manage in such a way to get rid of ignorance.

And they came up with this sort of mantra that everything you do, you're ignorant about in some fashion. And if you're ignorant about it, you have to see your ignorance quickly. You have to see your problems. And once you see a problem, you have to swarm on that problem to understand and characterize it so you can solve it. And when you've come up with a discovery, part of your discovery might be the problem because we might not have known about the problem. But if you say, "Hey, wait, there's a problem over here," good to know. If you swarmed it and characterized the problem, may not have solved it yet, still good to know. If you come up with a solution, fantastic to know, so let's spread it around and share it and get that multiplier.

And so within Toyota, a decision was made amongst all the alternatives as to why they were lousy at making lousy cars. They decided the problem was ignorance, and the solution to ignorance was learning. Now, the consequence of that was by in '62, Toyota's productivity was equal to world standard.

By the late '60s, it was double the world standard. So when Toyota comes back to the US market in the 1970s, they're selling cars way more affordable because they double the productivity. And cars, which are now, again, back to this terrible cars, terrible productivity, because they've been learning, the cars now are much more reliable by a factor of 100 or a thousandfold more reliable than what's on the market.

Now, that creates this opportunity to not only sell subcompact fuel-efficient cars but to sell mid-size cars. Now, Toyota in that asking the question, what explains our underperformance? So quality, productivity, and then time to market.

So by the time the mid-'80s come around, Toyota's introducing new models on a two-year clip versus four years at Ford. Now, think about this. You walk into a dealership, and you look at a Ford, and an average age is two years on the technology, the styling, design, et cetera, compared to a Toyota, which is looking fresh.

Why would you buy an old, outdated car when you have the choice between the Ford Taurus and the Toyota Camry? And Toyota continues this cycle of demonstrating their ability to learn their way to greatness around quality, around productivity, time to market with new models, standing up new production facilities. Now, remember, the starting point for Toyota, late 1950s, is the Toyopet. By the 1990s, Toyota has a product in nearly every segment.

In the 2000s, a product in nearly every segment in the US market, and it's first or second in each of those segments. Now, just another quick example, moving further upstream to developing new technology. Car drivers, the auto market, sent a signal to automakers that they wanted a doubling of fuel efficiency, be it the cost of gasoline, smog, and emissions in Tokyo, Los Angeles, wherever else.

And after a bunch of getting the answer wrong, General Motors and Ford both came up with the same answer of hybridization. And this is an offline conversation which is better, hybrid, et cetera. But General Motors came out with the Chevy Volt.

Toyota came out with the Toyota Prius. Now, what happened after that? General Motors ended up selling about 160,000 Chevy Volts before ending the model, shutting down the factory, and laying off the workforce. Toyota took its hybrid system from the Prius onto the Camry, tuned it differently so it was really attractive onto taxi fleets, retuned it again onto bigger product like the Highlander, retuned it again onto the Lexus as a performance package.

Now, having taken their product through six, seven cycles of retuning and putting it on 24 different platforms, Toyota to date has sold, again, 160,000 Chevy Volts to 16 million of its hybrid. Again, same problem, but Toyota managed in such a way to get to more and better answers faster, so a difference in outcome of 100 to one.

That's better than the drug industry in terms of distribution of profits. So anyway, where does that leave us? It's if ignorance is the mother of all our problems, then learning and high-velocity learning has to be the mother of all our solutions. Now, I'll just tie this up to Toyota again in terms of where this is rooted.So the founder of Toyota is a guy named Sakichi Toyota, spelled with a D-A, not a T-A on the end. And he wasn't an auto guy at all.

He was a textile guy. And he had this fabulous idea watching people in his home village weaving fabric. And the way they tell the story is that as he watched them weave fabric, he got broken-hearted when someone would weave fabric unaware that one of the threads on the loom had broken, and they had spent their entire day making fabric with a run in it rather than fabric good for clothing. And so he invented this loom, and you see it in the picture here, which when a thread breaks on that loom, a little flag pops up to say, "Hey, operator. Hey, weaver.

This thread is broken. Stop weaving. Re-string the thread. Re-string the thread and continue making a defect-free product rather than wasting your time." So that sort of was the initiation of this idea that in operations, you have to manage those operations.

When you have a problem, you can see the problem, so you can resolve the problem. Now, to really bring this home, here's another picture of Mr. Toyota later in life. And the loom here is one also that he invented and actually built.

It's in the Toyota Family Museum outside of Nagoya. This loom, for whatever reason, it weaves in a circle rather than back and forth. You walk into the museum and you see this beautiful mounted loom. And it still runs, it makes fabric. It's very pretty.

And it says on a plaque, "Invented by Mr. Toyota. Built by Mr. Toyota. One of a kind." It's odd. Such a good idea. And why is it one of a kind? That loom will keep running even if a thread breaks. Now, I spent about five years trying to wrestle with this.

If his standard is if the thread breaks, the problem is seen, the loom stops, the problem is solved, right? Why have that as the artifact dead center in the foyer of the museum? It'd be like if you went to the Edison Museum and what they had, the one thing in the center was the light bulb that doesn't glow.

Spent five years wondering about this, but then it dawned on me, this is a Japanese, not an American aesthetic. The monument to Mr. Toyota is not the loom. It's the fact there's no second loom. This principle that whatever you design will break because you're ignorant, you're wrong, and you make mistakes.

This principle that anything you design will break, and because it will break, it has to tell you that you have a problem, so it can be swarmed and solved, and what's learned spread. It was so important to them, so important to them that they decided to show not the loom, but the discipline. The discipline. Anyway, I spent a lot of my career, and there's some book excerpts and whatnot you can see on focusing on the operational side. But what I want to leave you today is to think that you can see what's wrong in your thinking long before it becomes evident in your doing.

And so I'll end with a case here. Again, another anniversary, June 1942. The US Navy sent a task force to engage a Japanese task force at Midway. Now, here's the setup. The Japanese Navy arrived with twice of everything. Ships, planes, sailors, airmen, et cetera, and a whole lot of experience fighting off of aircraft carriers because they'd been marauding around the Pacific for the last couple of years.

Now, that setup, right, of a force twice as big and more experienced showing against a smaller one, or I guess it's in this direction. Twice as big showing up against a smaller one, right? No, no. It's twice as big this way. I got it backwards. Twice as big, right.

All right. There we go. The pantomime. You'd think the one coming this way, twice as big with more experience should win, and that's not how it happened. Now, the reason I have this book up here is these authors did a story, the Japanese perspective on Midway, written out of Japanese interviews, transcripts, documentation, et cetera.

And after they build out this whole story of the Battle of Midway from the Japanese perspective, tremendous detail about what a pilot might have been experiencing in his torpedo bomber as it banked into a dive. They get to the end of the book and they say, "Hey, reader.

So, given what we've told you, when do you suppose the Japanese Navy lost the Battle of Midway?" Which was a disastrous defeat for the Japanese Navy. So you're thinking, "I've seen the Hollywood movie. The Hollywood movie says 3:00 in the afternoon." There's a real guy, Wade McClusky, a lieutenant commander in the Navy.

He banks through the clouds, sees a Japanese warship, drops his ordinance. All right, that's how Hollywood has it. But then you think, "There's no way people write a 500-page tiny print book and reach the Hollywood conclusion. That'd be a waste of time."

So you flip back through the book and you try and think, "Maybe it's earlier on the 4th of June. Maybe it's late May because the Japanese fleet was late and discombobulated leaving its harbors and ports around Tokyo in late May." So you're thinking, "Oh, yeah, maybe late May." So you get to the back of the book after you flip through the front of the book looking for the answer to the question, when did they lose?

And you flip and it says, "Dear reader, by this point, you've probably flipped through the book looking for an answer and have arrived at May 27th as your answer. You're wrong. The Japanese Navy lost the Battle of Midway no later than 1929."

Now, at that point, you're saying, "Don't screw with me. 1929's not even in the book." But then they go on to explain, by 1929, the Japanese admirals had given a lot of thought, a lot of thought, a lot of thought to how you fight with aircraft carriers in the Pacific.

And once they calcified and said, "Ha, we know how this is going to happen," everything else flowed out of that. How they designed their ships and their planes, how they trained their crews, how they planned reconnaissance and patrols, and how they planned for the Battle of Midway.

Now, the authors go on to say they had an opportunity. They had an opportunity to find the flaw in their thinking, but they missed it. Because prior to the Battle of Midway, the Japanese admiralty ran a war game, tabletop, little wooden ships, very cute, like in the movies. And imagine standing at that end are the Japanese admirals, and at this end, there's some junior officer who's got the battle plan, and he's standing in for the Americans.

So they start running the battle plan in this war game, and after a few rounds of this, the referee stops the war game. And he stops it because he says, "Hey, the junior officer is not following the battle plan as it's written." Now, why do you suppose he really stopped the war game?

Yeah, the junior guy's winning. He's beating the admirals. Now, at that point, what should the admirals have done? They should've said, "Hey, maybe..." All right, but what do you think they actually did? Yeah, that's right. They fired the junior guy. They found another junior guy.

And the way this book tells the story, they go through one junior officer, a more junior officer, a senior enlisted, junior enlisted, seaman recruit, some dude selling noodles off the street of Tokyo. But it turns out, anyone who reads the battle plan, looks at the table, says, "If I did that with half of everything, I'm going to get crushed.

I'm going to do something different." So anyway, what happens is they go with their battle plan, and the thing about what a battle plan or any plan is, it's basically a guess of the future. And they had feedback that their guess was not such a good guess, but they said, "We're going to stick to our guess and reject the feedback." So they go to Midway, and they get feedback from Admiral Nimitz.

Now, what's Admiral Nimitz's experience in the preceding years? So the US Navy leadership, like the Japanese Navy leadership, had gone through a similar exercise of battle plans and war games. But on the US side, they would design a battle plan, run a war game, maybe with a comparable junior officer on this side. But if the battle plan went contrary to the plan, they asked the junior officer, "Hey, what'd you see wrong?" And they went through these cycles of updating and updating and updating based on the feedback.

And in fact, they took this as far as when they were running actual exercises, real ships, real planes, real people out in the ocean, which is a dangerous place. You'd think at that point someone might've said, "Hey, Admiral Nimitz, it's fine to mess around on a tabletop with a wooden ship, but when we're out at sea, we've got to rehearse the battle plan because now it counts." That was an alternative, but the choice they actually made was when they were running real exercises.

The end of the day, the senior leadership would not hide in a wardroom below deck. They'd stand on the flight deck and debrief on the war game, on the exercise. Not only would they do that, they'd do it publicly in front of the 700,000 officers who participated, with the officers in the back saying, "Yo, Admiral, I understand your thinking. Let me tell you something.

Your thinking, it sucks. We tried it. It's terrible." With Admiral Nimitz dutifully taking notes. And by the end of the-- After the war, Admiral Nimitz reflects, he said, "Of all the things that happened in the Pacific, as horrible and terrible as it was, basically, there were no surprises because we used this early-stage planning to find out all the flaws in our thinking aggressively before it became flaws in our doing." So let me leave you guys with some homework on this one.

Is that undoubtedly, there are people in this room, actually, all of you, who are planning something, designing something, conceptualizing something. And my bet is that as you're going through this process, you're getting with your colleagues and trying to get the plan, the design, the conceptualization right.

And you're working hard, and you're budgeting time to get it right. And my guess is that for a lot of the things you're planning and designing, you're not committing, dedicating time early often to stand up and say, "Hey, guys, gals, gang, this is what I've got so far.

Tell me what's wrong." So your homework is to take your experience right now and convert it from one which is more like the Japanese preparation for Midway, which is, oh, the point of the plan, the point of the design is to get buy-in, understanding.

We have to get the minions to understand us, as opposed to the point of the plan, the point of the design is to garner feedback on what we think we know so we can get it better and better and better. So I just have to do a quick time check because Gene is--

Time Check (Gene Kim and Dr. Steve Spear)

All right. You have five minutes. I got five minutes left. Because this started, you promised me 30, but it started at 24:58. So I got five minutes to go. All right. Well, five minutes and 41 seconds. All right. So anyway, I'll get you there, Gene.

Dr. Steve Spear

Last time I spoke, I had to run that way as Gene came this way to get me. All right. So real quick, just in terms of making a choice on a different alternative to managing, and the importance of high-velocity learning and high-velocity outcomes.

So I'll preface this real quick. If you all grab that little Bitly thing, you can download the actual case. So, there. You want to take a picture? There you go. And it'll be in the Slack. So, coming out of World War II, the US and the Soviets both had this idea of putting nuclear power on board submarines to dramatically increase the effectiveness lethality of that weapons platform. The US launched their first boat in 1955, the Nautilus. And since the launch of the Nautilus in 1955, the US experience with nuclear power has been absolutely perfect. There's been no environmental harm, no human injury due to reactor failure on a US warship.

Other things go wrong. By the way, the British Navy, you guys were testing out a Trident missile last year, and got spun around, you launch it at Disneyland. There are folks from Disney in the room, so they're a little ticked off by that. But anyway, the reactor was fine.

Anyway, this is the Soviet experience. This is the Soviet experience with nuclear power and submarines in general. About every two years, the Soviet Navy has lost a submarine, its crew, and did terrible damage to the environment.

And this is a very small sampling of the records since the 1950s. Now you ask the question: what's the difference? Well, the start point was the same. A huge amount of ignorance. Huge amount of ignorance about the science, the technology, engineering, et cetera, related to atomic power.

The desired endpoint was the same, which was a sufficient level of understanding. One level of understanding was achieved, and in the other case, it wasn't. The only thing left as an explanation is how these programs were managed. And, this character here is the fellow who is Admiral Rickover, the father of the US nuclear program.

And given the choice of defining adversaries, he could've defined his adversary as a Soviet Navy. He could've defined his adversary as the science, technology, engineering of atomic power. But instead, what he did was he defined as his adversary the lack of understanding. And I'll just talk to this picture in a second. So Admiral Rickover tried to cultivate a culture in his program where if you didn't understand something, you raised a hand.

And Chapter 5 has some cases on this, but just talk because I'm kind of deliberately imitating him. Here's a guy, he's an admiral. He's entitled, like here in the UK or at home, admirals are entitled to wear a ton of bling on their uniform, but he's wearing a gray suit. Not only is he wearing a gray suit, it's on the day the Nautilus, the first submarine, is being commissioned. It begs the question, why doesn't he show up in a uniform with all the navy blue and gold trim and this and that?

And what Rickover realized is that his real adversary is the inability, discomfort of people to raise their hand and say, "Yo, I don't understand." And so one of the many things he did was he started showing up to work in a gray suit. The idea being that if he shows up in a gray suit, other people will show up in gray suits.

And it at least address a little bit the Pavlovian response of, oh, there's someone more senior to me. I don't want to look stupid. Oh, there's someone more junior to me. I don't want to look stupid. Oh, there's a uniform guy. They're so macho and heroic.

I don't want to look stupid as a civilian or vice versa. This is just one of many techniques, but the key point is Rickover defined the problem as behavioral. The technical stuff was a consequence of behavioral. The getting into the market as it were.

Technical, behavioral. The Soviets having the ship at sea because of technical, but because of behavioral. So anyway, the storyline here is when we look at the few organizations which have utterly crushed their competition, it's because people managing other people, people like you, have decided that the objective function every day has to be discovering something new, and the way to do that is expose our thinking to feedback which tells us our thinking is wrong before it becomes wrong in our doing. All right. So, Gene, I'm going to run a little bit over because Gene also did say, "When you're done, ask for help." So here's my ask for help.

All right. Stay back. So, as you can see, my basic thinking goes something like this, is to avoid having to fix a flood, grab the leak. And before you have to grab the leak, which is a hard problem to solve, notice when your pipes are sweating. And if you can solve the problem of the sweating pipe, you don't have the leaking pipe, and if you can solve the leaking pipe, you don't have the flood.

And so, what we've done is we've created a portable Andon because the problem we encountered, the problem we recognized, is that it's one thing you got a moving assembly line, someone works in about the same 10-foot left, 10-foot right space.

But when you have a workforce like nursing, like field service crews, et cetera, people working in amusement parks, where people are out and about distributed and mobile, the person with the problem has this difficulty that they've got their work, and it's a huge overburden to stop their work, go find a computer, log in, send a ticket off to someone else. So what ends up happening, the person with the problem is unseen, unheard, voiceless, and the people with solutions who may be somewhere else, they're deaf and blind to what's actually going on in their organization.

So what we did is we said, well, you guys are IT geniuses. There's got to be a solution. So what we did is we built an app. The app sits on a mobile device, so the person in the field can quickly, within 10 seconds, say, "I've got a problem." That immediately goes to the central service, which is supposed to be supportive of solutions, giving real-time, very rich visibility of people managing systems as to what's going wrong and how quickly it's being addressed.

All right, so that's the setup. Now, in terms of where we've actually used this in practice, so put it in a factory and their uptime went up. We put it in a hospital, connecting pediatric inpatient care to pharmacy. Their rate of missing medication went down by 30% because of this rich real-time visibility of information.

So here's the ask of all of you, which is, in your own organizations, you got anybody who might want to partner with us and try this out? And kind of the right within your organization is maybe 30 to about 300 people. Fairly small, not gigantic, but more than two or three.

Folks who are not computer-bound, which means they're disconnected often from the rest of the organization, out mobile distributed, where they need help from what might be a centralized service, which may not be anywhere close to them. We saw this problem looking at motor pool in Afghanistan, where a young... I'm almost done.

You have 30 seconds. No, I got one minute. One minute. One minute. All right. So anyway, that's the ask, and anyway, while you're thinking through where in your organization you might find someone who wants to partner with us in a pilot of this on-site, here's a little info video to fill 50 seconds while you think and slap me back.

See to Solve Video

Don't you hate it when you get hit by problems that you never saw coming? When you go to find out what happened, you discover that people have been patching and taping and otherwise firefighting recurring problems, never actually solving them to root cause because they have no easy way to stop and call for help. The patches don't keep up, and things get out of hand.

That's where the See to Solve real-time alert system comes in.