
Working asynchronously - marcelo_lebre
https://blog.remote.com/why-you-should-be-doing-async-work/
======
PragmaticPulp
I've managed multiple remote, asynchronous teams across multiple countries.
When people work in opposite time zones, asynchronous communication is
mandatory.

When it works, it's a great experience. However, async communication isn't
appropriate for every situation, as the article admits. Some times, the most
efficient way forward is to schedule a call where all parties can work out the
solution in 15 minutes of real-time conversation rather than 3 days of back-
and-forth e-mails. If the team is willing to fall back to synchronous comms
when necessary, then defaulting to async communication for the other 95% of
communication can work.

In my experience, the biggest pitfall is when developers try to force 100%
asynchronous communication at all costs, no matter how slow and inefficient it
becomes for everyone else. All team members must be willing to recognize when
synchronous communication is necessary and carve out 15 minutes to an hour a
couple times a week for those important, synchronous conversations.

Efficient communication is everyone's responsibility, and asynchronous
communication is only a win if it doesn't create unnecessary extra work for
everyone else.

~~~
coldtea
> _When it works, it 's a great experience. However, async communication isn't
> appropriate for every situation, as the article admits. Some times, the most
> efficient way forward is to schedule a call where all parties can work out
> the solution in 15 minutes of real-time conversation rather than 3 days of
> back-and-forth e-mails._

I always hated "15 minutes of real-time conversation", not because of being an
introvert or anything, but because it's fuzzy, nobody remembers what it was
exactly said, and usually ends up with people wasting each others time (like
Diltert-style meetings).

I'd much rather people knew how to communicate effectively on chat.

But people don't, so you get messages like:

"The service is broken!"

"[panicked] What do you mean? Is it down?"

"It doesn't show anything"

[still panicked] Really? Let me see... Hmm, I see it working properly, loaded
the first page and everything. What do you see?"

"I don't see anything"

"[???] On the first page? On some specific panel? Have you entered something?"

"Entered? I clicked and got nothing"

... and after 20 more minutes you realize they are on the third tab of a
particular page, which nobody ever uses, have entered some search term people
seldom enter, and got no results there, and everything else is working fine...

~~~
jerf
"I always hated "15 minutes of real-time conversation", not because of being
an introvert or anything, but because it's fuzzy, nobody remembers what it was
exactly said, and usually ends up with people wasting each others time (like
Diltert-style meetings)."

I'd say the solution is to attack those problems directly.

There are some things that just work poorly asynchronously. I find heavy-duty
explanations of something, where you need the highly-interactive back-and-
forth is necessary, and honestly, even just trying to type something is
wasting minutes vs. saying it, is a common use case for me. Getting 4 half-
distracted managers who are lobbing emails at each other into a quick
conference to resolve the matter is sometimes a really good idea, too, because
the "lobbing emails at each other" is a political minefield. A lot of
potential for hurt feelings and miscommunication that can be avoided just
getting everyone in live voice chat, with their full attention, for even just
5 minutes sometimes.

~~~
serpix
4 managers to one dev is a ratio that warrants a very quick change of jobs.

~~~
jerf
No, I mean, some sort of cross-team functionality where you need broad
agreement, not four managers all trying to manage literally the same thing.

I probably do more cross-team stuff than the average dev, but in anything
beyond a trivially-sized organization, managers are doing it all the time.

------
alexandercrohde
I want to call BS on the statement "Most meetings can be replaced with
documentation." Maybe in an ideal world, but no.

Have you tried reading the documentation the average engineer makes? It's like
a freshman essay -- lacking in cohesion, vision, context. It's usually
completely unstandardized across teams.

And 9 times out of 10 the most fundamental questions aren't answered by the
documentation e.g. "Why don't we just use existing tool X to solve this
problem?"

Communication is hard. Engineers use buzzwords. Product uses buzzwords.
Companies use buzzwords. Combine all these and you get a soup of overloaded
terms e.g. "service," "connect," "access," "resource," "platform" that have a
wide range of potential meanings.

~~~
tonyarkles
This is tongue firmly in cheek, but I think it really drives home your
"Communication is hard" point.

Have you tried reading the meeting agenda and minutes the average engineering
manager makes? It's like a freshman essay -- lacking in cohesion, vision,
context. It's usually completely unstandardized across teams.

And 9 times out of 10 the most fundamental questions aren't answered in the
meetings e.g. "Why don't we just use existing tool X to solve this problem?"

~~~
thrower123
Agenda? Minutes? I've heard tell of such a thing, but I've yet to meet a
manager that actually performs these arcane acts. I've gotten very used to
walking into meetings with no more idea of what's going to happen than I can
glean from the participants list and the subject on the calendar item...

~~~
scruple
Oh, cool, we must work together.

I pushed my team hard to get some discipline around meeting agendas. It lasted
for a week or two. I threatened to stop attending meetings otherwise. My
Director told me to knock it off. So, the signal is clear, right? We're all
just fucking around and playing pretend at being professionals.

------
omarhaneef
I feel like there is an insight here about working by yourself, too, that I
cannot quite put my finger on.

Even if there is no team, you don't want to self-interrupt your own work.
Well, we know that hence we invest in internet blockers etc.

However, if you are interrupted, it is best if you recover quickly. That is to
say, if you can set up your own work so that it is planned in bite size
components, and you know exactly where to pick up, you are better off.

This is like making an outline, and keeping track of where you are in the
outline, except at the level of detail you need (say 5 min increments). Or
perhaps you have a short hand of tracking where you are during an
interruption.

So, if someone says excuse me, you take 12 seconds to quickly note what you
were about to do, and if you are about to self interrupt, you do something
similar.

~~~
epylar
I've learned to take a lot of notes, make frequent checkpoints (e.g., git
commits), and break things down into small pieces, just to deal with
interruption--minute to minute (people asking me questions), day to day (fire
drills, bugs), and week to week (constantly changing priorities).

~~~
omarhaneef
Do you use a tool for this?

~~~
jsharf
I'm not the same person, but I have a small notebook and pen. Any time I think
"Shit, how am I going to remember this if I get interrupted right now?", I
quickly scribble down as much as I can and continue working. This is
invaluable when I do get interrupted.

I do this basically any time I feel like my short-term memory is overwhelmed
with facts, and as a result the notebook has effectively become NVRAM for my
brain.

~~~
omarhaneef
This is the closest to what I do myself -- I always have pen and paper on my
desk -- but the real issue is that I don't take a note when interrupted
because of social pressures (its rude to ignore someone for a few seconds). I
don't even do it for myself for self interruptions because I forget to.

~~~
kelnos
That problem is solved through humility and social graces.

"Hold on a sec, I just wanna write down what I was doing so I don't lose my
place."

If you want to add more, after writing it down, you can follow up with, "sorry
to keep you waiting, but when I get interrupted I often forget some useful
details about what I was working on, and I want to get that down before it
leaves my head".

(The "when I get interrupted" is a bit of a cheeky way to point out " _you_
are imposing on _me_ , so the least you can do is allow me this".)

------
jahbrewski
Not directly related to the post, but something I've been thinking about a
lot:

My life satisfaction and work productivity increased significantly when I
stopped working from home and began working 8-5 at an office. There were so
many things I took for granted:

    
    
      - Face-to-face interaction with co-workers.
      - Casual conversations to break up the day.
      - The rhythm of a commute.
      - Not struggling to find a spot in a crowded coffee shop.
      - The productivity boost of working alongside other people who are working.
      - The consistency and routine of normal working hours.
      - The ability to pair program, in person.
      - The ability to be productive with my team even if the internet is slow (or out completely).
    

I worked from home for six years, and I don't think I'd ever go back. I'm not
saying remote doesn't have its place, but I've found that I greatly prefer
working in-person with other people.

------
gatherhunterer
This is managerial nonsense.

> An even, swift and nimble pipeline produces exactly the right quantity of
> output for its requirements, and all its stages are balanced in terms of
> efficiency and speed. Resulting in no waste of time or resources.

Aside from containing neither a subject nor a verb, this last sentence is an
impossible claim. Anyone who intends to hold the author to the quality of
their reasoning would stop reading there. Only people who can say “upward
revenue stream dynamics” with a straight face will read on.

A single logical sentence has more value than a page full of poorly written
false claims and regurgitated platitudes.

~~~
marcelo_lebre
I've been a manager of different teams for a while now and I must admit that
every form of management or productivity strategy is nothing but written
nonsense in good form - or common sense in fancy terms.

------
bregma
I spend several years managing an all-remote team that ranged from Perth WA to
Seattle WA. We worked 90% pure asynchronously and 10% using video chat (or
physical get-togethers from time to time). It was highly productive, and
because it was all open source development any lack of productivity would have
been obvious.

I now commute to an office where we all work asynchronously but are expected
to appear to work synchronously, as is traditionally expected. It is less
enjoyable, frequently subject to context switches (you need to synchronize
with the dominant worker) and certainly no more productive -- although that's
hard to tell since everything is secret and need-to-know.

I would say working asynchronously is better for intellectual workers. Most
intellectual work places that claim to working syncronously are either working
under an illusion or under a bad manager with a "my synchrony" attitude.

------
laurex
I work on a distributed team on an asynchronous video app (Marco Polo) which
makes a lot of conversations easier (sharing bugs, non-urgent conversations,
personal connection) but we still Zoom for many meetings. Asynch has virtues
even for in person teams but it just isn't optimal for everything, especially
discussions leading to decisions that can then be executed upon.

------
benatkin
I get the idea that remote.com is trying to trademark the term "remote". F
that. The best way to stop that is to prevent remote.com from getting a lot of
brand recognition. I don't care how much they want to contribute to the remote
worker community - there's no way it will make up for stealing the identity
that we have for ourselves.

~~~
xapata
I dunno, it's just clever company naming, like Meetup. I don't think it's
stealing an identity. It's also a risk for the company, because the trademark
isn't defensible. Google's legal team doesn't like the fact that people use
_to google_ as a verb. The extreme form of that would be Microsoft being able
to say, "Now you can google better with Bing!"

~~~
benatkin
Being _remote_ is a lifestyle, where as a meetup is an event, so I think it's
worse than Meetup. The brand Meetup is problematic though. It makes it harder
to talk about events without accidentally dropping the name of a company.
Meetup may have gotten a pass because they've done pretty good, but they are
now driving away their customer base
([https://www.theverge.com/2019/10/15/20893343/meetup-users-
fu...](https://www.theverge.com/2019/10/15/20893343/meetup-users-furious-new-
rsvp-payment-test)). There are also other companies like
[https://remote.co/](https://remote.co/) that are already using the name
_remote_ , but remote.co is respectfully calling themselves remote.co instead
of just _remote_. Having a .com shouldn't be a ticket to appropriate a common
word and turn it into a brand.

~~~
xapata
> Having a .com shouldn't be a ticket to appropriate a common word and turn it
> into a brand

It isn't. You've got to have a great marketing team, too. Remember when UPS
tried to make "Brown" synonymous with UPS? Having the domain name isn't a
prerequisite for that kind of effort.

------
z3ugma
The way we've struck a balance at our company is to only allow meetings in the
mornings. In the afternoon, everyone can be off Slack, heads-down, and
programming or doing other deep work.

This halves the number of timeslots that are available to have time stolen
from you, but allows us to get the empathy and quick resolution that real-time
communication enables.

~~~
0xffff2
I guess it's impossible to please everyone, but I would be miserable with this
setup. I'm far more productive in the mornings and have managed to keep most
of my meetings in the afternoon so they don't interfere with my productive
time. Only allowing meetings in the mornings would probably cut my
productivity in half or more.

------
mlashcorp
This sounds great, and in theory should work on a well integrated team of
autonomous individuals. I guess as in most things, common sense is the key
requirement to make this a reality. Alas, common sense isn't very common...

------
nikisweeting
I find using an asynchronous-first chat platform like Zulip (as opposed to
Slack) is crucial to my ability to work asynchronously. Without
compartmentalization of topics into mutable sub-topics, it becomes a huge
mental burden to log onto chat every day.

------
cpeterso
People hate meetings because they're in bad meetings. We spend so much time in
meetings without giving them much thought to _designing_ them. I highly
recommend the book "The Surprising Science of Meetings: How You Can Lead Your
Team to Peak Performance". It covers different types of meetings, including
remote meetings and when _not_ to have a meeting. This podcast interview with
the author is a good introduction to the book:

[https://www.gayleallen.net/cm-127-steven-rogelberg-on-
making...](https://www.gayleallen.net/cm-127-steven-rogelberg-on-making-
meetings-great/)

------
__s
This is essentially the same problem schedulers run into. It's a latency vs
throughput trade off. The article is underlining that blocking is bad, & lots
of tasks may receive cancellation signals

I've worked in low latency environments, but I prefer high throughput. The
latter is more conducive to flow state. It also means people aren't relying on
my consistency, where some days my brain turns on & some days it doesn't

------
m0zg
What I've discovered is your team needs to be fairly senior already for this
to work at all. I once worked with a team where, shall we say, "talent" was
extremely uneven, and it was pretty miserable. It was a very small team, only
3 people, and one of the 3 saw no issues with "synchronizing" threads with
wait/sleep loops, paid no heed to coding standards, and just in general turned
in shit code others had to waste their time to fix later. Worse yet, he was
extremely defensive about any issues we brought up, to the point of not even
hearing what we actually say. In his mind, any critique of his code was a
personal attack and nothing else. Code reviews were multi-week affairs,
leaving him extremely pissed off, and what got checked in was still below par
compared to what the other 2 devs were producing.

If that person were in the same office, it'd be much easier to browbeat him
into compliance and teach/mentor him. But he was halfway across the globe, so
we suffered through it for ~6 months and then let him go, further reinforcing
his belief he was being personally attacked. Not a good parting of ways.

------
konschubert
I think it’s armful to the idea of remote work that it’s being equated with
async work.

~~~
marcelo_lebre
Async work is but a tool, a methodology, remote is a way of life/work. I
advocated async work when working office-based as well, the same principles
still apply.

~~~
konschubert
Agree, it’s also harmful to async that it’s being equated with remote.

------
davidw
Async communication makes a lot of sense.

Their "async planning" bit doesn't mention context switching though, which is
an important omission.

------
3bodyProblem
There are basically only a few things I agree with in this article, the rest
is so shortsighted and heavily tunnel-visioning about some ideal world.

The thing I agree with, yes being distracted takes time, focus and
productivity. I'm all for being more into more deep work etc. Also the part of
people need to be proactive rings true of course. But I fail to see how
something that evident really needs a graph.

But the issue I take with articles like this is that they think of humans as
robots. That walk in, or sit in front of their computer at 9, type for 8 and
then go home/stop working.

But let's be honest here, If you can keep highly focused for more than 4 hours
a day you are a superhuman. I know keeping this in mind doesn't take anything
away from the article. Yes we should focus more on Async productivity, but
work our work is definitely not single threaded. We are humans, If I hear my
teammate 2 desks over signing for the 3rd time I can do 2 things. Ignore it,
not getting out of my flow. Or stand up, talk to him/her and see whats up.
Maybe it's only a complain about Entity Framework migrations being a b __ __or
perhaps just tired, and gets annoying by small things because something
happened last night and its time to vent a bit.

recently I've started listening to this podcast
[https://hurryslowly.co/](https://hurryslowly.co/) . Although I do not
identify with everything discussed, I do think there is source of truth in a
few episodes. It just makes me consider, are we optimizing the right things
first?

I really wonder, if all this no meetings, no distractions is really the key to
making us more effective at our jobs. You can't really measure it, does the
hour in a meeting really makes you an hour less productive? Is it more like 15
min? Or did the distraction actually helped instead of bashing your head
against the wall for over on hour trying to figure out the solution?

I wonder the same about all those gosu vim/emacs users, it sure looks fancy
dancing with your fingers doing edits. But where does the real work happen? Is
is the amount of lines written or the amount of quality information processed
in my mind about the solution I'm looking for?

In the end..

\- Be human \- Try to have clear borders about distractions in your team \-
Turn all slack notifications off \- Don't have meetings that could have been
an email. \- Don't send emails about stuff that could have been a meeting

I'm really curious about working in a distributed team though, sadly I didn't
really had the chance yet. I think working remote has it own con's and pro's.

I do applause the auther for thinking about this, I think reflecting on how to
work better is always a good idea. But It could also easily be a recipe for a
burnout.

~~~
bwb
I do think you can try to measure it, and we are taking a stab at it with an
app that analyzes your online calendar app, you can see an example report
here: [https://app.shepherd.com/personal-report/sample/pages/my-
wor...](https://app.shepherd.com/personal-report/sample/pages/my-work-life)

It isn't perfect but we try to show how the meetings split apart your day and
your capacity to do deep work.

------
komali2
Great now how do I convince my team this is a good idea, overcoming super
ingrained and traditional working concepts?

~~~
marcelo_lebre
One step at a time. And if that doesn't work, then you find another team ;)

------
crtlaltdel
imo think twice add a “bugs” channel to your slack/chat. it invariably gets
used as a place to inject panicky statements, ask for status and
features...just make sure whatever ticketing system you have is well
understood by all stakeholders.

~~~
mjevans
What you need is a form of moderation. An actual group of workers who's job is
to collect data, validate a test case is reproducible, or at least that
there's telemetry of a problem having happened. In edge cases they could at
least collect some data and try to isolate where a problem might exist so that
better tests / data collection can occur.

------
the-dude
IIRC, remote.com is founded by a Gitlab alumni, funny to see this as #1 with
all the Gitlab outrage going on.

~~~
jobvandervoort
Yep me, together with the author of the post, Marcelo.

------
Porthos9K
I would love to, but my coworkers expect me to be synchronous. They do async,
but I'm always supposed to be sync with five nines availability.

Looks like it's time to go job-hunting again, but I hate job interviews.
Dammit.

~~~
marcelo_lebre
At the end of the day your mental health is worth a lot more than a few
interviews ;)

~~~
GreenJelloShot
Interviewing generally has a significantly negative impact on your mental
health... but at least it's temporary.

