All the IT career resources harp on building communication skills and avoiding jargon. But how do you get around explaining technology without using technical terms?
I got a great e-mail the other day from a TechRepublic member. He (correctly) stated that all the IT career advice out there tells you to work on communication skills -- specifically how to keep the tech-speak out of your conversations with stakeholders and end users -- but nobody tells you how to do that. From the e-mail:
"I, and almost every tech I know, has a difficult time trying to explain their points without getting engrossed in the detail and/or tech-speak. There is nothing that is more dissatisfying within my own career than trying to convince upper management of a solution that we need, especially one they ask for, and find that even at my best, I eventually lose them. I make a concerted effort to avoid technical terminology but the main decision makers in my company have a condition where their eyes roll into the back of their heads as soon as they hear the word computer, except for when broken is the next word in the sentence.
You and others like you often advise not using tech speak when trying to explain a problem or situation. But no one seems to be able to guide people like me in the right practical direction on what to use."
If there is a secret to communicating technical information to the non-technical, it is the use of analogy (a form of communication in which one topic is explained in terms of another, more familiar topic that is similar in a certain respect). In other words, when you need to explain a technical issue, do it in terms of something that falls more into the listener's experience of everyday life.
It's a fact that someone can understand a new piece of information if it can be explained in terms of information that person has already acquired and used. You see a lot of analogy used in court cases when experts are explaining medical evidence to a jury. I use it a lot when speaking to my teenaged son.
Analogies can be used on an everyday basis, as in explaining to an end user why he can't access secure Web sites. You could say, "If the cipher strength of your browser is inadequate, you will not get into secure Web sites." I can tell you right now that that will mean nothing to the average end user. Instead, you can say that not having proper encryption means that that person has security clearance to enter a building but may not be able to get into all areas. In order to do that, he needs to "upgrade his security clearance status" (adjust the encryption). And then show him how to do that. A file allocation table can be compared to a library card catalogue. IP addresses can be compared to phone numbers -- for one phone to communicate with another, both must have unique numbers in the phone system. If a user asks why his browser is running slow, you compare it to a busy highway. Too many users are using the service -- that's like too many cars on a road at rush hour.
Analogies can also be used in higher-level situations, such as the one you describe when you're trying to sell an executive on a new initiative. They're even more useful in those situations since you usually have some lead time and can think about some creative metaphors or similes.
Hope that helps. Anybody else out there have any analogies that have served them well?Get career tips in your inbox TechRepublic's IT Career newsletter, delivered Tuesday and Thursday, features insight on important IT career topics, including interviewing, career advancement, certifications, and job changes. Automatically sign up today!
Toni Bowers is Managing Editor of TechRepublic and is the award-winning blogger of the Career Management blog. She has edited newsletters, books, and web sites pertaining to software, IT career, and IT management issues.