The following principles further flesh out how to diagnose well.
a. Ask yourself: “Who should do what differently?”
I often hear people complaining about a particular outcome without attempting to understand the machine that caused it. In many cases, these complaints come from people who are seeing the cons of some decisions but not the pros and don’t know how the Responsible Party weighed them to come to a decision. Since all outcomes ultimately come from people and designs, ask yourself “Who should do what differently?” will point you in the direction of the kind of understanding that you need to actually change outcomes in the future (versus just chirping about them).
b. Identify at which step in the 5-Step Process the failure occurred.
If a person is chronically failing, it is due to a lack of training or a lack of ability. Which is it? At which of the five steps did the person fail? Different steps require different abilities and if you can identify which abilities are lacking, you’ll go a long way toward diagnosing the problem.
c. Identify the principles that were violated.
Identify which principles apply to the case at hand, review them, and see if they would have helped. Think for yourself which principles are best for handling similar cases. This will help solve not only this problem but other problems like it.
d. Avoid Monday morning quarterbacking.
Evaluate the merits of a past decision based not on what you know now but only on what you could have reasonably known at the time the decision was made. Every decision has pros and cons; you can’t evaluate choices in retrospect without the appropriate context. Do this by asking yourslef, “What should a quality person have known and done in that situation?” Also, have a deep understanding of the person who made the decision (how they think, the type of person they are, whether they learned from the situation, and so on).
e. Don’t confuse the quality of someone’s circumstances with the quality of their approach to dealing with the circumstances.
One can be good and the other can be bad, and it’s easy to confuse which is which. Such confusion is especially common in organizations that are doing new things and evolving fast but heaven’t yet gotten the kinks out.
I have always described Bridgewater as being “terrible and terrific at the same time.” For nearly forty years, we have consistently produced extraordinary results while struggling with lots of problems. It is easy to look at messy circumstances, think things must be terrible, and get frustrated. But the real challenge is to look at the long-term successes these messy circumstances have produced and understand how essential they are to the evolutionary process of innovation.
f. Identifying the fact that someone else doesn’t know what to do doesn’t mean that you know what to do.
It’s one thing to point out a problem; it’s another to have an accurate diagnosis and a quality solution. As described earlier, the litmus test for a good problem solver is 1) they are able to logically describe how to handle the problem and 2) they have successfully solved similar problems in the past.
g. Remember that a root cause is not an action but a reason.
Root cause are described in adjectives, not verbs, so keep asking “why” to get at them. Since most things are done or not done because someone decided to do them or not do them in a certain way, most root causes can be traced to specific people who have specific patterns of behavior. Of course, a normally reliable person can make the occasional error and if that’s the case, then it can be forgiven, but when a problem is attributable to a person, you have to ask why they made the mistake—and you have to be as accurate in diagnosing a fault in a person as you would be if he or she were a piece of equipment.
A root cause discovery process might proceed like this:
The problem was due to bad programming.
Why was there bad programming?
Because Harry programmed it badly.
Why did Harry program it badly?
Because he wasn’t well trained and because he was in a rush.
Why wasn’t he well trained?
Did his manager know that he wasn’t well trained and let him do the job anyway, or did he not know?
Consider how personal the questioning is. It doesn’t stop at “Because Harry programmed it badly.” You must go deeper in order to understand what about the people and/or the design led to the failure. This is difficult for both the diagnoser and the RPs, and it often results in people bringing up all kinds of irrelevant details. Be on your guard because people will often look to cover themselves by diving into the weeds.
h. To distinguish between a capacity issue and a capability issue, imagine how the person would perform at that particular function if they had ample capacity.
Think back on how the person performed in similar functions when they had ample capacity. If the same kinds of problems came up, then the problem is very likely one of capabilities.
i. Keep in mind that managers usually fail or fall short of their goals for one (or more) of five reasons.
- They are too distant.
- They have problems perceiving bad quality.
- They have lost sight of how bad things have become because they have gotten used to it.
- They have such high pride in their work (or such large egos) that they can’t bear to admit they are unable to solve their own problems.
- They fear adverse consequences from admitting failure.
[ <= check the previous post]
* Source: Principles by Ray Dalio