
Written communication is remote work super power - snird
https://snir.dev/blog/remote-async-communication/
======
jackjeff
Async communication is suitable to resolve some kind of issues. But it has two
drawbacks: participants need to be competent at writing and reading prose
(it’s harder than it sounds) and even with the best of care your ideas can
easily be misinterpreted resulting in the loss of an async cycle.

For problems which are not well defined, and where a lot of decisions need to
be taken, especially when they verge toward the arbitrary, it’s a lot easier
to have people in a room and hash it out. A remote meeting can work too.

The problem with meetings are those which are not well prepared. There shall
be an agenda and proper minutes should be produced.

For most complicated matters actions/investigations are supposed to be
followed up. In a way that’s how you mix async with sync communication.

~~~
duxup
Recently, I was so frustrated with some folks poor reading comprehension that
I was thinking about an imaginary communication system that would allow for
decision making where there were some rules:

\- No responding from mobile devices. The poor response rate is just too high.

\- The reader is quizzed on the the contents of the communication before they
can respond (randomly generated quizzes might be amusing).

\- The reader has to retype the original communication themselves before they
can respond....

\- Timeout value, if no responses that pass the above tests in a given time
frame, whomever asked gets to complete the task with no input and nobody can
change the outcome for ... a week or so and everyone has to live with it.

\- Anyone who wants to change it after the timeout value better explain why
they didn't ask before hand... no idea how this would work, yeah we're getting
into the weeds here.

Of course, these are all unworkable in a modern business environment but man
... I can dream that some folks would who make demands or provide input at
least put a minimum amount of effort into things before they throw their given
wrench into the works.

~~~
BeetleB
Bullets 2 and 3 combined are actually recommended for spoken communications as
well. As the listener, before responding, it's a good habit to say "This is
what I understand about your proposal" and proceed to summarize and give the
original speaker an opportunity to correct you.

Probably over half of the communications problems I've seen at work are
because people don't follow this basic practice. They respond based on what
they understood, not based on what the speaker was saying.

As one book I read put it: You should be able to reflect their world view back
to them as if you yourself are advocating for it (even if you completely
disagree). When you do this, they'll believe you understand them. For many
people, only then will they listen to your critiques.

~~~
a_e_k
> As the listener, before responding, it's a good habit to say "This is what I
> understand about your proposal" and proceed to summarize and give the
> original speaker an opportunity to correct you.

I find a practice like this is also helpful for following up after a meeting.
For meetings that warrant my taking notes, I like to type them up immediately
afterwards, send them out to the other attendees, and solicit corrections or
confirmations while the meeting is still fresh on everyone's mind.

It was a bit scary when I first started doing that since I'd fear that I might
have misunderstood something and would be revealing my ignorance. But to the
contrary, I've found that it tends to encourage others to share their notes
for comparison and elicit further discussion. (If there's something I've
misunderstood from a meeting, usually someone else was confused too.)

~~~
ivanovb
I've been doing the same for the past 10+ years.

The problem that I found with it, is that a recurring receiver (let's say a
client) will eventually start trusting your minutes so much that they don't
even bother to read them and just answer with 'Looks good' and basically you
lose the power of minutes.

To counter this, recently I've been trying to insert one wrong bullet point
from the beginning, making the receiver pay more attention down the line. I
don't have yet enough data points to see if this approach works.

~~~
jblarneyforward
That last point is pretty hilarious!

I find writing up the minutes during the meeting and distilling to “are these
the most important points?” works to grab folks’ attention.

------
nine_k
Real-time, spoken communication is on-site work super power.

When uncertainty is high, and an intense discussion is needed, spoken word is
much more efficient, from my experience. People are fundamentally better at
speaking quickly and taking proper turns. This all is much slower and more
cumbersome in video call, phone call, or a text chat. The perceived sequence
breaks, the turn-taking protocol breaks (unless enforced by a moderator, at
the expense of speed), and the communication become slower, less efficient,
and more tiresome.

I _love_ neatly written logically organized texts. But to produce such a text,
a lot of the questions it answers should be already understood, answered, and
arranged in a easy-to-consume order. There are situations when this is not
possible, and _finding out_ the scope of the problem and its structure is
exactly the task. Here's where face-to-face verbal communication rules.

Of course, providing some written output after such a meeting is important,
too, be it nicely written minutiae (a shared document on a large screen works
well), or just a photo of the whiteboard.

So, _both_ written and face-to-face types of communication are important. None
can efficiently replace the other.

~~~
e40
I agree with you partially. I found something interesting, with this everyone
work from home: I'm able to communicate with certain people more effectively
via zoom.

I think it boils down to with zoom, you are literally in someone's face, and
it's very obvious when you aren't fully focused on them.

Perhaps the new way, with zoom, gave some people an opportunity to reset their
manners? Not clear what the real reason behind it is, but I noticed it
immediately.

What a great bonus it was.

~~~
nahname
In a natural conversation, it is rare to have someone stair you in the eyes
for more than a couple seconds.

Hadn't considered that for some, this constant stair feels like they are
finally being recognized. This makes a lot of sense. You wait for your turn to
talk and the stage is yours. In some sense, everything is fairer.

~~~
cutemonster
You can look all people in their eyes at the same time

(But impossible in real life)

------
danielovichdk
Actually funny this question. Because come to think about it, text is by far
my preffered way to communicate.

That goes for work and for serious-private matters.

The absolute strengt with text is that it gives you history by default - you
can save it.

While you can save text it's also eaiser to the search.

The mental model around writing and communicating is the mental proces that
goes into it, and which is also the reason i disagree with people that believe
you should be good at writing - if you haven't thought about what you want to
communicate you can't write it nor speak about it. Why would you be better at
communicating by speech rather than text? Sure it's faster to speak or video,
but does that give a better result? I say no way

~~~
EvanAnderson
It's worth noting that some people specifically see verbal communication's
undocumented-by-default nature as a feature.

When I was younger I found that idea very offensive. I considered people who
held that viewpoint to be suspect (engaging in political machinations, or
using fluid recollections of conversations to their advantage). I still think
there's a grain of truth to my suspicions, but I've learned to recognize that
there are acceptable reasons for undocumented conversations.

~~~
Buttons840
There's still phone calls. Any co-worker you trust enough to have an "off the
record" conversation with wouldn't turn down a "hey, can I call you?" request.
They might think it's weird at first, but would understand later I'm sure.

~~~
RHSeeger
I've called coworkers literally just to rant to someone before. Sometimes, you
need to complain, but having a record of that is not helpful in any way.

~~~
Aeolun
Private chat works for me. Corporate IT might be able to see it, but I’m not
saying anything there that my boss isn’t already aware of.

------
Animats
Did this guy just re-invent memos?

There's a lot of history here, going back centuries. The military has put much
effort into designing written communication. There's the classic 5-paragraph
operations order format. There's the "bottom line up front" style, which for
information rather than orders. The military makes a very strong distinction
between info documents and orders.

Diplomats have some traditional formats, too.[1] Most correspondence is
formal. Sometimes there's an "appreciation of the situation" attached to
correspondence from a mission to its state department. That's an informally
written summary of what the writer has observed and what they think is going
to happen.

An amusing read is "How to Live though an Executive", which is nominally by L.
Ron Hubbard, the Scientology guy, but was really written by Richard DeMille.
This is from 1953. It's someone trying to invent Slack, before computers. It's
done with wallboards, clips, carbon paper forms, tear-off tickets, and people
called "communicators" doing the paperwork. It was never used. Too complicated
pre-computer. The basic concept is a trouble ticket, with an organized system
to insure that handing off the problem to someone doesn't mean it gets lost to
follow-up.

[1] [https://projects.iq.harvard.edu/files/hks-communications-
pro...](https://projects.iq.harvard.edu/files/hks-communications-
program/files/pp_sri_kulkarni_and_yotam_goren_4_10_17.pdf)

------
jka
Yep, this article rings true on a number of levels, particularly regarding
asynchronous work and lack of interrupts.

Anecdotally, I'm working on a software project at the moment with a small team
of volunteers.

To explain some context: I'm the sole developer currently, and I'm treating
communications to the team as high-value for us, now and in future - the same
way that I'd like to think that I treat the code (I write this with the
awareness I've recently cut some corners; but cleanup is on the cards).

One observation is that I'm _really enjoying_ only using email for that
communication.

Sometimes I code for a couple of days before checking or answering emails,
simply based on what feels most productive or compelling at the time.

As a result I never get distracted by pings while working, and feel much more
comfortable taking time while writing messages and replies, generally allowing
me to be a bit more thoughtful.

And there's only one communication platform. My attention's not split between
instant messages, emails, and other organizational tools.

This situation's probably an edge case based on the small team size and my
personal preferences, but it's been an interesting experience.

I don't know how well this approach would scale* -- and an open question based
on my experience and also raised by the article is: how and where do you
organize that content so that it can be discovered by newcomers to the team?

*Example: crisis moments, such as technical outages, would be tricky to manage for a multi-person operations team

~~~
vasco
I like flow as much as anyone but find the thought of working multiple days
without speaking to my team to be crazy, I'd feel like none of us would be
able to move as fast alone as we do together, and half the time would end up
following rabbitholes, or spending too much time on the wrong things because
we'd never check in for an opinion. The only way I'd see a full or more days
of work without communicating working well is if we'd work on larger amounts
of releasable code at once, but then there's more chances of conflicts,
reviews get longer and harder to do and there's more risk releasing.

I think having a team with 1 rotating person responsible to handle all
external requests per week, and everyone else being focused on their work but
still being able to pair when needed, ask questions provide guidance, etc to
be really cool. All of this remote, of course.

~~~
joe8756438
That’s an interesting idea regarding rotating external request handling. Do
the team members not currently on call forward requests to those on call? How
do you manage continuity of communication once the rotation has shifted?

~~~
vasco
We usually sync out of hours on-call with the "handle requests from outside
the team" so that while you're at work you're the same person, everyone in the
company knows to go to a specific slack room for these requests to our team,
or they can straight up create a "change request" ticket in our jira board if
the request can be done few hours/days later.

Usually there's nothing (in almost 4 years I think less than 5) that goes
across weeks that's still in progress. We have a very low volume of actual
incidents, and external requests that are sizeable enough get turned into
actual prioritised stories by the next planning.

------
cmarschner
Peter F. Drucker, influential author of countless books on management, once
made a very simple argument: there are reader types, and there are listener
types. If you are dealing with a partner you better know which type they are.

It doesn‘t make sense to hand a listener type a manuscript without talking
about the subject, and it doesn‘t make sense to set up meetings with a reader
type before you hand off the written argument.

We should perhaps just accept that an tolerate each other where our strengths
are.

[1] Peter F. Drucker: Managing Oneself. [https://www.amazon.com/Managing-
Oneself-Harvard-Business-Cla...](https://www.amazon.com/Managing-Oneself-
Harvard-Business-Classics/dp/142212312X)

Edit: Online:
[http://academic.udayton.edu/lawrenceulrich/LeaderArticles/Dr...](http://academic.udayton.edu/lawrenceulrich/LeaderArticles/Drucker%20Managing%20Oneself.pdf)

~~~
xpe
Whatever people’s preferences in terms of reading or listening, I am inclined
to think teams get better results when a high quality meeting summary goes out
ahead of time.

I don’t claim this is an absolute truth, but I also don’t think many
organizations have given it proper try.

~~~
paragraft
I agree, but think the virtue is as much as in the actual process of writing
the summary forces the summoner to clearly work out ahead of time what the
meeting is actually about and what it is aiming to achieve.

------
Kaze404
This article is great because it puts into words the relationship I've had
with Slack since the beginning of my career. I've been working professionally
for 4 years and I cannot remember a single time where I thought "I'm so glad
we have Slack". Don't get me wrong, I think the platform itself is a great
interpretation of IM, but IM is the absolute last thing I want to use in a
work environment.

One of the reasons I didn't work out on my first remote job is because I
refused to treat Slacks red icon as my #1 priority in the world. Coworker
needs my attention immediately? Call me. Is calling too much of a hassle? Then
it's probably not as urgent as you think. I understand it's very arrogant of
me but I cannot bear the thought of losing all of my focus to answer a
question that was really not that immediate. It sure doesn't help that people
think they need to greet me and wait for a response before they actually say
what they want to say.

I'm working at a new place now and we've gotten so good at asynchronous
collaboration that I haven't exchanged a single message on Slack with one of
my coworkers since they joined the team. All of our talks are done through
Github and our weekly meeting on Friday where we plan the next week and spend
an hour or two chatting. This is nice because it gives me time to reason about
discussions, and even makes me look forward to the next meeting to have some
fun with them, while previously I got so sick of my coworkers that I had
literal nightmare-induced panic attacks over constant meetings.

I'm really glad I managed to find a team that enjoys working on the same way I
do.

~~~
briandear
> Coworker needs my attention immediately? Call me.

I despise unsolicited phone calls. It’s figuratively kicking in your door. I
can delay a Slack response for a few minutes. I can’t delay some jackass
barging into my “office.”

~~~
abalashov
Second that. Phone calls - and they're all unsolicited as far as I'm concerned
- aggravate me far more than a barrage of IMs, though both are undeniably
aggravating.

There's a small irony to this since I've been in the VoIP industry for about
15 years. :-)

------
Traster
I think a big part of this article is that the author doesn't like being
interrupted and therefore has defined this as the problem. I don't like being
interrupted either - but often the interruptions I experience are the best
opportunities I have to communicate ideas, have creative back and forth, and
importantly, communicate the details that are going to get me shouted at for
saying on the wiki.

The problem with asynchronous communication is that I need to predict what
information you're going to need, before you need it. The result is huge
amounts of documentation work going on - 90% of which is useless, and the
other 10% is either undiscoverable or could as just as easily be solved with
"has anyone touched the db" in chat.

The example is great - because it's absolutely something that I've seen
happen. You post on the group chat "did anyone touch the db" and someone
replies, "Oh Johnny mentioned something about it the other day". Suddenly
you're not searching through thousands of jira tickets and wiki pages, and
most likely not finding what you want anyway - since no one can predict how
they'll scre up. You just ping Johnny, and if Johnny isn't there? Well he'll
reply when it's back. It's fine. _That_ is part of flexible working. Flexible
working isn't "I get to pick up my kids at 12" it's about everyone having
flexibility, and everyone giving flexibility.

To me, this asynchronous communication plan sets an unacheivable goal, because
you're never going to know what it is other people are going to need to know,
and documenting everything exhaustively is an uneconomical.

------
sytse
When writing you are not getting feedback (give more context, go faster, what
concerns to address). A back and forth can be a much faster way (both in total
time elapsed and time spend) to resolve something. At GitLab we recommend
async by default and jump to sync when you start going back and forth.
[https://about.gitlab.com/company/culture/all-
remote/asynchro...](https://about.gitlab.com/company/culture/all-
remote/asynchronous/)

------
krm01
In our business, async communication is at the core of how we deal with
clients. We design UI/UX for tech companies
([http://fairpixels.pro](http://fairpixels.pro)) and in the 10+ years of
trying out a dozen of ways to work, async email conversations were by far the
most effective for us.

Email over Slack, why? Slack and other chat environments still create the
expectation of realtime responses. Also, messages you type there are short and
often of a lower quality.

Email is usually more longform. This forces us and clients to think first,
write second.

The quality of feedback and communication is just so much better.

------
joe8756438
I also find keeping a log of work helps provide the right communication at the
right time. Especially when remote I find it is easy to forget all the things
I’ve worked on in a given week. It doesn’t always make sense to interrupt
somebody with updates on something the moment it is done. Colocation provides
so many more cues to communicate progress, ideas, etc. in the collocation
context the work log is less important as a communication tool.

It so happens, (shameless plug alert) I built a tool [0] that asks me what I
did on a daily basis via sms, the responses are organized in my work notes
folder. I use this for keeping track of long-running projects that depend on
lots of other people for input. I also use it to build a monthly description
of work to include with my clients’ invoices.

0\. [https://www.tatatap.com](https://www.tatatap.com)

------
inertiatic
I am a firm believer that written communication is the best way to sustain a
productive team.

Talking, especially in person, might get you the result you're looking for
faster. Look, we decided what we needed to make and skipped the overhead of
opening a ticket and capturing the back and forth.

But then you have to revisit your decision and your reasoning behind them 4
months from now. Why didn't we just do that other thing that seems more
efficient? Or even worse, someone picks up your work after you leave and they
have to do that, without the potential ability to recall the context. Or then
you leave a meeting about making any sort of decision and start working and a
few days later realize you're not on the same page.

I get that writing might not be some people's best skill, or even their
preferred way of communication. We all have to put up with things we don't
enjoy and learn skills to work, why should this be any different?

I work for company that is in the process of going remote first, without
embracing a culture of writing first and writing everything and it's not very
pretty.

Previously, I worked for a company that despite not really prioritizing remote
workers, because teams were distributed across the world, had to capture a lot
of the things I mentioned in the tickets created for each task. And it was
really empowering to have a lot of context as someone who was tasked with
maintaining those things.

------
alexashka
I think emotional intelligence coupled with integrity are the real super power
wombo-combo, no matter the role.

It helps if you have the technical skills to go with it but to be honest,
having those skills should be a matter of training, not expecting people to be
learning on their own time.

This should be fixed on the company level - every employee should receive
regular training, not be expected to magically keep up their workload _and_
learn new technologies in their spare time.

Another issue that makes projects go side-ways is people relying on a
paycheque for their livelihood. If you want people with integrity to practice
it in the workplace, don't place them in impossible situations where they have
to choose between their integrity and their family's financial well being.

This should be fixed on the government level.

This is all to say that this endless stream of blog posts about what an
already over-worked, under-paid worker ought to improve upon, are not helpful
- highly educated people used to be Aristocrats who fine dined and wrote
poetry. Today we are expecting people to pay for their own training, spend the
best years of their lives studying to pass tests, be hazed trying to get a
job, for the privilege of getting worked to the bone for the benefit of a
corporate entity. I thought only dystopian novels could think of a system so
counter-productive and insane, until I read Brave New World and thought hm,
this might be an upgrade over the life I'm currently living.

Anyhow :)

------
satvikpendem
If I were to ever hire, I'd optimize first for clear, written, long-form
asynchronous communication, second for ability for the job at hand, and
anything else third.

Having hired some freelancers recently, I've found that there is a world of
difference between those who can communicate clearly and those who can't.

~~~
abalashov
Oh, indeed. I think this is the single most underrated dimension of actually
being able to extract value from someone in a commercial organisation.

Also, having run into it a number of times, I feel compelled to mention those
who are quite capable of clear, written, long-form asynchronous communication
as a matter of skills and abilities, but seem cholerically averse to doing it.

------
jaakl
Video calls are like single-room IRC 20 years ago, before PM, threads etc
within same room were added. Probably just matter of months when we will see
subrooms, side-channel whisper, history of transcribed logs and many other
additions also in video calls. Just current software limitations.

~~~
djrogers
Pretty much all of those features you call out are available in modern video
chat software - at least the one I have to use daily (Zoom).

------
MattGaiser
I have a day where everyone else in on flex (basically their day off every two
weeks).

I have already cleared two large tickets because I can address the comments
they left when I am done another task (because they wrote out their entire
thought instead of waiting for a conversation).

I would bet I am 2-3x as productive as I now have hours of uninterrupted time.

------
timwaagh
In my team if someone needs to pick up the kids he just says it in chat or
even in a video meeting and gets them. I think webex meetings work better than
real live ones. If they are tiring that's positive because meetings last too
long. If only one person can speak at a time it prevents people from
interrupting and makes them conscious not to hog the mic. Async communication?
How would you do that? If you have a question and can't find an answer, what
do you do? Make a jira user story to document this specific scenario and put
yourself as the reporting too? Then assign to a colleague and hope he does
something with it? I mean it could possibly work if everyone is accustomed to
it, is of a very high level and is also a high level technical writer. But it
just seems to me that in practice junior might be too dumb to understand
seniors writing. Or senior just writes something that's not legible. Or senior
ignores his new assigned story because junior created it and not the product
owner. Or scrum master sees the story and thinks: that's not part of sprint
goals and throws it out of the board. It seems really slow to work this way.

~~~
eXpl0it3r
I think it really depends on the project size and the kind of work. If you're
more in a waterfall model, where the specs are clear and you just got to do
it, I can understand how being able to work uninterrupted is a nice-to-have.

But if you work very closely with the business and often run into things that
could be done or understood in different ways, having to wait a day or more to
get a clarifying response would not work. And this is know-how that can't be
written down easily if at all, since a lot of decisions are purely based on
experience and historical knowledge.

I used to have this illusionary vision of how everything should be neatly
documented, but if you operate on a constantly changing code base, it's really
hard to find a good balance. Documentation gets outdated every few weeks and
sometimes days, plus most of the time, you don't even know that said
documentation has been written. As such, you can't fully trust the
documentation and you always have to check out at least part of the code.

What seems to work for me, is documentation that gives a broad overview of a
topic and then gives certain pointers into the code. That way you capture the
essence of functionality that is likely to remain for a longer time and the
transition from documentation to code is made easier.

And finally, if someone is stuck or doesn't understand something, I find it
problematic to have the expectation that nobody may be available to read your
message for the next few hours or whole day. What is more efficient, someone
spending a couple of minutes to provide assistance or someone googling/search
Jira/wiki/Confluence for half a day and not making any progress?

------
throwdbaaway
Chat is only problematic if all you have is slack, with the lousy threading
UX, and the prevalence of DM and private channel.

Still, slack is miles better than wiki pages (go staled immediately), emails
(even more broken threading interface), and heaven forbids google docs
(impossible for collaboration, may work for bosses).

I think the best solution is something like zulip chat, complemented by wiki
pages for "immutable" information.

------
lbotos
I gave a talk on this idea few years ago, that even just the _metadata_ of
slack messages was enough to make improvements to process. As a support
engineer it was useful for us to see when we were asking questions in slack,
what the patterns were to improve our team training:

Ticket comes in -> we don't know -> we link to ticket in X channel. Tally the
channel links, look at chart, identify patterns.

In an office, this would require me to be an EXTREME micro manager, whereas
remotely, I just paid attention and used the meta data to drive our training.

In an office, you could ask the team to keep track, or to tell you what they
noticed, but by having a direct tap into the data stream, the team just does
the work.

(This requires a high degree of trust, and we were looking _inward_ so it
wasn't something that was met with disdain. If we were using this to compare
what teams were more responsive and being outwardly critical, well, I don't
think that will go over well anywhere.)

------
Buttons840
> participants need to be competent at writing and reading prose (it’s harder
> than it sounds)

In my experience, around 1/3rd of developers are not good typists. Writing
code isn't really about typing, so it's OK, but when participating in an
active conversation in a chat room with multiple people, not being able to
type well hurts.

------
cborenstein
A strength (and weakness) of async is that it comes with a higher expectation
of writing quality.

When the expectations are too high, it's likely that people won't get things
down in the first place.

My team has noticed an unintuitive approach to communication that seems to
work better than alternatives. Write better private notes.

Private notes are low-friction. You know what's worth writing. You don't need
to worry as much about if it's a mess.

Our approach is to help you make your private notes a little better organized.
And to make it fast to share these notes when they might be helpful to someone
else too.

It's bytebase.io. Would love the community's feedback.

------
DenisM
We're finding it quite effective to record short 2-minute videos and circulate
those. Everyone can talk and point things on the screen, not everyone can
write or even read attentively.

~~~
mwcampbell
> Everyone can talk and point things on the screen

I think you may be making some unconscious assumptions about everyone having
the same abilities. Deaf or mute people can't talk. Blind people can't point
at things on a screen. And even people who _can_ talk might be more
comfortable writing, e.g. people who are self-conscious about their accent.

For these reasons, I think that the recent increase in remote work, though
forced on us by the pandemic, gives us an opportunity to better include people
who might be inadvertently excluded in an on-site environment.

~~~
mwcampbell
On further reflection, I believe I responded uncharitably to the GP, by taking
the quoted part of that comment out of context. The GP most likely meant that
everyone _on their team_ can talk and point at things on the screen. In that
case, doing videos like that is fine, except that the team should be prepared
to adapt if anyone who can't use that method of communication joins the team.

------
VectorLock
I've noticed the biggest difference between junior developers and more
experienced individuals is their written communication abilities. This has led
me down the path of trying to find resources to help teach communications to
those that I mentor but since this isn't my area of expertise (teaching
communications) I'd love if anybody had resources to share.

~~~
ilaksh
I'm not an expert on teaching communications but I personally don't believe we
need to be an expert to figure out how people can increase their
communications skills. Its like anything else. They have to practice, and get
correction when they do something wrong.

A big part of it is habit or level of effort.

Force them to read books. Maybe something fun like a genre of novel that they
like. Because the fundamental level of literacy is going to have a big impact
on writing ability.

Have them find a forum of subreddit that they like and then regularly
participate in it. And then offline or in a private message, fix their grammar
and point out the problems with their communication.

Or just have them use written communications at work rather than in-person
meetings etc. And then when the communication is lacking, point out the
specific flaws.

~~~
VectorLock
Practices is great and all, thats how I learned, but I'd know there have to be
resources out there to help people learn beyond simply "figure it out as you
go."

------
chiefalchemist
Communication is a super power. Full stop.

The key to communication is to remember: "It's not what you say, it's what
they hear." (Note: say can be written, and hear therefore read.) The mantra
works either way.

Ultimately, the responsibility of the communication belongs to the sender.
Improvement still takes work, but you'll progress faster if you have this
foundation.

------
siculars
People ask me what do they need to be good at to work at Google. I jokingly
(but kind of seriously) tell them it's just like grade school - reading and
writing. 80% of the job is reading, editing and commenting on docs people
wrote or writing docs people will read.

------
brongondwana
I agree with this so much that I even wrote about it recently!

[https://fastmail.blog/2020/05/22/email-for-remote-
productivi...](https://fastmail.blog/2020/05/22/email-for-remote-
productivity/)

Snir David writes well. One point that I think is missed in the "chats and
video calls" is that you don't have situational awareness of whether the other
person is busy like you do in person.

It's the same as the problem with taking phone calls when driving a car as
compared to talking to people who are in the car with you. The people in the
car with you can see when you're in a tricky traffic situation. The caller,
not so much.

------
adolforismos
"The Mongol Empire was the largest contiguous land empire in history. It
started with the unification of Mongolia in 1206 and territory of 4 million
km² ruled by Genghis Khan, to have 35 million km² in 1279 under Emperor Kublai
Khan."

"Here is the thing: all that remote work in one of the biggest empires in
history was accomplished without videoconferencing."

 _Why Videoconferencing Is for Rookies_ [https://medium.com/swlh/why-video-
conferencing-is-for-rookie...](https://medium.com/swlh/why-video-conferencing-
is-for-rookies-8a03f0ed534c)

------
jugg1es
In my experience, the people most averse to writing stuff down are usually the
remote engineers. Remote workers don't typically have the same cultural
influence as local employees, so they tend to be somewhat alienated and
therefore have fewer expectations put on them. I think this disincentivizes
remote workers from fully assimilating into the culture and leads to less
interest in communication. Inevitably, this ends up affecting their
willingness to properly document.

Just my opinion built on my anecdotal experience.

~~~
Benjammer
I have the exact opposite anecdotal experience. Remote engineers I've worked
with have put a lot more effort into their writing because they understand
that it's one of their only avenues to participate in the company
communication culture.

------
domsom
Picking the Slack / Chat argument: I don't think it should be expected to
reply immediately. It's more like a lightweight inbox (when being tagged /
DMed) that's easy to reply to (no greeting/regards required). Channels are a
great place for async discussions that can be linked to and are kind of public
so noone needs to decide beforehand whom to engage, and everyone can decide to
join or leave the discussion without being cc'd forever.

------
naveedn
I have been thinking about the same problem as the author, but I’ve reached
vastly different conclusions about how to do remote work better.Polar
opposite.

I wrote my opinion here: [https://www.naveed.dev/posts/consider-xp-for-
distributed-tea...](https://www.naveed.dev/posts/consider-xp-for-distributed-
teams)

However, I think his points are thought provoking, and it’s interesting to see
how someone else thinks about the problem.

------
mister_hn
Async writing is powerful but unfortunately, it requires also dedicated time
slots to achieve it.

When you have the constant pressure from management to do X instead of writing
on Y in a limited time, then you have no chance to write beautiful,
centralised information. And so, the company itself accumulates technical
debt, looses history and precious information that might be speed up people in
the future.

------
phendrenad2
There's a reason Technical Writing is a class offered in engineering courses
in college. When you've read good documentation (HP user manuals from the 90s)
and bad documentation (most open-source projects, no judgement, they're
crowdsourced and we're lucky to have contributors willing to document things
at all), you really get a sense for how valuable this skill is.

------
abhayb
The super power I see is not so much written communication as intentional
communication. I try to get myself to communicate intentionally by having
command-enter send my Slack messages. But sometimes you need to Do the Thing.
And you can't afford to Intend to Do the Thing first. In those situations the
speed of spoken-face-to-face makes the organizational debt worth it.

------
ezoe
The problem is, most people don't have enough literacy and practicing to
communicate via text. Most of them appear to be able to read and write text,
but they are not. They simply recognize the few keywords and pretend they
understand it.

That's why most of the people, after remote work become the norm, fallback to
inefficient video chat rather than efficient text chat.

~~~
andykx
It is possible to convey much more nuance through speech.

I like to think of myself as an effective writer. Nonetheless, it is
incredibly difficult to express nuanced emotions through writing. This is
particularly true in “professional” contexts, where an informal message may be
perceived as rude. In many situations, I suspect that the same message,
delivered verbally, would not even warrant a second thought.

The reality is that few people are taught to write in a manner that allows
them to actually express their feelings. The fact that we even need to learn
this indicates to me that speech is a far more effective way of getting our
thoughts across

------
devxpy
Written communication will also give you RSI though

------
arminiusreturns
I am surrounded by people who love to do voice and video meetings, and I find
them taxing and not very efficient. I've been hearing a lot about
communication in this remote work covid world, but I've seen that turn into
more of these comms that I don't want.

I need to find a way to tactfully say I prefer text...

------
watwut
We found it faster to call and speak

------
ChrisMarshallNY
My biggest issue (and it is an issue that has been brought to my attention),
is the old "Emperor Joseph" issue:

 _" Too many words."_

I trend prolix. In my essays, this can be corrected by post-edit, but it is
not so easy to do that in realtime.

------
johndoe42377
So, writing rfcs, standards, articles and Usenet (boomer's tech, you know) was
not that bad after all?

The absurdity of synchronous realtime communication is most evident when
taking to an extreme of online coding. Nothing but crap is being produced.

[https://karma-engineering.com/lab/wiki/Remote](https://karma-
engineering.com/lab/wiki/Remote)

------
m0llusk
Nonwritten communication is unreliable. People often have different
interpretations of what was said and what exactly should be done. The only way
to reliably manage work is to have everything written down.

------
rogerkirkness
Fundamentally, it's faster to write and type than it is to talk and listen.

~~~
nine_k
It hugely depends on one's competence in writing, and one's style of thinking.

------
tabbott
The author did a really good job of articulating why I've spent the last
several years working on Zulip despite there being a thousand Slack clones to
choose from.

Asynchronous communication is essential to being able to focus, at least if
you do enough communication that it matters how you communicate. And it's very
inefficient to do asynchronous communication at scale in Slack or any of its
copycats. This leads to the Slack cultural issues detailed in the post;
they're the result of people working around the bad core workflow of a
beautiful, masterfully marketed tool.

Consider "Everybody expects an immediate response" culture. In my view, that
is people adapting to it being unpleasant to be a busy person waiting for a
reply in a Slack channel. (Which is because it's miserable to make sure you
don't miss things in busy slack channel, so everyone does, so anyone who wants
to be sure of a response spams PMs and mentions and otherwise applies pressure
to get a reply now now now so that they can mentally move on to their next
task).

Zulip aims to make asynchronous communication so efficient that such
adaptations are unnecessary. The core innovation is that all messages in
channels are organized within "topics", which work exactly like the Subject
field in email. This model works great for enabling asynchronous communication
in email, and it works even better in Zulip (mainly because of topic editing
and linking features).

The main goal of Zulip's interaction design is to make skimming hundreds or
thousands of Zulip messages (and replying thoughtfully to the ones where you
can add something!) pleasant. This enables a better way of working.
Personally, I read and respond to 500-1000 Zulip messages sent by dozens of
people across 50+ topics every single day, and I get compliments on how
responsive I am, despite the fact that I do focus work in multi-hour blocks
most days, Zulip's development community is all over the world, and I lose
hours of productive time every day due to a chronic illness. This wouldn't be
possible with Slack.

And this isn't just my experience; I've heard from so many people in
organizations that switched to Zulip that they love how Zulip makes better use
of the limited time they have (whether busy managers at companies or
participants in part-time communities).

> "You'll lose your history"

This is the other major bundle of problems that Zulip's topics solve. Zulip
can be a valuable knowledge store because of the organization provided by
topics (combined with features like permanent links and topic-powered search
workflows).

Zulip is 100% open source software (Not open core! We're intentionally not VC-
backed so that we can prioritize our values; see
[https://news.ycombinator.com/item?id=23102430](https://news.ycombinator.com/item?id=23102430)).
And we sponsor free hosting on zulip.com for open source projects, academic
research, and other non-commercial organizations.

------
livealife
Sometimes you need instant answer. You just can't move forward. Then it
requires documentation written 'properly'.

Honestly finding programmers with good writing skills too is difficult.

------
baron816
How do you get your coworkers to start proofreading what they write?

------
_curious_
_Effective_ written communication is remote work super power

~~~
ggurgone
that! I wrote something on the same lines [https://giuseppegurgone.com/remote-
work-communication/](https://giuseppegurgone.com/remote-work-communication/)

~~~
_curious_
I read it and I like it, thanks for sharing. Though I do hold the unpopular
opinion that slack is antithetical to effective communication methods/mediums.

~~~
ggurgone
yes I agree

------
techbio
The discoverability of written thought decreases with its quantity.

It comes down to knowing your sources, not relying on some Bacon number of
reinforced echoes.

------
tomplayford
Not everyone finds written comms as easy as everyone else.

absolutely +1 to keeping records, but as a form of communication it's not
terribly equal.

~~~
RHSeeger
I'm not sure I follow that statement. I can see an argument that text is not
strictly better than verbal communication but, at worst, I'd say it's equal
(for people as a whole, not for one person in particular). Some people are
better at written communication while some are better at verbal.

~~~
tomplayford
For most people, I'll happily agree with you. From a dyslexic's perspective,
being forced to only ever present one's ideas and thoughts in text is pretty
restricive.

~~~
RHSeeger
And that's fair.. for a dyslexic, written communication is worse. I wasn't
trying to imply that, for all people, which medium is better varies for each
individual. I was trying to say that, over the set of all people, which medium
is better tends to vary by person. That neither medium is "better" for
everyone.

~~~
tomplayford
+1 - we're in complete agreement.

------
ChicagoDave
Except no one actually reads emails anymore.

------
mcsoft
Finally, someone came up with a good wording for 'Slack is #1 productivity
killer'.

------
sabujp
i find that i spend 3x more time explaining something through writing than
through a quick chat

------
AceyMan
except for Slack | Teams | its ilk

next question.

/me: an expert writer who sees no change on the horizon

------
ilaksh
Agree with the headline. Good written communication is a requirement for a
software development project. But I am not sure about all of his ideas in all
circumstances. In particular in relation to a very small dev team and small
client group. In terms of something different like for example an open-source
piece of software on github, issue trackers are key.

However, for a small sort of private project. For example, if you have a very
small team and can get people in a chat room consistently so that you can have
solid conversations every day in there, that has worked better for me than
using some kind of issue tracker. Especially in terms of dealing with clients
or business-related team members. And maybe its really only for very small
projects, like one or two developers, I don't know.

But for me, with most of the projects that I have been on my own building a
product or tool for a client, the issue trackers and things like that worked
against me and the project as far as I could tell:

\- People would seem to think it was their job to fill the board/tracker up
with as many things as they could think of. This caused extra stress and
tended to make me want to rush through things to get them out of the way. The
biggest problem with that was that it took time away from the really important
things. And it is very difficult to get people to give realistic priorities.

\- Sometimes, people would write critical information in the issue tracker or
board, and I did not realize it had been updated or how critical it was. And
so they operate with the assumption that they have communicated something, but
actually I didn't see it until two days later.

\- When they have a place to put an infinite number of tasks, it encourages
them to increase the scope of the project, without having a real discussion or
necessarily even thinking the feature through.

For me when doing projects on my own (or maybe with a designer) for a specific
small group, there is just a limited amount of stuff that I can realistically
finish in a given time frame. So I actually will not allow an issue tracker or
board and try to get everyone to show up sort of simultaneously in a chat
room. Sometimes people cannot or will not do that, and in those cases
sometimes a phone call can work. Or maybe they actually are capable of reading
and writing async messages in the chat room (not very common).

Basically every few days I meet in the chat or phone or whatever with the
client and discuss what I have been working on in the last few days, walk them
through the updates to the application. So something is being delivered and
tested by the client every week or even every few days. Then we specifically
talk about exactly what is the priority for the next few days. If there is
development work that needs to be caught up on, then there may not be any new
features to work on. Or there may be a feature that has been in progress, and
the client gets an update on that.

Often the client has ideas for new features. Instead of putting them in a
board or issue tracker to pile up, when they bring them up, we decide whether
they are now higher priorities than other existing items and will fit into the
work load of the next few days. Or, I tell them to remind me later. There is
no such thing as a task that I will "get to when I have time". I have the
client focus on the next most important priority and/or I explain the ongoing
dev work, and we work out like 2-5 days of work and that's it. There is no
infinitely expanding list of things to get to later. If something he has been
thinking about is really important, it becomes a priority as soon as the
previous task is completed. We check if I implemented something correctly as
soon as it is implemented. We don't have to refer to a database of things,
because we just talked about it a couple of days before.

------
rakoo
Interestingly, I've been thinking about organization at work and I feel like
there are many forms of async communications that should or could be merged,
because of how common they are. We need to communicate announcements, ask for
opinions on changes, document a process, list relevant steps to a change that
is happening, ...

In my mind there are multiple goals a perfect system should have:

\- Must be easy to create a new "conversation" \- Must be possible to write
long form content in a "post", where "post" is the first item in a
conversation \- Must be able to have a meaningful conversation with replies to
specific points \- Must be able to change the content of the "post" based on
the discussion that happened (such that a "post" can be a poll, participants
discuss options, and the final decision is summarized) \- Must be able to
easily enter and exit the full conversation \- Must be able to easily link the
full conversation, for referencing \- Must be able to set metadata (dates,
relevant people, status, stuff like that)

We have many systems, but none really fits the bill:

\- Email is probably the worst, because you can't modify the original message,
you can't link to it and you can't transparently enter the conversation if you
weren't part of it initially. We've all seen the "adding XYZ to the loop" that
provide 0 content to the conversation. There's also the whole issue about top-
posting and lack of proper threading that make having a conversation
difficult. Probably just a client issue rather than a protocol issue though \-
NNTP is a step above, but ironically because it has remained niche the clients
and the etiquette help having a proper conversation. Still doesn't fill the
bill \- Ticket systems are paradoxically pretty good for this situation. They
do contain the necessary structure for incorporating metadata, in all the
various forms ingenuity can come up with.... sometimes too much ingenuity,
such as the labels and fields and knobs that were needed for that project
years ago are still here, cluttering a lot of space because most aren't
actually needed anyway. Imagine using such a mess \- A wiki is nice, but the
emphasis on structuring is detrimental for flows that go outside of
documenting. Sometimes you just want a linear list of conversations ordered by
date \- Google docs and associated are good for really long forms for the
initial "post", but are not very good at structured conversation

Perhaps the best software, for all those use cases, is a forum software. I'm
partial to the (old) reddit UX or the HN UX; remove the useless voting and
it's almost the perfect way to communicate. The interface gives you the space
to actually take time about what you want to say and properly articulate it.
HN is a bit terse here, reddit gives you formatting helps to nicely present
your ideas and makes reading it easier.

Only drawback is that they are text only, and sometimes you need to include
non-text (a screenshot of the planned changes, a video of the flow to
document, a map of the place you're discussing about, ...)

(If it is not clear already, I'm still sad at the death of Google Wave. 10
years later and it's still the future:
[https://www.youtube.com/watch?v=p6pgxLaDdQw](https://www.youtube.com/watch?v=p6pgxLaDdQw))

------
zawaideh
would be nice to use "they" or alternate between "he" and "she" in the post.
Otherwise, it's a great post

------
oDot
I wrote Emergency Remote[0] for companies thrown into remote due to the
situation.

From my experience, it seems that the reason companies use sync communication
and "emulating" an office is not because they don't understand the benefits of
async, but because of the required discipline.

Fortunately, that discipline is required vastly more of the initiator of the
conversation. This allows the recipient to quite easily refuse sync
communication. This way employees can help each other out and get used to
async.

[0]:
[https://www.emergencyremote.com/EmergencyRemote.pdf](https://www.emergencyremote.com/EmergencyRemote.pdf)

