Keeping the Critical Path Clear

Lately I've learned something. It happens from time to time, and - as they say - the day is not wasted when it does. Yet again, it's thanks in some part to those very clever engineers at Toyota and it comes to me while learning about how they manage to design cars about twice as fast as their closest competitors. It's nice that something I picked up around a month ago and have told my product and program managers I want to apply is echoing back to me via other members of the management team as a principle they wish to pursue.

Lesson one is simple:

Keep technological innovation off the critical path of new product development

Let's look at this in detail.

The first thing that needs to be stated is that this doesn't mean don't innovate. It simply means don't make the release of your next product depend on it. By all means (and necessarily, I'd say) pursue technical innovation, but deliver it when it's ready via the most appropriate release vehicle at the time. I've heard Tom Gilb refer to this as "front room, back room", with the metaphor of a busy restaurant: the waiters dash back and forth with whatever's ready, rather than standing in line waiting for the order for their latest customer, and the chefs busy themselves in the kitchen, expecting each new dish they finish to be whipped away to a hungry punter almost as soon as they have finished it.

The second thing that's important here is to recognize that it's the critical path of the current new product development you're trying to protect, not the critical path of getting a new innovation to market. Innovations and technical advances that involve a lot of R&D are inherently risky: there are unknown lead times and complete failure of ideas has to be an option, or the creative process can be seriously jeopardized. You don't want this risk in the equation when you're trying to predict the time it's going to take to get something into a customer's hands.

In fact, I believe that the time it takes to get any new innovation to our customers may actually be reduced by applying this principle. When you hold a product back because something isn't ready, you're holding back all of the things that were ready when you started. Providing a predictable cadence to new product deliveries means that you're R&D or creative team know that anything completely new the come up with will be carried straight to market in a predictable period. Release a new version of your mainline product every 6 months, and new innovations can be delivered in 6 to 12 months (remembering that you need to let any release in progress complete before you can get your features into the next one). Using Tom Gilb's analogy again, it's about shortening the time it takes for a waiter to get orders to the table that's critical in this argument. (Although it helps to get the cooking time down too, but that's a subject for an entirely different post!)

Lesson two here is perhaps a bit more subtle, and it's for all of the people who are skeptical about what the manufacturing industry can teach the software industry: it's the way that Toyota, Honda and the like think that makes them great, not the actual systems that these thought process give rise to per-se. Absolutely yes, the Toyota Production System itself is no good for developing software, but the learning processes they went through to get there are. The Toyota Product Development System is a testament to this.

Perhaps it's our way of thinking in the West that blinkers many of us to the fundamentals behind such a system as TPS and instead focuses our attention on the product of it instead: it's all apples, oranges and plums to us, which can't be closely related right? But they all grow on trees.