Beauty

Beauty

Friday, March 13, 2015

Be an Engineer Who CAN Communicate

We've all heard it, how we engineers can't communicate with non-engineers. We're just a bunch of nerds that want to sit in our cubes and geek out about some new tech.  It's a stereotype to be sure, but I'm pretty sure we've all met someone who seemed to have spawned the stereotype.  Maybe we all do a little.  The other day I was at a meeting in my community and someone was announcing which radio channel we'd use in an emergency.  Concerned that not all radios might be capable of receiving that channel, I turned to a leader near me and asked which band of frequencies the channel was in.  He replied "It's like you're speaking English to me, but I can't understand what you're saying."

Over the course of my career so far, I've encountered many brilliant engineers who are excellent communicators, and many who aren't.  I've also encountered some not so brilliant...never mind.  The point is that not all engineers stink at communicating.  Yesterday I attended a camp for a software product our company is starting to use.  The day was filled with presentations from both the vendor and guest speakers regaling us with tales of their success using the product.  The keynote speaker showed his public speaking chops.  His slides were simple and he incorporated examples to which we could all relate.  At the end of his presentation his point was abundantly clear.  Near the end of the day another speaker got up to show how his company had used the product.  Out came acronym soup and an enthusiasm literally brimming over, but little clarity.  I mentally checked out of the briefing within about five minutes and started looking at my phone while trying to appear to pay attention by looking up at the speaker occasionally (don't judge, you know you've done it).  So I ask myself, "Why do some engineers leave us either bored or overwhelmed, while others leave everyone in the room feeling smarter?"

All of us are a bundle of ideas and stuff we've learned, opinions and biases.  The experiences we have shape our frame of reference or point of view.  A point of view that few share, as it is unique to us.  But often when we want to communicate, out comes a stream of consciousness from our frame of reference that literally just finds no receiver on the other end.  It's useful to think of a frame of reference as an antenna.  If the sender and the receiver are not tuned the same way, the signal may well be transmitted, but nobody's listening.  You can turn up the power on the transmitter all you want, but if the receiver isn't tuned right, it matters not.

When it comes to communicating we have to take a step back and remind ourselves what it really means to communicate.  It means that the idea in my head goes over and plants itself in your head, preferably with the appropriate context.  You don't have to agree with it, but you do need to understand it and how I see it in order for me to claim success in communicating.  With that in mind, any time we set out to communicate we need to understand that the goal is to transfer the idea, rather than many of the other things that end up happening.  Success criteria is: the idea in my head is now also in your head, reasonably intact and in context of my frame of reference and yours.

Have you ever had someone who is just amazingly smart say a bunch of stuff that was way over your head?  You don't understand a flipping thing, but (after smiling and nodding as if you do) you come away saying "That guy/gal is really smart".  Yes, they probably are really smart, but did their idea get into your head?  Nope.  Fail.  That's the same thing that happens when you talk over somebody's head.  They may think you are really smart afterward, and it may make you feel good that you're the smartest person in the room, but you failed to communicate, which sort of means you aren't the smartest person in the room.

So what to do about this?  Only hang out with techies so we can always feel comfortable and tell jokes that no one else understands?  There is an admitted charm to the fraternal association with people having similar frames of reference.  But, while it is comfy to hang out with our brilliant friends, we still need to talk to other people, especially the ones who pay us to be smart.

It is useful when preparing to communicate, through any medium, to ask ourselves what idea we really want to get across.  People only tend to remember one or two things, especially in technical communication.  Therefore, it is very helpful for you to know what you want those one or two things to be and then shape the content of your message to funnel them toward those core ideas.  Once you've determined what you want most to communicate, it's time to start tuning the frame of reference so that you are transmitting the idea in a way that will resonate with your audience.  The most effective communicators take the time to understand their audience's frame of reference and tune their message as closely to it as possible.  You want to make it easy for them to understand what you are saying.  You can't expect them to have your exact background or just know what you mean.  You need to take the time to carefully plan out how to say things in a way that will make sense to them.

None of us have the exact same frame of reference.  And none of us are capable of fully understanding and tuning exactly to someone else.  But we can get close enough.  Sometimes when we need to explain something complex, we start to tune in the audience's frame of reference and we realize that they simply don't have the background to understand the idea we want to put in their head without additional knowledge that they don't currently have.  At this point we have a choice, we can just blast them with the data and hope for the best, we can attempt to teach them some of what they need to know for the idea to make sense, or we can simplify the idea and frame it into an example they will understand.  Option number one is good if you want everyone to think you are smart, but you don't care about communicating.  Rarely the right option.  Option two works if the amount of background needed to tune the audience's frame of reference to yours is relatively small.  Option three is usually the best option.

Remember that the goal is to get the idea from your head to theirs.  Getting it there in a simplified form is far better than getting nothing there, or worse a garbled and misunderstood complex version.  Does it really matter if your customer's program manager fully understands how you instantiated a class or the exact composition of the material you used?  If it does, it's likely your customer will have someone present who actually understands that level of detail.  But if that level of detail isn't necessary, why on earth would anyone attempt to explain it to the uninitiated? Take it up a level or three and explain it like a story about how this web service talks to another one to ask it a question, and then what it does when it gets the answer.  (I'm not advocating sock puppets or anything insulting like that, just a nice simple discussion of functional flow).  Your customer will walk away with a warm fuzzy because they know your system does what they want it to do and at some level they get how it does it.  How much better is that than having them walk away with no idea whether the system actually does what they want but uneasily hoping that all that techno-babble means you're super smart and know what you're doing.  The warm fuzzy and the basic understanding is far better.

I've seen engineers attempts to wax eloquent or look super smart turn into total disasters because the customer misunderstood what they were saying.  I've seen attempts at flippant humor completely disintegrate the customer's confidence in the vendor.  And I've seen nice and simple briefings with straightforward explanations keep millions of dollars of business sold because the customer actually understood what was going on in their own frame of reference.

So the next time you are called upon to communicate with someone, whether it's a hallway conversation, a whitepaper, or a heavy duty design review, stop for a second and ask yourself "what do I want this person to know and remember when I'm done?"  Once you're sure about that, start to tune into their frame of reference and put it into a context they will understand and with which they can relate.  Do that simple exercise consistently and you will be amazed at how well you can communicate, even if you are an engineer.

Once you try it out let me know how it works.  If you have your tips for being an engineer that can communicate, I'd love to hear them.

No comments:

Post a Comment