Comment by oriesdan | Hacker News Reader

Comment by oriesdan | Hacker News Reader

That's really impressive and insightful.

I've been working all my career (12 years) as a remote worker (freelancer for a couple years, then employee) and poor async communication skills is by far the worst and most omnipresent problem I've seen - mainly because as nobody sees who is doing what, allowing interruptions quickly lead to everybody constantly interrupting everybody. Having Hangout or Slack constantly ringing because three people want my attention at the same time is a sure way toward madness.

The lack of async culture also often manifests that way : a manager/lead/whatever sends a grossly imprecise demand as a one-liner email ; then developers ask questions about what the hell that person is talking about ; then the first person gives a few more details (the minimum amount) and concludes with "can we have a call? It would be simpler".

I think the main problem is that many companies, while they want to try remote work as it "attracts top talents", don't have the proper culture for it, which is, ultimately, the culture of writing. Not only being able to type down the words you would have spoken, but to actually perform thinking writing - which implies to draft a few ideas, then read them, modify them, change their order, remove some, add others, and only when you're sure you've nailed the issue, hit send to share it with everyone.

The typical non-remote employee won't want to do that and prefer to throw vague ideas in the room so everybody contribute to making them clearer at the same time. I'm biased of course, but I think this is highly inefficient.

This matches up so precisely with my experience it's scary (and a little sad).

Everyone is so quick to "have a quick call" that inevitably sucks 20 minutes out of everyone's day because (and I've heard this verbatim a dozen times in the past 6 months alone) "it's too much to type out" or "it's easier than sending an email," but then wonder why nothing gets done when all the dev tasks are eighteen 20-minute segments of work instead of two 3-hour segments.

To your last graph, I think there are absolutely times where this makes sense, but "business owner has a new feature request for a large existing product" is not one of them.

Also they wonder why they all forget all the things they said in their 20 important meetings a day.

This. I try to avoid calls as much as I can, it's so much more effective to have a written transcript, whether it's in Slack, email or Jira.

It's not just that people don't know how to write. It's been my experience that many people also don't know how to read properly. If you try to make a nuanced argument, many people will read what they want to read and completely misunderstand you. Or sometimes they will complain "why are you writing so much? I don't like to read".

It’s not even that. People don’t even try to read. Ask two questions in an e-mail, and get an answer to the first question, only. Every time.

You have to adapt. Ask the single most important question as the first sentence. Don’t write a lot of text after the question either – it would only make people feel they can put off reading it, and therefore put off answering the e-mail. Don’t ask an easy question later in the same e-email (people would answer that question only, and ignore the rest of the text). And so on.

Sure, that might work for simple questions. But sometimes you really need to ask a nuanced question, and then what?

I’d ask the question first, then explain it. Possibly ask the same question again after the explanation. If the question could/would be misunderstood without the explanation, I’d change the question to instead be confusing without the explanation. But you really have to work hard at being able to explain enough things with a very short text.

> Ask the single most important question as the first sentence

Exactly. And also, NEVER ask the questions you'd like answers for on Friday afternoon. Or any afternoon in general.

If it doesn't say what it wants in the first sentence or two, I'm hitting delete, unless the email is from my boss. And I currently do not have a boss.

"but to actually perform thinking writing" <- This is well articulated, thanks for framing this in a way that is widely understandable.

We have a guide that covers top attributes of great remote hires. This will be merged into that guide soon: https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_request...

I found this video very helpful:

https://www.youtube.com/watch?v=vtIzMaLkCaM

Thank you for sharing this excellent video.

I work in academia on the “business side” in IT. Interacting with faculty is notoriously frustrating.

Around 23:00 in this video the presenter offers a rule of academia that “nothing will be accepted as knowledge or understanding until it has been challenged by someone competent to challenge it.”

I found that immediately insightful and instructive.

This is what I found too when I ran a team. I started having to manage remote employees and found out that it was vastly harder than I imagined. The whole team had to essentially train ourselves on how to handle remote workers. We did this by forcing each of us to be remote part of the time, so we could learn what worked and what didn't.

It's sad really. I worked at another company where there were a few remote workers that all ended up getting fired for performance reasons. When I pointed out that it seems that all remote workers have performance problems and maybe it isn't them, management looked at me like I was fool, and clearly if the remote workers just "worked harder" it wouldn't be an issue.

I like your description. I've complained that my current company likes to throw people at problems, instead of solutions. Sounds like writing might be the root issue. Documentation is not a priority, and if there is documentation; nobody reads it. This means any emergency has to have half a dozen "experts" on a meeting to resolve the issue. It's very frustrating.

Reply on news.ycombinator.com