A couple months ago I wrote about my experience working all-remotely. The world has changed since then, and narrative on remote work has gone from: "this might be a good idea" to "we are implementing this NOW!"
I'd like to thank GitLab's CEO, Sid Sijbrandij, for promoting not only All-Remote work, but our Family and Friends first policy with our second Family and Friends day. I'm using some of that time to finish up this post. If you are new to remote work, you might want to look at GitLab's Guide to All-Remote.
I want to revisit one remote working topic, which was probably the most difficult for me to embrace as a first time all-remote manager -- but will become more critical as employees are simultaneously working from home and caring for their children -- working asynchronously.
Synchronous vs asynchronous
Simply, and I'm borrowing from Google's dictionary here, asynchronous means, "not happening at the same time."
Asynchronous is the opposite of synchronous communications which include a face-to-face discussion -- the communication between all parties is happening simultaneously. Other synchronous examples include telephone calls (hi Mom!), video conferences, and, potentially, text messaging.
An example of asynchronous communication would be listening to a pre-recorded podcast. The listener is consuming the information at a different time than when it was recorded. E-mail is another example.
Working asynchronous means preferring asynchronous communication over synchronous. Collaboration means making a request and not getting or expecting an immediate response.
Don't set working hours
If it is your first time managing a remote team, especially if the team is working in the same timezone, it is tempting to set core working hours -- for instance requiring the team to be online from 10AM-4PM. Unless you are working in an environment which requires hands-on monitoring (for instance production or customer services), I would recommend fighting this urge.
I work with people widely distributed, so it isn't feasible for us to work overlapping hours. I also personally work what I call a non-contiguous day. I rarely work full day in a solid block, so my day might not even overlap with people in my own timezone.
When you assume that others will not be working when you are, then asynchronous communication becomes more natural.
Meetings are social
When I first started managing an all-remote team my instinct was to fallback on synchronous video calls -- I will admit to being a reformed Power Point jockey. Someone from outside GitLab asked me, "if all work happens asynchronously, why do you still have video conference meetings?"
I now consider meetings as important for their social aspects -- rather than a venue for collaboration or decision making. You may need to bring awareness to a process change, or outside decision, but I overall I feel like meetings are useful for feeling I "know" someone better because I see their face and hear their voice.
Keep synchronous meetings short, have an agenda, and mostly reference tools and documents where the real decision making is happening.
Latency
Asynchronous work implies latency in communication -- you might not get an answer to an inquiry right away if your counterpart is sleep or otherwise unavailable. Latency in communication takes some adjusting to, but I'd argue that requiring employees to always be available to reply to any request synchronously can add to undue stress.
Unless you are dealing with a critical system failure, in my experience, an immediate response is almost never required. Unfortunately increased latency can mean working on multiple tasks simultaneously so not to become blocked on one thread of communication.
This is the most significant drawback to working asynchronously. It often requires that most employees, including engineers, have multiple projects or moving forward simultaneously. Fortunately modern tools enable quick context switches, but working on multiple projects can increase cognitive load in already demanding roles. I recommend focusing on one task and not context switching when notified by a colleague, but when it is convenient.
Use asynchronous tools
Decisions and conversations around work items should be discussed, documented, and preserved. Document management, wiki, issue tracking, and source control systems allow teammates to collaborate without having to participate at the same time. Prefer these systems over synchronous tools like video conferencing and chat.
Over communicate
I suspect one of the reasons managers are afraid to embrace asynchronous communication is loss of hidden context in office chatter -- they have a sense of what is happening based on what their team and others around them are saying. But I'd argue it isn't effective to depend informal, undocumented, communication.
Since asynchronous companies are missing the informal communication channels and context that the office provides, I encourage my team to over communicate what they are working on, problems they are having, and status. You aren't going to be able to visible see that a team mate is frustrated, but I encourage team members to speak up when they unable to solve a problem on their own. That could happen in the messaging system or
Staying the course
I will admit the number of synchronous meetings I have are piling up. I think most are there, as I mentioned earlier, to provide social context, but I've noticed when the pressure to deliver increases, so does the tendency to go return to synchronous management. I feel like this is a crutch, and something I'm actively improve in my management style. I firmly believe individuals do their best work when they are able to work at their own conveniece rather than the convenience of management.