The Benefits of Asynchronous Collaboration
December 5, 2016For the last few years, I’ve worked remotely. I wrote down some thoughts after about a year of working remotely. There was also the time I worked remotely during my first session of vanlife. In preparation for making the change to remote work, I read Remote: Office Not Required.
One of the ideas of the book is asynchronous collaboration. I wanted to discuss that idea a bit more and mention how it’s affected my life.
Work as a developer is made up of periods of hurry-up-and-wait. You have work to do after waiting on requirements, project management, and design. After your work is complete, there’s a process of QA and acceptance by product owners. From project-to-project, team-to-team, and company-to-company, those steps are different. They’re still there in one form or another. Whether you’re working in a waterfall system or some flavor of agile, those phases exist. They’re there if informal or not.
When I have a variety of tasks on my plate, I can use an asynchronous approach to avoid the waiting part. “Finished this new feature and need to have the designer or project manager check it out? No problem, I’ll send it to them and then get started on the next thing while I wait for their feedback.” This works well with remote teams because you never really know when someone might be working. Instead of waiting on them, you can move onto something new. Even when I’m not remote, I’ve used this technique with clients who are in a different location as well.
Waiting is pure waste, and the goal is to avoid that as much as possible. Waiting isn’t resting. Resting is stepping away from the task at hand and no longer focusing on it. Waiting maintains focus without the benefits that come with rest.
If you’re in the same office, this workflow is also more useful. Instead of interrupting the current work of a pm, you can send them the update to look at later. And instead of interrupting your next task with their response, they can send it to you peruse when you’re free. For me, interruptions are the biggest source of inefficiency. That creates stress and irritation. They’re necessary sometimes for emergencies, etc, but should be avoided in nearly all cases.
While multiple different tasks may not seem the ideal, you’re not juggling them. You’re not switching back and forth often. Instead you’re switching to a new task when you would’ve been waiting. This might make creating detailed project forecasts more difficult. However, having an accurate forecast is a never-ending problem in software development. It’s hard to predict the unknown. This way you can at least get as much productivity out of everyone and eliminate some of the unknown.
This is all biased towards my experience as a developer. But it should apply to someone who’s a designer, project manager, tester, etc. Management, especially upper management, will always be different to some extent. However, their ultimate goal is getting the most out of people. Asynchronous work helps with that.
