One of the greatest advantages that remote-first companies have is that work happens asynchronously. I lead to a culture of writing things down. It allows teams to be flexible between working styles and time-zones (up to a point). It creates a more equitable environment regardless of physical location.
Despite the advantages, setting up an asynchronous working process can be tricky. Here’s a few simple playbooks to follow.
This is a work in progress!
Running a project
If you’re running a project and the team works asynchronously, here’s what you need to do.
- Write a project brief Take the first stab at answering a key question. Talk to people as needed to get the information you need and be sure you have an initial answer.
- Share a link to the document in public channels, tag specific people for feedback, and ask that all feedback is added as comments to the document Comments in a document are naturally asynchronous. They act as an inbox for feedback and there should be no expectation that they will be answered immediately. If you get other feedback in Slack for example, direct people to add it to the doc (conversations get lost, are more synchronous, and chat apps are not a good place to find things later).
- Resolve the comments, have ad-hoc discussions as needed to gather more input Be editorial. Resolve what is necessary and decide what you won’t address. Anyone should be able to give feedback, but that doesn’t mean everything needs to be resolved.
- If you are unable to make all of the decisions, hold a meeting to resolve them and kick off the project
Saving meetings for the end of the process reserved for making decisions (if needed) leads to a more inclusive environment. The interface for providing feedback is clear and avoids the tyranny of structurelessness.
Even better, you now have a document you can reference as the project progresses and point people to if they have questions. (Documents are better than people at answering questions).