malvasia bianca

A quote from Morgan and Liker’s The Toyota Product Development System:

Toyota does very little “information broadcasting” to the masses. Instead, it is up to the individual engineer to know what he or she is responsible for, to pull what is needed, and to know where to get it.

Here’s the full context (pp. 95-96; italics in original):

Pulling Knowledge Through the [Product Development] System

In lean manufacturing, pull production eliminates overproduction by having downstream activities signal their needs (demand) to upstream activities. Kanban cards usually signal (control) production in a pull system. In product development, knowledge and information are the materials that are required by the downstream activity. The speed at which technology delivers information in automotive product development is overwhelming. However, not all information is equal to all people. The lean [Product Development] System uses “pull” to sort through this mass of data to get the right information to the right engineer at the right time. Knowledge is the fundamental element (material) in product development.

Toyota does very little “information broadcasting” to the masses. Instead, it is up to the individual engineer to know what he or she is responsible for, to pull what is needed, and to know where to get it. Individual engineers are expected to locate and extract needed information, whether this be design data residing in the data collector, a product performance experience, or a perspective from a senior executive. This policy holds true for everyone, from the most junior design and release engineer to the chief engineer. The key underlying principle that makes this work is that everyone has access to both the design data and the [Chief Engineer].

For an example from the opposite end of the program hierarchy, all engineers are responsible for creating benchmarks for their respective components. They are expected to gather relevant information and understand the latest technological developments, industry trends, and supplier and competitor products that affect their designs. Once the execution phase begins, manufacturing engineers pull design data from data collectors as they need it to start working on die or fixture designs. All engineers pull requirements from checklists, which are updated at the end of each program.

The supplier mentioned earlier (a company that had an unacceptable management cycle time) illustrates how the [Product Development] system links processes. This seat maker through value stream mapping identified thaht they were batch dumping information onto the next process (design sent hundreds of drawings to purchasing and ordered hundreds of parts prototyping, to build the hundreds of different variations of prototype seats, etc.) After moving to a staggered release system where a subset of seat designs were released on a preplanned schedule, weekly reviews of progress were set up and the supplier set up status boards at each functional area within the value chain. A key purpose of the status boards (referred to as “pull boards”) was to signal the need for information from other functions. Once the status board was in place, it was easy to spot when key information was needed. When key information was delayed, it was identified within a week rather than months later. The example clearly shows that in a lean [Product Development] process, a key enabler for pull knowledge systems is reducing management cycle time.

At first, I was thinking of “don’t broadcast information” in terms of “I don’t like being lectured at”, which made me happy. But I do like a general low level of chatter among team members – e.g. at our daily standup this morning, two of us were talking about what we did yesterday, and another team member mentioned an old bug report that turned out to be relevant, quite possibly saving us a day of time. And if we hadn’t been broadcasting information, that wouldn’t have happened. Then again, some XP sources suggest that the need for a daily standup is a sign that your process isn’t working well enough, but then yet again that’s because they want information to radiate even more (by everybody working in a big, open room, constantly interacting). But that only works with teams below a certain size; eventually, you have to cut off universal chatter to save your sanity.

When I balance all that, I tend to think that I like broadcasting information within a group of a certain size. And I bet Toyota does, too, I just need to find the right section of the book. I could be wrong, though; it’s certainly something to think about. That’s the problem with reading books like this: I’m missing so much of the context, so many details, so much of the gestalt.

Moving along, we see that individuals are apparently able to pull the information they need at will. Which is certainly a problem that we have: we have various “data collectors” (especially our wiki), but they’re not well-organized, consistently maintained, and up to date.

One interesting thing about Toyota product development is apparently that, on the one hand, they’re quite good at consistently storing information, e.g. about results of experiments (whether positive or negative). But they also manage to do this in a terse, accessible form: I’m pretty sure they save the lab notebooks, but they also put their results on a standardized single piece of paper, the “A3 form”. I haven’t yet gotten to the section of the book where they talk about that in detail, but it sounds like it could be a really useful idea, and if done right a very useful antidote to wiki chaos.