Working asynchronously
blog.remote.com
Working asynchronously
1–10 of 110 posts
Re: Working asynchronously
#2Even 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
#3Looks like it's time to go job-hunting again, but I hate job interviews. Dammit.
Re: Working asynchronously
#4I 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…
Re: Working asynchronously
#5Re: Working asynchronously
#6I 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
#7I 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
#8I 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
#9When 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.