Building and Operating a Remote Company: Calendars

In a previous blog, just as the COVID-19 pandemic was really getting in gear in the US, I wrote about the top advice for employees working from home. I got a lot of good feedback from friends and former colleagues on that blog and I’ve been thinking for a while about doing one from the employer side, so here it is: if you want to build a remote-first team or product, what habits and practices should you get into?

As background, I’ve been working primarily “from home” since about 2015, and managed people as far away as 12 hours in timezone differences while growing highly successful products. I’ve decided to turn these top tips into a blog series now, which you can find in the “Remote Working” category on this blog.

Calendaring & Meetings

TL;DR: Avoid booking meetings. Instead of meetings, write to communicate until latency / bandwidth of writing is unacceptable. Avoid using common overlapping times for meetings unless necessary.

One of the most overlooked and difficult things to get beyond when helping manage a remote-first company/team is meetings. Coming from an office environment, we’re often used to “grabbing a conference room” or “hopping on a call” to expedite information transfer. But if you were in (for example) New York and your colleague was in (for example) Beijing, you of course wouldn’t really expect to grab a conference room or hop on a call for regular 15-30 minute one-off meetings to try to hash something out: it’d be too expensive to ask someone to work the hours that do cross over. This is where a lot of people get stuck/fail and decide that remote working “doesn’t work.” The inability of managers and companies to rectify this has been one of the biggest reasons I’ve seen remote working failing.

One of the most common things newly remote workers — especially in management — try to do is to get an office-like environment by creating geographic centers of specific types of knowledge workers (“people that work on X work in Beijing and people that work on Y work in New York”). This does result in a globally distributed team, but few of the actual benefits of remote working: individual employees still need to largely work the specific local hours (no “take a mental break/exercise time from noon to 2pm, but then pick back up after dinner”) and you’ve now isolated knowledge to specific geographies (and sometimes languages) in a way that’s very difficult to undo.

The best way I’ve found to do this is to try to really push back against all standing meetings: see what can be done asynchronously. Even if a colleague lives in a geographically close area: still see if you can go asynchronous by writing down questions, elaborating where needed, and waiting diligently for a response. This admittedly degrades the bandwidth of individual conversations: verbal conversation is almost always faster than typing and allows you to convey more information than what words alone can often convey in the same time. However, if you go through with this, you are forced into two of the greatest corporate advantages of actually working remote:

  1. Everyone is forced to write things down: how they came to the decision they did, what other relevant details are, appropriate links to further reading, etc. To be clear, this is more work to the producer of such content than hopping on a quick call for 15 minutes to verbally explain. But the advantage is that it can live on: it breaks down information silos instead of building them up, and employees that weren’t around in the initial discussion can get forwarded along a written “from the horse’s mouth” collection of information, which can be invaluable when you’re training lots of new hires or someone is out sick or some other reason they really should know some of the information but weren’t initial receivers.
  2. Employees stress less about “needing to pick up the kids at 4pm” or “go to the dentist/doctor” because there should rarely be meetings except those that are absolutely necessary booked anyway at any particular time

There is a balance here: if a Slack/e-mail/etc thread has “gone way too long/far” that’s when you can and should decide to give up and move on to a synchronous meeting: but treat it as the exception for when absolutely necessary vs the default.