Being better at technical communication
I’m sure you can think of a discussion or email thread that you couldn’t really follow due to its content. Maybe it was with a software engineer describing their code, or a lawyer explaining the complexities of labor law. Regardless of the topic, parts flew over your head and you had to spend a good amount of effort going back to understand what happened. This confusion is a breakdown in communication; specifically technical communication.
Technical communication is just communication around specialized or technical topics. In addition to all the rules and guidelines around normal communication, it has the added complexity of needing to convey specialized knowledge. This is particularly challenging when the audience doesn’t share the same background concepts or ideas (such as when you’re trying to explain how your system works to someone who’s never used it). This is further compounded by the specific terms and acronyms that are used in different fields.
I see many individuals running into challenges when they either don’t know how to apply technical communication skills, they apply them at the time or in the wrong way. When this happens one, or both, parties, will miss important details of the message (at best) all the way up to damaging their relationship with that team. More frequently this results in poor communication that requires additional followup to clarify what is meant. I can think of many email threads that simply. Wouldn’t. End. because one or multiple individuals on it were not able to effectively translate their technical concepts.
In addition to needing to apply technical communication during synchronous communication - phone calls, zoom calls and the like - technical communication also needs to be applied to asynchronous communication - emails, documentation and bulletin boards. Asynchronous can be more challenging since the reader only has the text that’s in front of them and there’s no chance to clarify questions. In general the approach I take is to write my documentation so someone with NO background would be able to follow along. Assuming that my audience has no clue what I’m talking about helps me avoid assuming they’ll know background ideas and makes it a lot easier to include the right level of information.
Some other things that help with technical communication
Define acronyms immediately - The first time you use an acronym, either spell it out and put the acronym in parenthesis “Three Letter Acronym (TLA)”, or do the opposite “TLA (Three Letter Acronym)”. This gives the reader a good reference.
Identify and define specialized terms - Depending on the format this could take the form of a glossary, an appendix or just some lines at the top of an email. For example “Active Directory is a system we use to manage access and data about our users”.
Include Reference Material - Depending on the audience and format I also like to include links, attachments, photos etc. to help provide more context. This could be a general systems diagram so everyone knows how the systems interconnect, a vendors documentation, or anything else to help your audience understand what you’re talking about.
