Here is a transcript of last week's podcast with Eric Ries talking about the impact that Toyota legend Taiichi Ohno had on his work and the Lean Startup movement. This discussion took place just after the 100th anniversary of Mr. Ohno's birth. Read and listen to reflections from others, including Norman Bodek and Sami Bahri DDS.
Mark: As we're just passed what would've been the one 100th birthday of Taiichi Ohno, one of the fathers of the Toyota production system. I wanted to get your thoughts because you cite Mr. Ohno a few times in your book and I'm curious how did you get introduced to his work and how did he influence you.
Eric: It has been incredibly influential, I think I would go so far as to say it has changed my life. It's actually just a coincidence, it's a funny thing how these things work. To just set the stage a little bit I had founded a company called IMVU in 2004 and I was really into a lot of the ideas that are called agile software development which have their origins in lean. But a lot of the works I had read about them Toyota was not specifically mentioned, lean principles were not mentioned, so I didn't know the theory of a lean or anything like that. I knew nothing about manufacturing. I have actually to be totally honest never set foot in a manufacturing plant in my whole life.
I had no idea at any of that would be relevant to me. But I had this intuition that we should be going a lot faster in a startup and doing practices that even in the agile world were considered a little bit extreme. We've had the chance to talk about them on other occasions things like continuous deployment really putting software customers hands much faster than was previously considered possible.
I had this problem which was, I had no way to explain to anybody why that was going to work. People were looking at me like I was completely crazy. I could see that it was working because I was very stubborn and I had this intuition. I said we're going to do it no matter what.
It was working, we're always hiring new employees, the company's growing, we're bringing on investors. We had investors that when they were doing their due diligence for the company pulled out because they didn't like the answers I was giving them about how we built the technology.
They would bring their experts in, experts trained in more traditional software development methodology. They'd be like this kid is crazy, he doesn't know what he's talking about this is not the way it's done. It was a continuous point of stress for me and my co-founder, OK.
You have to remember at the time I was by far the youngest person on the team and I was often younger than the employees I was hiring and training in them in this method. It's not like it was this easy situation to be in but I really believed it was right.
So I was reading everything I could get my hands on for ideas about first of all was I actually right or was it a fluke? If that was right how could I possibly explain it? I had read some cases about Toyota, business school cases so I was a little bit familiar with that. There was this thing called Toyota Production System that's all I knew and I figured I should be educated about it.
I go on Amazon and I type in “Toyota Production System” and lo and behold this book by Taiichi Ohno comes up called Toyota Production System. I said perfect, it must be the definitive guide. Toyota Production System, I got this book and I'm holding in my hand right now. I found my copy.
You've read the book, it is a very wise, very humane philosophical treatise on how to run a business. As a practical manual for setting up a factory or doing any other task it is not exactly your step by step guide. I remember just having this feeling that I was reading something crazy.
It is kind of like Zen mumbo jumbo about auto-nomination and automation with a human touch and all this stuff. But there is that one passage about about five whys in there and just all the sudden for me for what ever reason that little section where he talks about trying to get to the root cause of problems by just asking why.
He has a few examples, things that I don't even know what they are. A machine with a strainer it incorrectly attached. I have no idea what that looks like, never seen a machine strainer my whole life. But somehow his their humble, very analytical approach was like a lightning bolt to me.
I said, “Oh, I can do that. That is going to solve a huge class of problems that I have in my life where I'm constantly fighting with people about how much prevention…” When something goes wrong do we the person, do we blame the computer, do we fix just that problem, do we try and solve that whole class of problems?
That was super helpful. That was one of the very first times I've learned to see the work that I was doing in the management as a system that needed engineering and debugging just like the software I was used to writing.