Last week when I described my current systems engineer position as being all about communications, I almost lost my wife to uncontrollable laughter. When she finally recovered, all she said, while still trying to catch her breath was, “how do you stay employed?”

She has a point.  If you have an engineer in your life, you are throughly on her side. If you don’t have an engineering background, trying to talk with an engineer is not for the easily discouraged. At times you felt it would be easier to drive down the highway at rush hour, blindfolded, with someone shouting instructions at you from the back of the vehicle than it is to talk with an engineer. You’re probably right but in the spirit of a new year, I want to offer a few simple guidelines that can make the discussion far less frustrating than both of you have come to expect.

As always, I’ll give my standard disclaimer, I can only speak for myself. This is what works for me. I can’t guarantee success but I’m willing to bet it will reduce that urge to tie your engineer to an ant bed until he or she admits they are deliberately being obtuse.

Let’s start with a little trust and say that your engineer also wants to eliminate your frustration. Granted, there are times we will be deliberately obtuse but usually we’re just as frustrated as you are.

It should be simple, the person in front of you is capable of doing complex math in their head and here they are giving you a blank look, like you just started speaking High Elvish.   Or worse, they’ve already taken action on what they thought you said and based on the results, you may as well have been speaking High Elvish.

All of us, even you, tend to interpret spoken words into concepts we’re familiar with. When you tell me you want milk, you already know what kind, and what your store has on its shelves. You don’t worry about the expiration date because you automatically check it. Who buys expired milk anyway?

Whole, half and half, two percent, buttermilk and even powdered milk, all of those come under the heading of milk and your engineer has no clue (I used to think buttermilk would taste great, until I tasted it). With no additional guidance, your engineer will probably come home with powdered milk. Lower cost, easy packaging, no need for refrigeration and much longer expiration date. To him, this exceeds all the requirements given to him.

Yes, he will only make that mistake once but you’re making matters worse. Now, when you send him after rice, he’s paralyzed by the number of choices. If you thought ahead and sent him with a picture of the box, you had better hope the manufacturer did not change packaging. The experience with the milk suggests it’s better to come back empty handed.

The more proactive of you will suggest taking your engineer on several shopping trips before letting him go on his own. It’s a very good plan and works well on anyone but an engineer. Your engineer is far more interested in the traffic flow of the shop, why the shopping cart wheel is squeaking and what techniques did they use to handle the pickle jar (those little divots in the bottom of the jar are not there for decoration).

Let’s look as a few simple guidelines. I know they appear to have limited utility but you might be surprised how much these guidelines will reduce your frustration.

First – Let the engineer know what matters to you. Don’t hint, don’t assume they already know, don’t assume they will ask. Remember the powdered milk, it met all the requirements but you never considered powdered. We don’t get insulted when you put it in the form of requirements.

Second – Don’t assume we were listening. The modern workplace forces all of us to multitask. I can tell you without shame that I’m extraordinarily bad at multitasking but years of work have allowed me to appear very competent at it. I know it’s a solution but don’t ask us to repeat everything you said, that’s insulting. A better tactic involves picking one of the minor details and ask for clarification. For example you might ask, “Did I say dill or bread and butter pickles?” If I answer correctly then I was probably listening.

Third – Stay focused. Don’t go into details that aren’t important to you. Unless you have a particularly interesting design problem, odds are we’re only paying partial attention. It’s nothing personal but you can’t compete with a compelling problem, don’t try. Saying too much allows our attention to wander. For that matter, when you say “uh” or “umm” to collect your thoughts, it allows our attention to wander. The moment I hear “um”, my mind tries to take advantage of that dead time. Before your next word registers, I’m already working on my next post.

Fourth – If we ask a question, answer the question that was asked. Don’t keep adding more information. I know that you think we’re communicating but I’m building a problem statement in my head and filling in details. Giving us details we didn’t ask for only forces us to restructure the problem statement.

Fifth – When you get the blank stare and if you spend any time with engineers, you know what I mean, it doesn’t always mean we think you’re an idiot, so don’t babble like one. Maybe we just solved the unified field theory or realized why our bank balance was off by 53 cents. Give us time to come back to you. On the other hand, if we take longer than a few minutes, you may have to recapture our attention.

On a more personal issue, since I relate to the things I’m familiar with, I tend to view conversation between two or more people in terms of computer protocols. A fast review of these protocols shows two typical modes; a message exchange where only one computer at a time is talking and a broadcast mode where both computers are talking at the same time.

The choice of these two modes is usually based on the value of information. The broadcast mode does not allow for verification of the messages and usually involves high repetition of the information in order to ensure the message gets received. The other mode allows for verification of the message exchange through an acknowledgment in the form of a response.

After listening to my Wife and Mother-in-law converse in broadcast mode, I’ve come to realize that people tend to use the protocol they were raised with. When I talk to my wife using a simplex mode and she’s using broadcast mode there’s usually some amount of frustration. She keeps broadcasting because I’m not saying anything and I’m staying silent until her message ends.

Make sure both of you are using the same protocol. If the discussion is important, I highly recommend the simplex method. It allows for acknowledgement of the message and encourages a response based on the content of the previous message. On the other hand, if you like the sound of your own voice, by all means use the broadcast mode. I’m probably not listening but that’s why you keep repeating your message. I’ll point out that this blog is a form of broadcast until you post a comment.

So far I’ve only covered two issues, how to send your engineer to the store and how to discuss a problem. The techniques described here will work in other situations but you need to get comfortable with the basics first. Let me know how it comes out.

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