32
Clouding Communications with acronyms
Let me start by saying communication is hard. Clear, concise communication even more so.
Acronyms harm all communication. Acronyms are everywhere, all throughout our lives. But why.
Has anyone ever seen an acronym and thought yes, that has clarified things. Very rarely, if ever.
I hope I can convince you of one thing by the end of this blog, to stop using acronyms.
I'm going to start with an email from Elon Musk, sent to Space X employees in 2010. Regardless of your feelings about him, I hope you can see the points in his argument, that acronyms seriously suck!
There is a creeping tendency to use made up acronyms at SpaceX. Excessive use of made up acronyms is a significant impediment to communication and keeping communication good as we grow is incredibly important. Individually, a few acronyms here and there may not seem so bad, but if a thousand people are making these up, over time the result will be a huge glossary that we have to issue to new employees. No one can actually remember all these acronyms and people don't want to seem dumb in a meeting, so they just sit there in ignorance. This is particularly tough on new employees.
That needs to stop immediately or I will take drastic action - I have given enough warning over the years. Unless an acronym is approved by me, it should not enter the SpaceX glossary. If there is an existing acronym that cannot reasonably be justified, it should be eliminated, as I have requested in the past.
For example, there should be not "HTS" [horizontal test stand] or "VTS" [vertical test stand] designations for test stands. Those are particularly dumb, as they contain unnecessary words. A "stand" at our test site is obviously a test stand. VTS-3 is four syllables compared with "Tripod", which is two, so the bloody acronym version actually takes longer to say than the name!
The key test for an acronym is to ask whether it helps or hurts communication. An acronym that most engineers outside of SpaceX already know, such as GUI, is fine to use. It is also ok to make up a few acronyms/contractions every now and again, assuming I have approved them, e.g. MVac and M9 instead of Merlin 1C-Vacuum or Merlin 1C-Sea Level, but those need to be kept to a minimum.
He has really hit the nail on the head for me. I'd argue to go further not even have an approved list but it's the right direction!
Next on my hit list of why you shouldn't use acronyms is it massively hinders cross team communications. This can be between frontend and backend teams. It can be between engineering teams and marketing teams. Throughout the whole company acronyms cloud communication.
Let me give an example, some people use PR in the marketing sector to refer to Page Rank, however in the engineering teams PR means something completely different, it means Pull Request. You can see how already those two teams could misunderstand a conversation just from the use of this one acronyms, never-mind when you start to include other teams and more and more acronyms.
I once was in a meeting with members from all different teams, and someone from the engineering department was explaining their role and what they do. Scattered throughout where fairly standard (from a engineering viewpoint) cloud acronyms e.g. EC2 (Amazon Elastic Compute Cloud), CDN (Content Delivery Network) and so on. At the time I was sat next to someone from the Human Resources department who whispered to me asking me to explain what each one meant as they didn't understand, others in the room had glazed over.
These fairly common acronyms in the engineering world were harming communications, confusing some people, switching others off from the content being delivered. It's so easy for us to slip into using these acronyms if we deal with them day to day. But we need to remember the audience we are communicating with. If we reduce our use of acronyms we will be less likely to fall into the trap of clouding cross team communications.
Now never-mind clouding cross team communications, acronyms can harm communications inside your own team!
I can recall at least two situations where I was new to a team and in the morning stand up discussions, and I was completely lost, not because of the technical information but the use of many unfamiliar acronyms. I had no idea what they were talking about, until I had to pause the stand up and ask for them to explain what the acronym meant, which actually took longer than using the actual words contained in the acronym themselves.
This happens all the time, I'm certain, you've probably experienced this yourself.
Often it can be even worse if someone doesn't ask for clarity on the meaning of acronyms and leaves the conversation no clearer on what is going on and feeling out of their depth. This happened to me plenty of times early on in my career, where I'd frantically search for the meanings of acronyms after meetings to make sense of what had just happened in the meeting.
It can be really off putting for new starters to your team. It can also mean new starters are spending more time trying to decipher acronyms than getting stuck in with the team.
Context is everything when communicating. It's very easy when communicating to forget the people you are communicating with likely won't have the same context and head space as you.
This is even easier to forget about the other persons context when writing using asynchronous communication e.g. email, written documentation, blogs, direct messages and so on. It's also less likely that the reader has your context and head space when consuming content from asynchronous communication sources. Making both ends of communication harder.
Especially important to consider context, when some of the most common and pervasive forms of modern communications are asynchronous in nature.
It is so easy to slip into the use of acronyms when writing in particular, and for me. likely to be the biggest source of confusion. (It's much easier to ask someone what they mean by an acronym when speaking directly for example).
I've done it on several occasions when writing this blog and had to go back and correct myself. But if we remind ourselves of our readers and the readers context, we can make a conscious effort to remove acronyms and help clear up communications.
I've done it on several occasions when writing this blog and had to go back and correct myself. But if we remind ourselves of our readers and the readers context, we can make a conscious effort to remove acronyms and help clear up communications.
I've often read blogs, and attended presentations where I've had to search out the meaning of acronyms while trying to understand the meaning of the content I'm consuming. Making the processes of understanding and digesting the content doubly hard.
This is before you even consider the accessibility of the content. Try having a screen reader, read out text containing acronyms. It is so hard to maintain your train of thought and digest the content, for me at least.
Acronyms negatively impact communications throughout our lives, and yet they persist. Next time you use or hear an acronym being used, please consider how it's now clouding the communication and how you can help bring clarity to your communications.
In summary, I hope I've managed to convince you to stop using acronyms. If we all make a conscious effort to stop or at least reduce the usage of acronyms, we can make communications clearer, more concise and banish the confusion.
32