If there’s an engineer in your life you already know the soul numbing frustration that comes from trying to describe a problem to an engineer. My poor Wife has suffered through this so many times she’s become a computer expert in self defense.

Why is it so hard to work with us? We’re smart, intuitive and seldom have problems assembling kits but the difficulties of describing a problem to me has caused my Wife to consider how well I would survive on a diet consisting only of Brussel sprouts.

Let me give you an example. I hear my Wife say, “Byron, my computer isn’t working.” Now anything she says after this statement is wasted effort. In fact, I tend to regard it as a distraction.

I’m already evaluating possible contributors. For the computer to stop working, it has to be the power supply, video card, monitor or motherboard. Each of those items has a different method of testing to isolate the problem. Here’s where I start asking pointed questions designed to isolate the faulty component in the order of highest probability.

Normally this is where I encounter my first signs of discord. Invariably one of my questions involves information she gave me after she told me she had a problem. The problem is I never heard a thing she said when I started my analysis. She interprets this as me ignoring her. Well, maybe, but not the way she chooses to interpret it.

Engineers also run through a list of similar problems in search for commonality. Halfway through my list, I have a match. Unfortunately for me, I recognize this from last week. Maybe the computer is still working and her statement does not accurately describe the problem.

Pause analysis, “What’s not working?”

“It won’t let me delete this file”

Oops, reset analysis. That’s a totally different fault tree but now I’m annoyed because she was misleading in her description and I’ve wasted the previous analysis time. The fact that it only took me thirty seconds and I was playing a video game at the time has no bearing. This is my wife, she’s certainly smart enough to use precise language.

She’s annoyed because I ignored all the supplemental information she was giving me. Of course I ignored it, I’m following a decision tree and her supplemental data is not only useless it’s distracting. Fortunately, I’ve learned that expressing this opinion only increases her frustration.

Over many years I’ve learned that her silence at this point in not her awe at my superior troubleshooting skills. This is the time she carefully considers how many forms of Brussel sprouts she can feed me over the next two weeks. That and wondering if any jury in the world would convict her of homicide if she told them I was an engineer. It’s a close call.

See the problem? Ignore that question, the fact that you’re still reading this post says you’re lived through this discussion.

How did this go so wrong? We both have similar goals. She wants to delete the file and I want to impress her by showing off my incredible computer skills and get back to my game.

Contrary to the methods that Sherlock Holmes seems to use, we don’t throw all possible clues into a hat, shake it up and pull out an answer. Being engineers, we follow a process.

• Establish the problem statement. e. for Sherlock Holmes, is that really a dead body and how were they killed?
• Develop a fault tree of possible suspects. Who had opportunity and motive?
• Run experiments to eliminate each suspect. Question suspects until we find one with a bad alibi. Don’t assume a bad alibi is proof of guilt.
• Repeat until we have an answer

I have no idea how this happens but once it’s decided we will be engineers, this process becomes ingrained into the way we think and resolve problems.

Going back to where we started. When you describe a problem to an engineer, use precise terms. Not working is completely different than not functioning correctly. It frustrates us as much as we frustrate you when we have to ask a string of questions to get to the failing symptom.

Let us establish the problem statement, don’t continue to add information you think is pertinent. That information belongs in the next phase and you’ll only have to repeat it later if it is pertinent. It’s not personal that I’m ignoring your helpful observations.

I’m sure you’ve already noticed that all my helpful suggestions are designed to modify your behavior. No, I won’t try to convince you I have no fault here. I should take my time before jumping into the problem solving phase. I should, but we wouldn’t be having this conversation if I could. I’ve learned to pretend I’m still listening while formulating the problem statement but I think my Wife is starting to realize that my hearing isn’t that bad.

We’re engineers and this trait is an essential element of who we are. You’re unlikely to change us but you can make it easier for both of us by understanding how we’re driven by this simple process.

© 2016 – 2019, Byron Seastrunk. All rights reserved.