The 6 Communication Tips for IT Pros

IT departments aren’t usually known for their communication skills. More often, they’re famous for a lack thereof. That’s nobody’s fault — the intersection between tech skills and communication skills is a rare thing. But it can be an opportunity for you. Work just a little bit on becoming a better communicator, and you’ll have gained a skill that can make you an indispensable part of your department and a huge asset to the business as a whole.
Nobody becomes a great communicator overnight, but follow these six rules and you’ll begin to do a much better job of getting your point across clearly, concisely, and (hopefully) without ticking anyone off. Here’s how to start:

Write to Your Audience – Before you begin writing anything, you should know who you’re writing for. If it’s your manager, another member of your project team, or the head of your department, you can get into an entirely different level of detail than you’d want to with a client, for example.
Knowing your audience helps determine not only how you should discuss a topic, and but also what areas of discussion might be off limits. For example, if you’re building an app for a client who’s changed the scope of the project on you several times already, you probably don’t want to present them with every option for how you could implement a feature. Have that conversation with your manager first, then present that client with your solution.
Psuedocode Your E-Mails – Most poorly-written documents aren’t actually full of bad writing, they’re just poorly organized. And just as you’d write psuedocode to help you tackle a hairy programming problem, outlining the points you want to make in an e-mail, document, or PowerPoint will help you make sure that you’ve covered all your bases and done it in a logical order.
Start by outlining the major points you want to make, then break those down into subpoints, then come back and fill each point out into the actual text of your document. For example, I started this story by brainstorming the subheads you’re reading now. Then I came back and wrote an intro. Finally, I expanded each of these tips.
Link People to Background – It works on the Web, and it should work in whatever document you’re creating as well. Oftentimes you’ll be targeting a communication at a group with a wide range of technical knowledge. You can’t explain the underpinnings of every technical decision, but you also don’t want to come off as unintelligible to people outside the tech world. So leave a few key bits of background intact and link people to the rest.
Work with Other Departments – Better yet, make friends in other departments. If you’re writing an app or designing a system for your marketing department, it pays to have someone you can grab coffee with if you need a few last bits of insight into how they plan to use whatever it is you’re building. We all know that no spec ever contains the level of detail you’d need to build the perfect application. (And the ones that do are usually impossible to work with for other reasons.)
If you find someone you can get along with on the other side of the aisle, you’ll be able to avoid a lot of implementation problems, and you’ll have gone a long way towards knowing your audience.
Lose Unnecessary Words – Words and phrases like “obviously,” “it goes without saying,” and “in any case” are just taking up space. If a point truly is obvious, why are you making it? If it goes without saying, why say it? Write out your document, then take a pass through it an eliminate every word or phrase you don’t absolutely need to make your point. Do this several times, and you’ll start to leave out words that aren’t doing work as you write.
Don’t Just Spellcheck – Actually read through what you’ve written. Sure, the squiggly red underline can save you from some egregious mistakes, but it doesn’t catch typos that turn one valid word into another. Taking a second to catch those errors will help people take your communication that much more seriously.