Live data from Hacker News

Working asynchronously

blog.remote.com

1–10 of 110 posts

Re: Working asynchronously

#2
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.

Re: Working asynchronously

#3
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.

Re: Working asynchronously

#4

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 ex…

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).

Re: Working asynchronously

#6

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.

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

Re: Working asynchronously

#7
post #4

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 ex…

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).

Do you use a tool for this?

Re: Working asynchronously

#8

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.

If only job interviews could be async!

Re: Working asynchronously

#9
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.

Re: Working asynchronously

#10
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...
Post reply on HN