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 agilealliance.org.) 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: 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. 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. 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? 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! Related content opinion Bad beginnings have bad endings If you get off to a bad start on a project, you may never be able to recover. By Paul T. Cottey Oct 03, 2019 6 mins IT Strategy IT Leadership opinion How was your telecation? The point of a vacation is not to work less, but to not work. By Paul T. Cottey Jul 08, 2019 5 mins IT Leadership opinion There's a new sheriff in town The challenge as a senior IT leader in an M&A situation is that the new operating rules are unlikely to be communicated clearly, if they are even communicated at all. By Paul T. Cottey Jan 28, 2019 4 mins CFO C-Suite Technology Industry opinion Look at me! Some employees are happy being unhappy and can be quite vocal about it. Sometimes, however, attention-seeking behavior is masking something else entirely. Itu2019s your job as a manager to figure out which is whichu2026and what to do about it. By Paul T. Cottey Nov 16, 2018 5 mins IT Leadership Podcasts Videos Resources Events SUBSCRIBE TO OUR NEWSLETTER From our editors straight to your inbox Get started by entering your email address below. Please enter a valid email address Subscribe