It is important to go to where the action is taking place. I was taught this as a young officer in the Navy, where, as in other areas of the military, we emphasized “leading from the front.” In warfare the reason is obvious: it is difficult to assess a complex situation from a distance. The further you are from the action, the more your view is obscured by what the great military writer Clausewitz called, “the fog of war.”

So, you would correctly guess that I support the idea of “going to gemba.” For those unfamiliar with this term, the Japanese word “gemba” refers to the location where an activity takes place, for example, the factory floor. Going to gemba is revered in lean manufacturing where one is told how Taiichi Ohno taught observation to new engineers. (Ohno was Toyota’s VP of Manufacturing and the genius behind the Toyota Production System.) He would make an engineer stand in the middle of a chalk circle and tell him to observe and take notes. Later he would return to see if the engineer had observed enough. Ohno believed that observation was the best way to understand what is happening on the factory floor.

Although I agree with Ohno about the value of observation in manufacturing, it is worth understanding why going to gemba is not nearly as useful in engineering. In manufacturing we engage in repetitive actions that raise the value of physical objects. This presents ideal conditions for observation. Anomalies stand out vividly against the homogeneous background of repetition, and physical objects, quite conveniently, are visible. Such perfect conditions for observation do not occur in product development.

In product development observation can lead us astray because our most critical choices are invisible. Consider the real example of lean manufacturing experts “improving” an engineering department. They carefully observed the workplace and discovered that unenlightened engineers placed objects like staplers on their desks in inconsistent ways. They solved this critical problem by drawing stapler-shaped white outlines on the desktops. They focused on the visible because they were unaccustomed a domain where the most important choices are invisible. Instead of studying where engineers located risk in their designs, they studied where engineers located staplers on their desks.

In fact, the Nobel Laureate Daniel Kahneman classifies the tendency to overweight the visible as a cognitive fallacy called, WYSIATI (What you see is all there is.) Kahneman points out that when we observe a situation we construct a mental model based on its most salient features. Our confidence in this mental model is a function of the coherence rather than the strength of the evidence. We will weight a small amount of consistent data much more heavily than a much larger amount of data that contains some noise. It almost never occurs to us that the data that we do not see might be important. Simply put, our brains are wired to think that what we observe is all that is going on.

Unfortunately, in product development the most important information is not observable from your chalk circle. The stuff of product development is not physical objects, but information. The most important choices an engineer makes are invisible. Stare at a printed circuit board from a chalk circle as long as you wish. Now tell me: What design problems did the engineer have to overcome? What alternatives were considered? Which ones were discarded and why? How much margin is there in the design? Where has this margin been allocated? Where is the risk in the schedule? In the performance? My point is that mere observation, while tremendously powerful in manufacturing, is hopelessly inadequate in product development.

Furthermore, observation tells us very little about how we are operating a product development process. How much WIP do we have? Where are the queues in our process? How did we sequence the work of a project? What batch size are we using? It is easy to assess these things when physical objects are involved, but quite difficult to do so when the WIP, queues, and batches consist of invisible information. To develop deep insight into product development we must go beyond observation.

This is not news to experienced product development managers. Consider Bill Hewlett and Dave Packard of HP. Like Ohno, Bill and Dave believed it was critical to go to the place where the work was done. They combined this belief with a deep insight into product development. For decades they used an approach known as management by walking around, (MBWA). It sounds a lot like going to gemba, but it was quite different. In fact, one experienced HP manager pointed out to me that the most important word in MBWA is “managing.” Not going to, not gemba; it is managing. You see, Bill and Dave, who were great design engineers themselves, fully realized that the most important decisions made by design engineers could not be directly observed by merely visiting the workplace. So what did they do? They left the chalk circle. They learned what was going on through active interaction with the engineers. They communicated their goals and values through active interaction with the engineers. They collapsed status differences and created low-risk ways for engineers to express concerns and feelings. And most importantly, by personally modeling these highly functional managerial behaviors they shaped two generations of great technical managers.

Now, there is risk in leaving the chalk circle. Engineers are a ruthless and impolite bunch. Many are quite willing to point out your ignorance and to mock the stupidity of your questions. So, if you are only trying to create the illusion of managerial omniscience, then hiding in the chalk circle will help. I once talked to an HP engineer who was visited in his cubicle by a tall gray-haired gentleman. He said he was surprised by the insightful questions that the man asked, because,”I didn’t think anyone that old knew anything about technology.” He later found out from his manager that his visitor was Dave Packard. Bill and Dave never had to worry about creating an illusion of technical competence; they were the genuine article.

Fortunately, you can practice MBWA without being Bill or Dave. Engineers actually do not expect you to be omniscient. All they really want is a decent chance that you will understand what they are talking about.

So, if product development is your game, don’t think that going to gemba is going to solve your problems – it won’t even identify them. Almost nothing that is truly important is visible in the physical environment of engineering. Critical issues like batch size, overlap of activities, sequencing of tasks, margin in the design, architectural partitioning choices, and risk management strategy are not apparent by observing the physical objects. You would be better off emulating Bill and Dave. Leave the chalk circle and try to be smart about what you do once you are outside it.