12:30pm ET
Lex here again writing from the LPPDE 2014 conference in Durham. Check out the blog from Day 1 of the conference here.
Jim Womack Shares His View of Lean Product (and Process) Development
Womack (author of Lean Thinking among other books and founder of LEI) kicked off day 2 this morning introducing himself as “that old lean guy who thinks about lean in the world, in a larger context.” He also identified himself as “the guy who put the P (for Process) in LPPD.’”
Womack began his keynote by reminding us that from his view, whether we like it or not, the customer is THE sole judge of value. Customers want a product that can solve problems for them. Then the organization’s job to do more with less from across the enterprise. Across being the key word and idea. Being lean – and/or improving one’ s product development process – these things aren’t a matter of following a prescribed set of rules or one right learning path; it’s about running some experiments, learning from them, and then comparing how you’re doing after the fact to how you WERE doing before, Womack says.
Before getting to his personal view on LPPD, Womack reminded that lean is situational (something John Shook has spoken about as we’ve seen lean thinking move into new and different fields and be picked up in different ways). We tend to forget this. People desparetely want to be told what to do when it comes to lean thinking, Womack says, but we mustn’t forget that word “thinking” in “lean thinking.” We have to think if we want to change the way we operate in our teams and organizations. Lean change is really on us.
When it comes to product development, Womack sees the problem like this. Most organizations are organized vertically (this hasn’t always been the case, but it is the case now and this likely isn’t going away anytime soon he says… and “people at the top like this fact!”). But the product needs to flow horizontally across the organization in order to be made right/well and solve a real problem for the customer. Every time the vertical and horizontal structures intersect, as an engineer or developer, you’ve got two bosses. The challenge is how to think horizontally in a vertical world.
The way Toyota did this, he says – not that we can all be Toyota, nor should be – is to have a chief engineer. The chief engineer is the person responsible for “surfacing contradictions within the organization” and “getting a conversation going about what the right thing to do is for the customer and the company.” (Here’s another example of leading without authority, a lean principle basically you’ve got to lead by doing the work and solving problems, getting your team members (at multiple levels) engaged with you solving problems). Just listening to Womack, I’m reminded that just focusing on problems tends to help with that horizontal/vertical disconnect.
The idea at Toyota was/is this: your chief engineer helps different parts of the organization work together, makes things “whole”. The question for developers at organizations without this role – how can you be more effective in creating some sort of chief engineer function?
Next, Womack dove into a bit of Toyota history, reminding us how TPS (the Toyota Production System, the roots of lean thinking) began. Taicchi Ohno said he was simply looking for a way to shorten the time from order to delivery and “get to cash”, not have so many resources tied up as auto companies do. He didn’t have a name for TPS and he wasn’t interested in naming it. “It was a series of desperate experiments to go faster with less,” Womack says. It was absolutely not a program; it was devised by line managers doing experiments. Only after they ran some experiments and those turned out to be successful was it given a staff and a name. Why? Toyota needed teachers and needed suppliers (and to work more effectively with suppliers). It turns out this isn’t easy. (Tell us in the comments, please – what have you learned trying to work collaboratively with suppliers?)
“What Toyota did well was clearly and precisely link information and action,” Womack says. This idea too often gets missed, and so many of our organizations have the same challenge today. This is what lean product and process development is all about. How do you get your product developers (and the larger organization) to focus as much on process as product? This is the question we need to be focusing on as a product development community, and it requires everyone’s participation if we’re going to make change in our organizations and in society. It requires running experiments and then sharing what we’ve learned. No, it’s not easy. Womack acknowledges this: “Most organizations only want to run successful experiments and share learning from experiments that are successful.” This is why you need a leader who is interested in solving problems, he says, not having all the answers.
From this writer’s view, the good news I suppose is we can start running experiments and thinking about leadership differently today/now. Even if our actions in a new direction are small.
“I try to give people courage to try stuff, to try new things,” Womack says. “And yes, it does take courage.” An honest note to end on.
More to come…
“Somebody Has to Start Somewhere” – A Panel Conversation on LPPD Practice with Jim Womack, Kevin Nolan, and Doug Pericak
3:30pm ET
After keynote talks by Jim Womack, Kevin Nolan (GE Appliances), and Doug Pericak (Ford) this morning, all three speakers took the stage for a panel conversation on what’s next for LPPD moderated by Terry Barnhart.
To start, Barnhart asked everyone to share their thoughts on what LPPD even is from their view.
For Pericak, from a chief engineer’s point of view, he says it’s being smart about how you approach PD in every way and just good systems engineering. (He says a lot of organizations are doing component engineering, which doesn’t allow you to be lean). With systems engineering, you’re going to see better results in cost and quality. For Nolan, it’s about engaging everyone in solving problems, connecting different parts of the organization, and creating enough flexibility in the organization for engineers and developers to shine.
Next, Barnhart asked Womack to share his thoughts on where to start. A lot of people want to “do lean” or start doing LPPD, but how? Jim brought it back to people. “Somebody has to start somewhere and say ‘the future will be better’ because of me.” It’s about taking ownership for making things better. He told a story of Jim Morgan’s leadership at Ford, how Morgan went out and did the research, visited Toyota, learned new things, and brought that knowledge back.
The goal is to do get people to do process development on their product development. It’s fine if you don’t know what to do and you just know there’s a gap. Acknowledge what the gap is.
Then the conversation moved on to the ever popular question of “culture change.” How do you change people’s minds, get people to think differently, introduce new ideas?
Nolan says a big part of this is giving people good examples to look at. Showing people there is a better way. People are always going to want to do the more comfortable thing, he says. The job for the lean manager or chief engineer or any lean practitioner is to get the organization out of its comfort zone. “If you don’t, you won’t survive.” Pericak suggests rewarding that person who has a passion for making things better, and looking for people who aren’t just flying in and out of the organization, but are willing to develop a longterm relationship with the customer. For LPPD, Womack says organizations need to value the role of chief engineers much more. How do we get companies to do this? “Here’s another area where we should be running experiments!” Womack says.
Other key insights:
- Nolan reminded us that leaders/managers don’t always add value in talking with engineers/developers. You don’t want to ask engineers to jump through hurdles to do something customers don’t care about. Be mindful of this when conducting experiments.
- Pericak spoke about the need for leaders to be involved closely in design reviews. When people realize their time is being wasted, they put in a fraction of the effort. When people see that a chief engineer is fighting for them, design reviews become magical.
- Pericak also suggests 30 min daily huddles with your team to get on the same page about where everyone is focusing their attention that day and if everyone is working toward the same goal, on the same problem. A daily huddle is also a good chance to give everyone a chance to contribute and this creates goodwill and momentum. You want to make everyone feel heard.
- Womack can’t emphasize problem solving enough. You’ve got organizations today where people go in and do the same thing that isn’t working… but people go in and do the thing they know will look good on their “performance review” (disconnected from the real work to be done). “Isn’t that tragic?” he said. “So don’t do that. Figure out a way not to do that.”
- Womack reminded us about just how capable almost everyone is of succeeding/adding value/helping the organization if they have a good process. (You may recall W. Edwards Deming’s words: “A bad process will beat a good person every time.”)
And once it came time for Q&A, this I thought was the most interesting question from the audience: “What do I do about the problem of alphabet soup? People don’t want to learn ‘lean’ and in product development, they’re already memorizing a bunch of other acronyms. How do we solve this problem? And what is the ‘correct language’ for implementing these ideas?”
Womack chimed in with this provocative bit of wisdom/handy advice: “The correct language is the language that produces results… the language that resonates.”
