Screaming Circuits: Communicating Up and Sideways - For the Engineer Entrepreneur


Communicating Up and Sideways - For the Engineer Entrepreneur

A good leader should communicate in the language of his or her subordinates. A good leader should be the one to adjust dialect and language. This is well accepted wisdom. The problem is that “should” is a rather meaningless word. “Should” doesn’t require, nor does it instruct. “Should” implies obligation, but doesn’t imply action or consequence of not taking action.

Expecting a superior or colleague to speak in your language only ensures that you “should” be able to communicate, not that you will. Relying on “should” is a lot like relying on luck. You give up control when you rely on luck or “should.” It’s fine if you don’t care, but not if you do.

It shouldn’t be a surprise that effective communication is a vital part of surviving and advancing in the business world. Without it, no one knows what you do or what your worth is to them.

In this context, “shouldn’t” is an appropriate word. The usage here is that the argument is common enough knowledge that it’s reasonable to assume that a reasonable person would agree. It doesn’t imply, nor need to imply any action or consequence.

Graphs and charts

This isn’t an article about “managing your boss. I’ve seen enough of those, and have always thought them rather presumptuous. “Managing your boss” is really more manipulation and exploitation than it is about managing, and I’m not at all a fan of manipulation. What you can do, and will benefit from, though, is to manage the communications with your boss and co-workers.

It’s great if you have a boss that knows how to communicate well. Not everyone does, and even for those that do, it can be pretty helpful to share the job of effectively communicating.

One of the easiest illustrations is in the contrast between a visual person and a numbers person. The numbers person needs to see metrics in spreadsheet or table form. The visual person needs the same information in chart and graph format. Trying to get one to accept the other often results in little or no actual communication and lots of frustration.

If your boss is a visual person, and you hand in a table with all of the data, plus rows and columns of only distantly related numbers, they will have a hard time with it. Their brain wants to be able see structures at a glance. Instead, you’ve given them a jumbled mess of indistinguishable black and white hieroglyphs.

On the other side, if you give your numbers-person boss a nice bar chart, they will see a bunch of fluffy colors that do little more than obscure the details. They need to see not only the numbers they’re interested, but also the data behind the numbers.

But shouldn’t a good leader be the one adjusting language, you ask? Again, I’ll compare the word “shouldn’t” in this context to luck.

Good leaders do adjust their language, and listen carefully. They are putting in the effort, and what you are trying to say is (presumably) important. Why would you not do as much as you can to complement their effort? Good leaders have also hired you, in part, for your communications skills. Assuming the leader will do the majority of the work is doing them a disservice and is a failure to live up to your commitment as an employee.

The same holds when dealing with colleagues you don’t report to. It may seem like you’re partly doing their job if you adjust your communication to fit their style, but if your message is important enough to give, it’s important enough to justify the extra work toward clarity for your recipient. Ideally both parties are doing it so that misses by one will be more likely to be covered by the other.

A good example would be in the use of acronyms and jargon with (or as) a new coworker. Communications problems happen quite often when one person has a background from a large, tightly structured company, and the other is from a smaller, more cowboy like, company.

Jane joins a small start-up company from a large multi-national corporation. Her former company spent a lot of time studying lean manufacturing, the Toyota Production System, and other process improvement systems. Bob at the small company doesn’t have the same language.

Jane is aghast when she suggests “Poka-yoking” a process and Bob doesn’t understand her. She drops her jaw and wonders what kind of a mess she got herself into when she took the job. She’s surrounded by bozos that don’t know the most basic of business processes.

Poka-yoke is a term used in the Toyota Production System. (Wikipedia entry here) It sounds like a rather exotic process, but it just means to make a product or system mistake proof. If a plug would damage a piece of equipment when plugged in backwards, key the plug so it can’t be plugged in backwards. Just design in some mistake proofing. It’s as simple as that.

In this scenario, it turns out that Bob is a brilliant user experience designer and considers mistake proofing to be just about the most important aspect of a design. Jane and Bob are on the same page; they both strongly believe in mistake proofing products. However, since Jane didn’t take into consideration the possibility that Bob might not have been exposed to that one specific set of business terms, she feels he must be incompetent. Both Jane and Bob would be well served to accommodate the language of the other.

I’ve found, over my career, that there are an astounding number of terminology differences between different corporate cultures. There are terms that have different meaning altogether, and there are different terms used to describe the same thing. Even the basics like “margin” can be used differently in different organizations.

Jargon and acronyms are okay, as long as you never assume that the person you’re communicating with has the same jargon dictionary in their head as you do.

Duane Benson
"I like both of him and he like both of me, because I live in a split level head"
          - Napoleon the 14th


Post a comment

If you have a TypeKey or TypePad account, please Sign In.

« Electronics Manufacturing Files - What We Need | Main | Five traps to avoid when changing from hand assembly to machine assembly »