The ASS Rule

A friend lent me Elon Musk’s biography. The book details Musk’s childhood through his education and successes at Zip2, PayPal, SpaceX, SolarCity, and Tesla. It was was written in 2015 so, unfortunately, there was no mention of Musk shooting his Tesla into space nor his interview with Joe Rogan.

My favorite parts of the book were the anecdotes regarding Musk’s approach to business and leadership. One particular story stood out. Musk, upset with the overuse of acronyms within SpaceX, sent his entire team the following email with the subject line “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.

This story is impactful as it is hard to recall a firm I have worked at that did not suffer from rampant abuse of acronyms. I can vividly recall project kick-offs where new acronyms were introduced and various engineers snickering: “oh no, more acronyms”.

Going forward, I will be taking care to scrutinize the introduction of new acronyms. Especially as I am frequently finding myself working on distributed teams with individuals whose first language is not English.

Even more, acronym abuse is unhelpful to new team members, and is disrespectful when no one takes the time to explain what the acronyms stand for.

Lastly, acronym use should be limited - if not totally eliminated - when writing technical requirements where language should be unequivocally clear.