Live data from Hacker News

To find great remote employees, prioritize candidates with strong writing skills

youteam.io

81–90 of 332 posts

Re: To find great remote employees, prioritize candidates with strong writing skills

#81
How do you feel about acronyms? Do they improve or hurt communication?

From time to time, Musk will send out an e-mail to the entire company to enforce a new policy or let them know about something that's bothering him. One of the more famous e-mails arrived in May 2010 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.

Re: To find great remote employees, prioritize candidates with strong writing skills

#82
post #66

Earlier quoted context omitted.

But, when it's that long, do people read it? It seems like a great CYB tactic, but maybe a poor communication tactic. I'm a voracious reader, but when it comes to most corporate communication I won't really read anything over a paragraph long. I might skim it if it is from my manager. Maybe.

People read if it’s written well. Don’t make it long to be long, make it long because it needs to be long. My favorite feedback is when someone replies to a 1000+ word newsletter with “Wow, short and to the point! Thanks”.

It's a lot harder to write something short and concise that efficiently communicates to team members than something long and wordy that requires a lot of reading.

Re: To find great remote employees, prioritize candidates with strong writing skills

#84

Agree, but this does skew in favor of people who's first language is English, which shouldn't really be an indicator of engineering quality.

IDK for me as a non-native english speaker, it's harder to discern non-native english from native english speakers when inspecting written communication as it is when listening to spoken communication. I assume it's the same for native english speakers, but please say if you disagree.

Also, I think it's easier for non-native folks to both comprehend others and communicate as they can look up stuff or use google translate.

Re: To find great remote employees, prioritize candidates with strong writing skills

#86
post #22

Earlier quoted context omitted.

This is how it is at my company (100% remote). Having Zoom on stand-by is key for us. Anytime things get complicated, we just hop on a Zoom call. All of us can communicated well in writing, but I don't know of anyone on my team who prefers it. For me, in particular, I'm an incredibly slow writer, so it's just painful to write too much.

It’s big where I work, too - I’m very into the little slack (there might be a teams one?) plug-in, where you can just message people “/zoom” and it instantly makes a meeting with whoever’s in the chat. It makes little 5-minute meetings for debugging or clarification super painless, which means we do more of them, which is huge for the team being on the same page.

I doubt there's an equivalent Teams plugin because the standard solution for that problem in Teams is to click the little telephone icon inside the chat and you're on a call. Add or subtract video and screen sharing as desired. Continue to paste things (documents, links, whatever) inside the call's chat and it's recorded along with the chat/call.

I have a lot of complaints about Teams, but there's something to be said for an integrated solution.

Re: To find great remote employees, prioritize candidates with strong writing skills

#87
post #80

I believe I am a good writer. On my first job as a developer I kept getting very positive feedback on my writing. I ended up even starting a newsletter with writing advice for software developers[0]. So 4 months ago I started looking for a remote job. I applied to 250+ positions. All very suited to my skills (e.g. I wouldn’t apply to any job asking for “senior” or “fullstack”). I got about only ~15 interviews, 1 offe…

I think you missed one thing -- in my opinion the most crucial: cover letter.

I wrote about it on https://blog.gingerlime.com/2020/who-doesnt-want-to-be-hired...

Re: To find great remote employees, prioritize candidates with strong writing skills

#88
post #8

This isn't my experience, I find that people who are quick to initiate communication do really well. Doesn't matter too much about the writing (maybe some people are much worse than us at writing) as we simply voice chat if things weren't clear

This breaks down quickly if you are across timezones like many remote teams. Async communication becomes the most common way of distilling info. It can't completely replace zoom/slack but it is critical for transparency and team cohesion.

Re: To find great remote employees, prioritize candidates with strong writing skills

#89

Agree, but this does skew in favor of people who's first language is English, which shouldn't really be an indicator of engineering quality.

An engineer that can't communicate properly is a poor engineer, regardless of their coding ability. I've worked with too many great coders who were terrible at communicating. This includes engineers who were fluent at English. Communication is an extremely important skill. This is a reality of life. If I moved to Nigeria and could barely speak the language, should I expect people to accommodate my poor communication…

Not writing well doesn't mean that you don't communicate well. Plenty of engineers can communicate just fine in English, just sloppily without perfect grammar.

Re: To find great remote employees, prioritize candidates with strong writing skills

#90
post #63

I've been working on remote teams for almost 20 years. The key to success is overcommunicating. In other words--don't assume people have full context or share assumptions. Write emails that lay out assumptions explicitly and detail problems completely. As a manager I sometimes feel like a Habsburg bureaucrat buried in the Chancery offices sending painstaking messages to a far flung empire. Come to think of it, remote…

As a manager, you can probably get away with this. As an IC, people rarely read my emails if it doesn't fit in their screen (so 3 paragraphs is the max). The only thing I've found that works is to send details, and then probe the recipient on each important item in there to make sure they understood what I wrote. If I'm too detailed, they will get lost. If I'm very concise (but still complete ), they'll misinterpret.…

> As an IC, people rarely read my emails if it doesn't fit in their screen (so 3 paragraphs is the max).

You need to learn how to restructure your writing. Most logical people naturally write in a way where it’s premise, premise, premise, conclusion. Instead, you need to write conclusion, premise, premise, premise.

One way I’ve found to help my team learn to write this way is to institute a rule that any writing longer than 3 paragraphs has to have a TL;DR at the top that is no more than 3 sentences. This gets people over the hump of putting the big ask up front and then after a few weeks, they start naturally writing that way.

Post reply on HN