Skillful Questioning, Part 2

Let’s continue describing a truly invaluable way of gaining clarity by challenging vague language (started in Part 1, which introduced the “meta-model”). In any context, but especially when interviewing people while troubleshooting, getting the right information about the problem at hand is critical to correctly directing your efforts.

I used to play a little game when I was learning the various parts of the meta-model. Each week, I would focus on one of the meta-model’s language patterns and score one point whenever I observed someone making a statement that included the pattern. A few times, I got so excited that I would blurt out “unnnnnnspecified nouuuuuuuuuuun!” or “moooooodal operator of possibility!” and do a little victory dance. Judging by the look on people’s faces, I don’t recommend this. I forgot the words of the master:

Let your workings remain a mystery.
Just show people the results.

Tao Te Ching (verse 36) ¹

So, go ahead and play the meta-model game all you want, but win silently. Anyway, let’s finish the list of meta-model language patterns (from Introducing NLP by Joseph O’Connor and John Seymour) and see how they apply to troubleshooting.

Modal Operators Of Possibility

Modal Operators of Possibility – “I can’t” – are clarified by asking: “What would happen if you did…?” or, “What prevents you…?”

Joseph O’Connor & John Seymour, Introducing NLP ²

Modal operators of possibility are statements concerning what is possible: they are words like “can,” “cannot,” “possible,” and “impossible.” But, they’re just words! As such, they may or may not reflect the real world. As a troubleshooter, don’t get sucked into someone else’s reality and accept their ideas about what is possible or not possible without proof (see the virtue of skepticism for more on this topic). Especially on the “not possible” side of the ledger, you’ll frequently encounter people who are locked into the well-rehearsed sequence of their workflow. Noting someone’s routine is fine but remember that effective troubleshooting frequently requires deviating from the “official script” (for example, by changing the order in which things happen).

• “I cannot get the engine to start.”

These words about possibilities, like the universal quantifiers discussed below, also don’t allow for exceptions. Someone who says they “cannot” do something, or for whom a task is “impossible,” is using language that is constraining and final. By the way, I’m not saying that you can overcome an actual, respect-the-laws-of-physics type of limitation simply by asking a clever question. The person who says they “can’t” may very well be right about what is possible. However, if they are being held back simply by the way they’re framing the problem, you can help them get unstuck by throwing a jarring question into the mix.

The way to counter modal operators of possibility is to say “Show me!” and ask, “What would happen if you did?” This simple question is all it takes to pierce these limiting beliefs and get the mind working on alternatives.

• “What is stopping you from starting the engine?”

Modal Operators Of Necessity

Modal Operators of Necessity – “I mustn’t/I have to” – are clarified by asking: “What would happen if you did/didn’t…?”

Joseph O’Connor & John Seymour, Introducing NLP ²

Modal operators of necessity concern needs and involve words like “should,” “must,” “ought,” and their negations: “should not,” “must not,” and “ought not.” Like the modal operators of possibility, these words involve presuppositions that may not be helpful or true. They also hint at a rule or procedure being followed, but only indirectly. You want to bring these implicit assumptions out into the open for examination.

• “You should turn on the backup battery before engaging the ignition.”

Frequently, you will discover that the person has no better justification for their actions than “that’s what I was told to do” or “that’s the way I’ve always done it.” The backup battery is always turned on before you engage the ignition because…the manual says there will be an explosion if you don’t? A leprechaun told you to do it that way? Again, successful troubleshooting often requires straying from the well-trod path, so you should keep in mind that the “way we’ve always done it” is not necessarily the only way to do it.

• “What will happen if you didn’t turn on the backup battery before engaging the ignition?”

Universal Quantifiers

Universal Quantifiers are questioned by asking for a counter example: “Has there ever been a time when…?”

Joseph O’Connor & John Seymour, Introducing NLP ²

Humans like to generalize: it’s faster, easier, and makes you sound confident. To a troubleshooter, however, exceptions will frequently point the way to a solution. When you hear words like “all,” “every,” “always,” “never,” or “none,” recognize that someone might be generalizing. Universal quantifiers like these allow no room for exceptions. If they are true, that’s good to know. If not, you’ll want to understand the exceptions.

• “This stupid thing never works!”

To unravel a universal quantifier, ask for an exception. In this case: “Has there ever been a time when…that stupid thing worked?”

Operational data is another effective way to contradict universal quantifiers. Take a statement like: “The temperature in the warehouse has never exceeded 82 degrees in the month July.” If you had a graph or table showing the recorded temperature during that time period, you could easily see if this universal, no-exceptions-allowed statement is true or false.

I hear universal quantifiers all the time when asked to help fix problems. People like to exaggerate and, particularly if they’re angry that something is broken, they can really lay it on thick with words like “never” and “always.”

Complex Equivalence

Complex Equivalences can be questioned by asking: “How does this mean that?”

Joseph O’Connor & John Seymour, Introducing NLP ²

Linking two statements together to mean the same thing is called a “complex equivalence”; the speaker is leading you (perhaps unintentionally) to make an association between two things. But is the connection real?

• “The workers are taking a break. The assembly line is stopped.”

When it comes to troubleshooting, never underestimate the ability of people to jump to conclusions. Worse yet, you may attempt to fill in the blanks and reach false conclusions all by yourself (even if the speaker wasn’t making that leap). The mind loves to fill in missing gaps with its own interpretations! In this example, it may be true that the assembly line is stopped and the workers are taking a break. But, that doesn’t necessarily mean that one caused the other. The assembly line could be idle because of a work break, but it could also be the other way around: perhaps the workers are taking it easy because the assembly line is broken.

• “How does the workers taking a break mean the assembly line is stopped?”

Presuppositions

Presuppositions can be brought into the open by asking: “What leads you to believe that…?” and filling in the presupposition.

Joseph O’Connor & John Seymour, Introducing NLP ²

Making your way in this world demands reliance on beliefs and expectations. For example, imagine the paralyzing fear you would experience if you didn’t simply trust in the Law of Gravity. It’s much easier and less stressful to assume that gravity will behave like you expect. Unlike our experience of gravity, other beliefs we hold are highly contextual (i.e., they’re only true in certain cases) or, sorry to be the bearer of bad news, they’re simply false.

There’s nothing wrong with presuppositions per se as they are essential to life. But, if you’ve been called in to fix something, it’s likely that someone’s expectations have been violated (unless, of course the expectation is that all machines eventually break down—now that’s a very healthy belief!). Therefore, detecting false presuppositions are critical to your success as a troubleshooter. Words and phrases typically associated with presuppositions are: “since,” “when,” “if,” “realize,” “be aware,” “ignore,” and suggestive questions beginning with “why.”

• Statement: “When this gauge reads 100 lbs./sq. in. of pressure, then turn the release valve.” → Presupposition: waiting for 100 lbs. of pressure to build is needed before turning the release valve.
• Statement: “Why are you trying to wreck the motor?” → Presupposition: I’m wrecking the motor. And, I’m doing it intentionally!
• Statement: “Ignore the green wire. Are you going to cut the blue wire or the red wire to defuse the bomb?” → Presupposition: I must choose either the blue or red wire, as opposed to doing something else to stop the countdown timer. FYI, always choose the red wire.
• Statement: “Be aware of the fuel tank reading.” → Presupposition: the fuel tank reading is accurate and important.

Cause And Effect

Cause and Effect can be questioned by asking: “How exactly does this cause that?” or “What would have to happen for this not to be caused by that?”

Joseph O’Connor & John Seymour, Introducing NLP ²

Cause and effect is a powerful way of explaining our world. If A causes B, then you’ve found the lever to prevent B, or make sure it happens all the time, depending on whether B is a good or bad thing!

• Statement: “The car would have started, but the battery was low.” → Cause/effect assumption: the depleted battery was the sole reason the car wouldn’t start.
• Statement: “The contamination resulted from a leak in Tank #12.” → Cause/effect assumption: the only source of contamination was from Tank #12, and the leak caused it.
• Statement: “An abnormally high number of database operations used up all available memory, making the server unresponsive.” → Cause/effect assumption: the database used up all the memory and the server crashed because of it.

With respect to problem reports, “cause and effect” statements are a Big Deal. You’ll want to thoroughly investigate them because, subconsciously, you will be drawn to them like Germany to David Hasselhoff. You won’t be able to look away! If you’re not on guard, these statements will burrow their way into your head and take over the troubleshooting process, leading you on the proverbial “wild goose chase.”

Before that happens, step back and ask some skillful questions:

• “How does this one thing cause the other?”: This may reveal new possibilities of causation, especially if coupled with the question “What would it take for A to not cause B?”
• “Would you please describe the process that makes A cause B?”: The details revealed here may show a weak link (or, none at all!) between A and B. Additional contributing factors may also be uncovered.
• “Has there ever been a situation where A didn’t cause B?”: If you can point to a situation with the same cause but not the same effect, there may more to the story than a simple A → B explanation.

Mind Reading

Mind Reading is questioned by asking: “How exactly do you know…?”

Joseph O’Connor & John Seymour, Introducing NLP ²

Presuming to know what someone else is thinking or feeling can be filed under the category of “mind reading.”

• “Jim doesn’t care about the malfunction and won’t know how to help us…”

In the context of troubleshooting, you may encounter this type of heroic extrapolation when brainstorming a list of people who could help you out. However, don’t back down and pass over a potential ally without first questioning why. You may hear all kinds of weird reasons why you shouldn’t contact the one person who can fix your problem!

• “How exactly do you know that Jim won’t help us?”

Conclusion

We all have different models of the world that are reflected in the language we use. The meta-model gives you insight into those differences. By assuming you don’t know exactly what a person’s words mean, you can dig deeper for the precision that’s so often needed when troubleshooting.

References:

• Header image: Bain News Service, P. Tom Gibbons interviewed. [No Date Recorded on Caption Card] [Photograph] Retrieved from the Library of Congress, https://www.loc.gov/item/2014716240/.
• ¹ Lao Tzu and Stephen Mitchell, Tao Te Ching: An Illustrated Journey (New York: HarperCollins, 1999), verse 36.
• ² Joseph O’Connor and John Seymour, Introducing NLP  (London: Thorsons/HarperCollins, 1990), pgs. 97, 99, 101, 102, 104, 105.