Clarify. Verify. Quantify.

Posted on September 30, 2014

0


Lion

This is the trilogy that new engineers (and sometimes old ones!) forget to follow when dealing with customers who bring up problems with the products they are working on.

I’ve seen three ranges of responses to a customer comment/request:

  • The eager puppy. This is the engineer who translates a passing comment from a customer like “huh, this feels funny” into a serious problem that needs to be addressed right away.
  • The camel. This is the engineer who always goes “humph! you’ll have to live with it” to customers.
  • The lion. This is the engineer who bites the head off any customer who asks for anything.

The eager puppy, while trying to be helpful, sometimes fixes things that aren’t really broken.

The camel often says no, because of a false idea that their word is God. It has been reinforced with years of customers treating their word as gospel and often saying, “Oh, thanks anyway (you’re so smart).” But the camel worked so hard just to get to this point in the project, that it’s burned out and can’t think of how to solve the problem.

The lion often is also just as tired of the project, but is a bit more aggressive in response. Sometimes this aggression actually comes from insecurity: the lion just doesn’t know how to meet the customer’s request–or the work required is just too much to contemplate. The lion’s philosophy is that a good offense is the best defense. That’s why the lion punctuates an emphatic, “NO, we’re not doing that” with rants about the request being stupid, expensive, or not possible in this time frame.

It’s important in times like this is to clarify, verify, and quantify:

  • It’s important to clarify that there actually is a problem before bending over backwards to fix it.
  • Then it’s important to verify it actually is a problem. Can you, under the described conditions reproduce and observe the same problem? If you can’t reproduce the problem, you won’t know if you fixed it.
  • Finally, when you know there is a problem, and you know the conditions needed to create the problem, then you need to quantify the problem. This means you need to determine how serious the problem is… put some numbers on it… Is the jiggle inches in range? 10ths of inches? 100ths of inches? Is it on the order of seconds slow for under 100 pieces of data?

After you have clarified, verified, and quantified the problem, you can come up with possible solutions. Likely (since you are an engineer), you will have determined what each solution will “cost” something different in terms of time, money, or risk/chance of success. If there’s an easy, quick, guaranteed solution, then you can usually just do it, but if there are trade offs, you should bring it up to “the powers that be” — your manager or, with his or her blessing, sometimes the customer.

When you do present the possible solutions, your clarification, verification, and quantification of the problem will help the customer understand or determine if the problem is serious. For example, if the problem only happens under weird, unlikely conditions, the customer may say don’t bother fixing. On the other hand, if the results will be catastrophically dangerous (even though unlikely), it may be worth investigating possible solutions.

Remember, as an engineer, you owe your customers the clarity of logical facts so they can make well-informed decisions.

Advertisements