The LEI was kind enough to send a review copy of their new book, the second edition of Lean Process and Product Development. I have just started it, and am already finding gems. (note to the LEI – the Kaizen Institute is not my address. Thanks to Jon for getting the book to me.)
The original edition was a cleaned up manuscript that was published well after the death of Allan Ward, and bore only his name on the cover.
This edition adds Durward Sobek to the author line. Sobek was a student of Ward and today stands on his own as someone whose views should be respected.
I am not going to try to compare the two editions, rather look at this new book as it stands on its own.
Rather than wait and write a big long review, I am going to publish short posts as I come across key points of note – hence the subtitle of this post.
I am already seeing a tight link to the leadership model outlined in Toyota Kata.
In the 2nd chapter, as the authors discuss Value and Performance of development projects (as in how efficiently they create profitable value streams and create usable knowledge for future projects), I came across a compelling quote:
A general manager of Toyota’s Advanced Vehicle Development department was asked how he spent his time.
He replied he spent about 2 hours a week doing administrative work, and the rest of the time “on technical problems.” Before I remark about the “technical problems” consider the first bit. How much time do your department heads spend administering vs. contributing to the development of the organization?
And that leads to the second part. He says:
“But every technical problem is also a personnel problem, because the problems don’t get to me if my people know how to solve them. So all of the time I’m working on technical problems, I’m also teaching someone.
To paraphrase the next paragraph in the book, the solution to personnel problems is to teach.
So I’ll digress from this book a bit here, and read between the lines a bit. If we go back to David Marquet’s sketchcast video he talks about the necessity of creating an environment where your people need to discover the answer, or “you’re always the answer man, and you can never go home and eat dinner.” (This is really hard when you know the answer, by the way.)
So already, in the first couple of chapters, we are establishing an environment that doesn’t simply produce engineering designs. Those, I suspect, are an outcome of deliberate processes to build the organizational competence and clarity.
We’ll see. More to come.