The Chief Engineer Function

All the books about Toyota's product development system describe the critical importance of the chief engineer. Books like Jeffrey Liker's The Toyota Way have told the stories of legendary chief engineers like Takeshi Uhiyamada, chief engineer for the first Prius and Ichiro Suzuki, chief engineer for the first Lexus. The chief engineer is the person who shepherds a car through the development program, providing deep knowledge, a guiding vision and the day-to-day decision-making that create exceptional products.

With the recent ruling that Toyota's chief engineer for the 2007 Camry Hybrid died from overwork, it is no surprise that questions come up about whether or not a single person can handle all the responsibilities embodied in Toyota's chief engineer, and whether or not that role is required for an organization to reap the benefits of lean product development.

Of all the practices within lean product development, the chief engineer is one that is guaranteed to raise questions and eyebrows during my presentations. I hear everything from, "That can never happen here!" to "They just named me the chief engineer. What am I supposed to do?" Assigning a single person is impossible today in most U.S. companies because old conventional wisdom about product development discourages people from developing into the kind of person who can be a true chief engineer.

In American companies, even creating the role of a chief engineer is often fraught with political difficulties, because it upsets the power structure within product development. A true chief engineer will interact with engineering, marketing, manufacturing AND senior management in ways that run counter to the way most of us think about product development. If the company is ready for that type of disruptive change, this is a good thing - since the thinking patterns that resist the chief engineer are the same ones that slow down product development, increase costs and lower product quality needlessly.

For most companies, however, changing all those thinking patterns takes time. Rather than throwing a new chief engineer at the problem and hoping for the best, it is better to take a more measured approach while the company develops its lean thinking skills. If we can't assign a single person, we can at least ensure that the current product development leadership structure has the ability to perform the same integrating function as a chief engineer.

The "chief engineer function" is the ability of an organization to integrate its best customer, technical and process knowledge into outstanding products. One good first step is to tear down the wall between marketing and engineering, perhaps by assigning marketing leads who co-locate with their product engineering teams. I have seen groups assign a marketing lead and a technical lead - and then give them a shared office with just a few feet between them, so that they are in constant communication.

Over time, the company's needs and ability for a chief engineer will develop. As the company leans out its development process (especially project status reporting waste), develops a strong base of shared knowledge about its products and processes, and deepens its customer knowledge by having the senior technical staff go-and-see customers for themselves, the chief engineer function will grow. The people who are capable of becoming chief engineers will emerge - sometimes from unexpected places. At the same time, the need for this integrating function to happen as fast as possible will arise. At that time, it may make sense to designate a chief engineer - and then give that person everything he or she needs to succeed in that role.

Impedance in the Knowledge Flow

What things impede knowledge flow in your organization? Where are the places where knowledge flows - just not as quickly or as clearly as it could? Here are the top 5 sources of knowledge flow impedence I see in my travels. Which ones apply to you?

• High Noise - Low Content Communication Channels: Over-reliance on communication channels that tend to hide or distort information. These include audio-only conferences (especially those done late at night at the kitchen table to deal with time zone differences), slide sets with more than 1 slide for every 2 minutes of presentation, most email, memos and reports that are longer than two pages or anything that requires access to a system that is hard to navigate.


• Overloaded Resources: Don Rienertsen's Managing the Design Factory lays out a strong case demonstrating how overloaded resources slow down development. But did you realize that they also slow down the flow of knowledge? People juggling too many projects in too few hours will be driven to take shortcuts that stop the flow of knowledge. They will stop taking the time to talk to others working on similar problems to figure out how to share solutions, and they will resist requests to share their knowledge with others if it doesn't help them with their immediate to do lists.


• Artificial Organizational Barriers: knowledge-sharing works best in an organizational structure that is a balance of both strong functional and strong cross-functional teamwork. On the one extreme, departmental silos prevent knowledge from spreading to related functions. On the other extreme, product-centered teams don't share knowledge effectively across products.


• Lack of Common Engineering Tools: Knowledge gets stuck when one set of tools (product data management systems, for example) can't talk to other tools. This is one area where the benefits of standardizing on a common toolset is well worth the pain. Teams working on similar problems need access to each other's information in ways that can be easily shared.


• Complex Knowledge Management Tools So-called "knowledge management" tools often become write-only databases because it is too hard to store information in them, and then too hard to retrieve it. With new search technologies like Google Desktop, you don't need a specialized tool to manage knowledge. Simple, searchable file shares of electronic A3 reports may be all that you ever need.

As you can see, most of these barriers are structural - embedded in the organizational structure, culture and IT systems that support the organization. This list contains few ideas for quick wins. The companies that have strong flows of knowledge in their organizations have worked for it, relentlessly identifying and eliminating the barriers to knowledge flow.

What can you do? Individuals working on their own can greatly improve their knowledge sharing effectiveness by attacking the high noise - low content communication channels within their direct control.

If you lead a product development organization or work on a lean product development team tasked with improving knowledge flow, it would be worth your time to identify the specific impediments to knowledge flow within your organizations, and invest the time to fix them as part of your lean product development efforts.

A3 Reports: It's All About the Paper Size

I occasionally run into people who don't like the term "A3 Report" - they think it's an obscure title for a simple tool. An A3 report is a document written on either A3 (metric) or 11" x 17" (U.S.) paper - twice the size of letter paper - to capture the essential information about a problem under investigation or a piece of valuable knowledge. You can find examples of them here in my Resource Center.

I encounter a lot of people who want to call these things "knowledge briefs" or something similar. I'm normally fairly flexible about the language people use to describe their work. But I've been resisting this trend with my clients, for two reasons.

The first reason is that everybody else calls these things "A3 reports" - so if you want to find out how other people are using concise, visual reports to solve problems, you want to search on the term "A3 Report" to find the answers. For example, you'll find the excellent book released this year by Durward Sobek and Art Small called Understanding A3 Thinking: A Critical Component of Toyota's PDCA Management System.

However, that's not the only reason I resist. Answer this question: how long is a Knowledge Brief?

The only possible answer is "it depends on what you mean." However, an A3 report is - by definition - on A3 paper. If it's on letter paper, or it's two or five pages - it's not an A3 report.

The paper size drives the right behavior to foster rich discussion, true knowledge sharing and good decision-making: distill the problem to the essential information, keep all the essential information visible at all times and use visual models to improve the flow of knowledge. To describe your problem on a single sheet of paper, you have to think about what's essential, and you learn pretty quickly that it's easier to be concise when you use pictures and other kinds of visual models rather than text.

Occasionally, I'll run into a company that has difficulty with the paper size - maybe they don't have printers equipped to print that large, for example. However, the visual models on an "A4 Report" (letter sized or 8.5" x 11") have to be fairly small to fit, and the reports have to be distilled down to the point that essential information has to go on a separate sheet. If you print the missing information on the back of the "A4 report" you have just hidden essential information, since I can no longer see it all at once.

Rather than go that route, I would rather solve the mechanical problem of "how do I print on A3 paper?" The small expense of installing a few large format inkjet printers for A3 reports is far outweighed by the benefits of using a format that has been demonstrated to lead to faster, better decision-making.