Translating that spirit of cooperation to a Western context isn’t easy, because it demands aligning the goals of all product development programs as tightly as possible. It won’t work without two types of people in place: a true chief engineer for every program (a shusa equivalent) and every functional team (a bucho equivalent). Both individuals must have the experience to succeed and the respect of all players on their teams. A successful R&D career at such a company may include time spent as both a shusa and a bucho — and, most importantly, time spent internalizing the needs and priorities of both sides.
Most Western companies take a process-driven approach to product development, involving elaborate handbooks, compiled over decades, that prescribe hundreds or thousands of deliverables, checklists, and coordination meetings — all no doubt good ideas when they were developed for some long-forgotten project. But because engineering teams rarely have the time, resources, training, or inclination to meet all these requirements, management often appoints “process police” who are charged with driving compliance with the handbook, while mandating sparsely attended, high-level “gate reviews,” all in the name of keeping the program on track. Well-intentioned as the system may be, the result is a project development team that spends far too much time — and money — on compliance and reporting, and not enough time on experimentation and technical problem solving.
Instead, establish an event-driven approach in which various key decision points (events) are laid out in sequence, along with the engineering results that will be needed to make each decision. Hold your engineering teams accountable for meeting various technical objectives by a specified time. In the course of their work, they may use checklists and procedures to keep track of their progress. But leave that to their discretion. Invest your oversight in helping them make better technical decisions based on rigorous data and experimentation.
Simultaneously, refine your knowledge processes: your means of capturing information about processes and products and making systematic use of that knowledge. Expect design engineers to maintain their own benchmarks, industry standards, technology trends, and supplier data for the components they work on. That might include the creation of checklists, trade-off curves (plotting diagrams of component performance), A3 reports (detailed breakdowns of technical problems, which take their name from the A3-sized tabloid paper on which they are plotted), teardown analyses (detailed evaluations of competitors’ product costs), and other quality-oriented forms of observation and analysis. Engineers should also be trained to synthesize this information and articulate what it means in the wider scheme of the product development process.
A well-designed knowledge-building process will help you build both technical problem solving in the short run and more extensive capabilities in the long run. This type of learning doesn’t just happen. To develop such a system of your own, you will undoubtedly apply information technology in innovative ways, but the most important aspects are human: engineers continually thinking about the significance of what they observe, and management continually rethinking the way knowledge is put to use. Can you design a system in which engineers “pull” the knowledge they need, as they need it, rather than having someone “pushing” knowledge at them? Can you manage such critical processes as teardowns so that every engineer is responsible for his or her part in the process? And can you institute a more effective program “postmortem,” capturing and institutionalizing the lessons from each launch, to the benefit of future projects?
Instilling a Flexible Risk Ethic
Every product development project brings with it inherent risks: technical risk (will it work as planned?), schedule risk (will it be ready in time?), market risk (will people buy it?), and financial risk (will pricing, costs, volume, and program life come together in such a way that you can make money?). Many companies aspire to eliminate risk by embedding a system of constraints in their product development processes. When programs go over a cost threshold, miss deadlines, or leave too many problems unsolved too long, “red flags” are raised that bring unwanted attention and sometimes penalties. Then all work on the project halts while the issue is dealt with, often in the hastiest manner possible to bring the project back into line.