Dear Gemba Coach,
We often hear that Toyota chief engineers have no power. Really? So how does that work? Why such an organization? What problem does it solve?
No formal power doesn’t mean no power, but yes, what I’m told is that Toyota’s chief engineers (CE) have no formal authority over designers in their project, which doesn’t mean they don’t have a great deal of influence.
As Takao Sakai points out in his new book, The Secret Behind the Success Of Toyota, there is no greater waste than a product that does not sell. He rightly argues that the lean movement is by far too focused on manufacturing and misses that 90% of the value is designed across the road, in product development (I strongly recommend the book if you want to learn more about the chief engineer system). Product development produces design information, which then gets realized, more or less happily, in production. Good plants are essential to:
- Realize the design information correctly (value analysis)
- Give good feedback to the engineers for the next product (value engineering)
What is the problem we’re trying to solve? In order to succeed in its target market, five problems have to be solved correctly:
- Attractiveness: Which features do customers take for granted (and if not there, simply won’t consider the purchase) and which new features they look for in their constant expression of “never enough.” Attractiveness is a complex mixture of permanent needs and fashion-led impulse wants.
- Cost: The market price of products is generally more or less set and if the company wants to make any money, it has to manage the overall cost of the product or service in order to make a profit. It is a total cost, for instance, think of the marketing budget that goes with a Hollywood film on top of the production budget.
- Compliance: Each country and industry has different regulatory norms and practices and beyond doing the job and attracting interest, products must also comply with various regulations.
- Product tech: To deliver the attractiveness of features, technology choices must be made, in a constant trade-off between performance, reliability, (quality) and total cost – both for the user and production.
- Production tech: Once product technologies are chosen, there are yet more choices to make in terms of production technologies, even in similar physical processes. For instance, do we want a high-volume press or a smaller, slower one to make parts one by one.
By the very nature of technology, tech products are the result of meshing together various specialties. No one can master every field, and the more high-tech the product the greater the knowledge specialization, this is unavoidable. To be the best in the world in a specialty mostly involves committing oneself to this field at the expense of others.
Benefits and Problems with Silos
Functional silos are therefore not only unavoidable but also necessary. This first became clear to me as far back as 1995 when I published a book on business process reengineering (which I wish I could recall): specialized functions work as universities where engineers learn to be good at their trade, under the leadership of the department head.
The problem, therefore, is how to both get it right on the five types of technical choices, attractiveness, cost, compliance, product technology, and production technology, whilst pushing a development project through functional silos with all that this involves.
Silos, in particular, lose track of the overall needs of development and tend to focus on functional culture and functional trends. For example, it’s not unreasonable for the IT department to want to try the latest advantage of cloud computing, or, on the other hand, remain fixated on an old, legacy technology it knows well (often engineers love to find new applications to technologies they’re masters of). I was recently invited to a management awayday, with the whole management team, and in the train, the HR manager was reading … an HR magazine.
The problem, therefore, is to bring all these specialists together to come up with a successful product.
There are several ways to do so. The most common is deciding by committee. The development flow is mapped, typically as market needs or opportunities → product concept → business case → main design choices → detailed specifications → suppliers briefs → prototypes → tooling → start of production → sales briefs etc. These processes vary from company to company, but there tends to be one with “gates” at each stage to move the project formally from one stage to the next (or kill it). At each of these gates, a management committee makes the key decisions to move the project forward.
Another common way of handling this process is that one member of the committee, often the CEO, but not always, highjacks the process and imposes his or her view on the rest of the functions.
In most companies, the process is handled by a “project manager” who is more of an administrator, in charge of moving the project forward and controlling schedules and overall project costs, but rarely technically competent enough to stand up to specialists or with enough clout to stand against the “highest paid person’s opinion” pressure.
What Would Steve Jobs Do?
Back in the days of Eiji Toyoda, Toyota engineers (several having been trained by German engineers in airplane development) concluded that the only sane way to make a smart synthesis was to have single point accountability. One single person responsible for the success (or failure) of the product on the market, which meant one single person able to make the final trade-off choices in other to deliver a mix of attractiveness, cost, and compliance through design choices and production choices. This person would be the “president” of the product project.
Think Steve Jobs. In his case, he was both CEO and chief engineer of Apple, and Apple came out with revolutionary products sequentially as he focused on one, and then the other, all the way to presenting them to the public in his legendary shows.
Since the chief engineer is bringing the product to life from concept to sales, and, on the contrary, individual designers are only involved with the project at one stage or other of the project, and then move on to the next one, it makes sense that the CE has no formal authority on the designer – only the function heads with power of evaluation and career development. I’ve been told that Toyota takes this to extremes (I have no sure way to check) and that at each product milestones, engineers are reassigned to the next project whether the current work is finished or not. Not missing a milestone is not a nice-to-have, but a life-or-death issue for the CE who makes decisions and choices accordingly.
A CE is therefore first and foremost a product guy or gal. He or she is personally responsible for the architecture of the product (think like a movie director or fashion designer) and will make all the important trade-offs as they crop up, from architectural choices to minute details, according to his or her vision or interests. To best visualize what the CE does, check out this fascinating video where Mike Sweers, CE of the Tundra explains to pick-up fans the choices he made with the truck he signed: https://www.youtube.com/watch?v=vsQ4tHIThs4
The structure of the videos shows the features on which the CE focused, powertrain, drivetrain, frame, etc., and then the CE explains the link between customer benefit to technical choice (and where the trade-off is).
No organization is perfect, and every high-profile model story is different at Toyota – the Lexus development story is very different from the Prius development story, according to both the CE personalities and where the company was at the time. Although this feels rather open-ended, this is also where the model is brilliant, by combining the stability of functional knowledge and the adaptiveness to the spirit of the times, both on the market and within the company, by having each new product developed with a person-centric bias.
Forget “Cool”
Don’t assume, however that this works smoothly – the tension between CEs who want to have all the best, newest, sexiest features to make their model succeed (in their lights) and the profound conservativeness of functions, who on top need to make sure the new model can be assembled effectively on existing production lines, is always very high and there are endless reports of open conflicts and arguments as products come together.
Indeed, a key skill of the CE is to be able to listen and influence rather than dictatorially impose their views (not that some of the most famous CE stars in Toyota were not dictatorial). But in this way, compromise happens very close to the gemba, on specific technical decisions, whilst retaining an overall view of the product aiming for a market. This balances the CE designing great products that can’t be produced at cost and functional engineers being fanatic about some technical solutions that bring no real value to customers. It’s a different way to handle the fundamental trade-offs of product development. For instance, as CE, Mike Sweers tells how he learned to question a technical choice he’d made when he was in a previous job as a seat designer. Akio Toyoda told him at the time, “Don’t give customers what you feel is cool, but what they really want.”
For all its apparent inefficiency, this system allows the company to retain the view that each product is unique and that there is artistry involved in great engineered products.
I wouldn’t say that Toyota chief engineers have no power. As a group, they must be the most powerful people in the company as Toyota management recognizes its future success or failure rests on its ability to grow great chief engineers (they consider they have a very mixed record on the subject). Chief engineers have no formal authority on designers, but their influence on people’s careers is considerable (imagine being a designer the CE requests nominally, or one the CE doesn’t want to work with).
No system is perfect, but Toyota’s track record in producing product after product that sells profitably (as opposed to more visible competitor models that don’t sell or lose money) as is currently debated in the TPS vs. Tesla discussion, shows that the system has its advantages both for immediate profitability and in the long run.
