When working in a distributed setting, moving towards async practices is the last level-up. And it’s not easy. Especially not if you’re someone who’s been working in an office setting your entire life. It will take time and effort to become an excellent async communicator. And writing. A whole lot of writing.
It’s way too easy to simply send a message on Slack to someone without giving it the time and attention it needs. To counter that impulse in me, I’ve got five guiding principles that I try to live by when communicating async.
1. Give context
When you talk to someone, you are right there to answer any questions that they might have about why you ended up in this situation. You don’t have that luxury when communicating async. That is why you need to assume that people have minimal context on your problem. Start your message by laying out why you’re working on this and what got you to where you are. That way, you and the receiver will be on equal footing, and you can avoid a lot of misunderstandings.
2. Provide enough information to cover most follow-up questions
When you have described your problem in a low-context way and posed your questions — try to think of any questions that the receiver might have and respond to them before they have to ask them. This can often include “did you think about X”. If you did, and decided it wasn’t a good idea, let them know upfront. “We considered X but decided against it because of Y” is often enough.
3. Include all the resources needed
If you have links, images, or other supporting material, make sure to include it. It might be a link to an article or a screenshot of a change you made. The more material, the better. Again, think low-context.
4. Express your need clearly
To get the help you need, it’s a good idea to be very clear about what that is. Don’t assume that the receiver understands what you’re asking for; say it in explicit terms. Example:
I need your help to understand if there’s anything else I should add before sending this to the user.
5. Include a deadline
Since async communication is open-ended, it’s important that you clearly state when you need a response. If you have a default way forward, include that too.
I would appreciate it if you could have a response ready for me no later than Friday at 13.00. My intention is to use the first option unless we conclude that one of the other options are better.