How IT can communicate more effectively with the business

communication waves people listen hear transmit
Credit: Wesley Fryer via Flickr

You might think you are communicating clearly, but the reality is that business and IT people speak different languages.

You think you are communicating to the business in plain language, but you are not.

Read these next two sentences:

"Kevin Pietersen fell short of the highest-ever score for Surrey when he was left on 355 not out against Leicestershire at The Oval.

They were all out for 557 when last man Matt Dunn was caught behind, denying Pietersen the chance to beat Bobby Abel's unbeaten 357 in 1899."

(For anyone who understands cricket, then try understanding the infield fly rule instead.)

Every word in those two sentences is in English, and yet most native English speakers in the United States can make no sense of them.

Try this one, that you could hear in a project status meeting from your head of development: "We are going to re-factor that part of the code." All English words, but not meaningful outside of IT, so you ask the head of development to try again. You get this: "We are going to improve the internal structure of the module's source code, while preserving its external behavior." (Paraphrased from 

Again, all English words, but not helpful for the non-native IT speaker. The third time is the charm: "We are going to spend the next two weeks simplifying a part of our code so it can be updated more efficiently as your needs change, but we are not going to delay the go-live date." That wasn't so hard now, was it?

Here are some good rules for communicating with your non-IT brethren:

  1. Know your audience. There are a lot of closet-techies out there, so don't assume anyone without IT in his/her title knows nothing, but be prepared that not everyone knows or cares about your jargon. When in doubt, engage the audience to know if they are tracking with you.
  2. If you can, show your materials to someone similar to your audience in advance. If nothing else, just get another set of eyes on them to make sure that the darn spill-chunker, I mean spell-checker, did not "correct" something inadvertently.
  3. Consider the need for acronyms in a presentation to a non-technical audience. Do you need to tell the CEO that you have an MPLS-based network, or does he/she care only that if one network connection breaks there is another network path for your customers to place orders?
  4. Repeat what the jargon means the first time you introduce it. If you are showing an application roadmap, it probably is going to have acronyms on it. But, if you explain the key acronyms as you go, you'll keep your audience with you.

The meaning of the sentences on cricket? As nearly as I can tell, Bobby Abel has been the man to beat for 116 years and counting!

This article is published as part of the IDG Contributor Network. Want to Join?

Drexel and announce Analytics 50 award winners
View Comments
Join the discussion
Be the first to comment on this article. Our Commenting Policies