I’ve just finished a very interesting book about cultural miscommunication, The Spirit Catches You and You Fall Down. It’s a true story about a Hmong family’s young daughter who has epilepsy. The Hmong, if you don’t know their history, were in Laos when the U.S. recruited them to fight against the Communists. The U.S. later brought tens of thousands of them over here to resettle, many of whom ended up in Merced. Their interaction with the medical community there often leaves both sides frustrated.

The Hmong see epilepsy quite differently than we do. While the medical community tries to manage the disease we call epilepsy with an ever-changing regimen of various prescriptions, the illiterate parents in this case are both confused and upset by the medicines. To them, epilepsy is a sign of potentially great healing powers, as many of their shaman have had epilepsy. They view epileptic seizures as a “crossing over” and an ability to communicate with the spirits. Even when they are trying to cooperate, they do not understand what the doctors want them to do. Often, they do understand and choose not to “comply.” They see the medicines, the solution, often as worse than the original problem. The author, Anne Fadiman, does a wonderful job of painting the picture of the collision of these two cultures.

Cultural Blind Spots

It struck me while reading this that cultural blind spots are not limited to people who speak a different language, come from a different country, or have a different religious background—we have huge cultural blind spots between the various job functions in a single company! Marketing “speaks a different language” than engineering, for example. Representatives of each group can sit in a meeting and bandy about various three letter acronyms; they then walk out of a meeting thinking they have each clearly communicated their needs and desires, only to find out later that what they thought they said was not what someone else heard. Business people wanting to have some custom software developed think they are clearly explaining their requirements and business needs, but are horrified when they see the prototype! How could those analysts not understand what they wanted? They had all agreed at the meeting!

Fadiman uses the analogy of that old optical illusion picture: first you see a young woman in the picture, next an old woman. Sit in on some meetings and hear the engineers say “It’s an old woman!” and hear the product management team insist that “It’s a young woman.” They’re both right, from their own viewpoints and cultural biases. How do we learn to be able to see that it is truly both? How do we enhance our communications across these two chasms?

The Patient’s Explanatory Model

To help physicians and other medical personnel understand the patients’ viewpoint of their illness, Arthur Kleinman, a medical anthropologist at Harvard, came up with eight questions to help doctors learn a patient’s “explanatory model,” how they saw the illness and what they expected from the medical profession.

  1. What do you call the problem?
  2. What do you think has caused the problem?
  3. Why do you think it started when it did?
  4. What do you think the sickness does? How does it work?
  5. How severe is the sickness? Will it have a short or long course?
  6. What kind of treatment do you think the patient should receive? What are the most important results you hope he/she receives from this treatment?
  7. What are the chief problems the sickness has caused?
  8. What do you fear most about the sickness?

Discovering the Explanatory Model of the Customer

It struck me that software engineering might do well to come up with its own set of questions designed to elicit an understanding of the customer’s “explanatory model.” In this case, “customer” might be the person paying for the development of custom software or the product management team responsible for defining a new product. Often their view of the problem to be solved will incorporate vastly different images and details than the programmer or analyst can imagine. The questions can also serve to remind the programmer or analyst that there are other potential solutions that may have nothing to do with technology.

Here are a few suggestions:

  1. What do you call the problem? Describe it as clearly as you can.
  2. Has it always been a problem or did something in your environment change?
  3. Have you attempted to solve it in other ways? What did/did not work?
  4. How big a problem is this for you? How much is it worth to you to resolve?
  5. What kind of solution do you think would be effective?
  6. What are the most important results you hope to receive from this solution?
  7. Can the problem be divided into prioritized chunks, so we can solve one piece at at time?
  8. What does this problem cause? (What are the effects of this problem?)
  9. What do you fear most about not solving the problem?
  10. How will things be different when this problem is solved?