Technical people have a bad reputation for being poor communicators. And unfortunately, it's not entirely undeserved. If you ask managers in the finance department about why they think that the IT people they deal with are bad communicators, they point to all the common complaints.
"They speak in impenetrable jargon."
"They don't listen well."
"They don't understand what I'm trying to accomplish."
While these are sometimes valid critiques, the problem often lies elsewhere. Frequently, we do listen well and we do understand what the business wants to do. (OK, the jargon thing is fair.)
The real problem was driven home for me recently at a conference where I was giving a presentation. I came early to hear what some of the other speakers had to say. They clearly articulated lots of interesting ideas. But ultimately, many failed to transmit the key points that they wanted to share.
Why? They simply ran out of time. I was surprised at how consistently the conference managers needed to give presenters the hook in order to keep the day remotely on schedule. After 15 minutes, presenters were still talking about slide No. 4 of 40, and it was clear that we weren't going to get the discussion we really wanted out of the talks.
It wasn't that their information was uninteresting or poorly organized or padded with irrelevant data. The problem was that the more information a presenter wanted to share, the less we in the audience received. The presenters were so enamoured of their own ideas that they couldn't condense them into a form for others to digest. Every detail was so precious that they couldn't part with a single one.
Unfortunately for the audience, that meant that they didn't get much of anything. They were being assaulted with too much information and lost the main ideas in the onslaught.
I've found that this is a common problem, not just on the speaking platform, but in most offices. CEOs dismiss CIOs as being hopelessly mired in details and unsuitable for higher management posts because they can't communicate the core of an issue in a paragraph or less. Clients write off project managers because they can't pull the important message out of the complete picture. Business analysts consider developers hopelessly technical because they won't relate important information in a format that others can use.
As problem solvers, we delude ourselves into thinking that others can't understand anything about a problem without understanding everything about it.
If you'd like to be a better communicator and overcome the too-much-information problem, here are a few things to think about before you open your mouth:
What do you want them to remember from the conversation an hour from now? Managers, clients and subordinates are barraged with information and data all day, every day. Most of it passes through their brains like cars through a freeway interchange. Think carefully about what you want them to recall in an hour. If you were to go back and ask them what the conversation was about, what would you want them to say?
The half-life of information is short. What falls outside of that recollection window may be irrelevant detail that's better left unsaid.
What do you want them to remember from the conversation a week from now? If it's hard to retain information for an hour, think about a whole week.
What do you want your audience members to remember a week after your discussion? Realistically, it will be considerably less than what they will recall after an hour.
What do you want them to do with the information? Most business communication has a purpose beyond just self-expression. Usually, the motive is either calibration -- keeping others informed of progress and approach -- or action. If it's calibration alone, the previous two questions should guide your communication. If you want people to make a decision or take action, tell them what you want them to do. And give them the information they need to carry out that action.
If you want your words to carry more weight, start by cutting down on the number you use. Powerful communicators say more with less rather than less with more.
Paul Glen is the author of the award-winning book Leading Geeks: How to Manage and Lead the People Who Deliver Technology (Jossey-Bass Pfeiffer, 2003)