I have been working for distributed companies for over 5 years – long before this pandemic malarkey and everyone becoming a “remote work expert”. The reality of the past 18 months for many people has been a lot of terrible remote work. Including for me at times – I love remote work in “normal times”, but in the darkest timeline I have never met any of my current coworkers, struggled to keep a normal schedule, and felt caged in (even in my beautiful, purposely designed home office).

Throughout all of this I’ve known that normally I love remote work, I just hated the pandemic situation, but I have so much empathy for those who have concluded – based on this experience – that remote work is not for them.

DuckDuckGo, where I work currently, is fully distributed, and we hire globally. The native apps team (my team) runs from Russia, through Europe, to the West Coast of Canada and the US. Prior to DuckDuckGo, I worked at Automattic, another fully distributed company where I led teams of 20-40 people, again based all over the world.

Remote work, works – when we are intentional about it. My three core principles of remote work are:

• Embrace async.
• Enable autonomy.
• Build connection.

1. Embrace async

Why: synchronous time is more expensive. It was always more expensive but in a remote context it’s explicitly more expensive. In a distributed context it can be prohibitively expensive because timezones mean someone is taking the call late at night. Moving things that don’t need to be synchronous to asynchronous reduces meeting overhead, and makes for a more equitable experience outside the predominant timezones.

Embracing async means moving to writing as much as possible, especially things like status updates and announcements. Those do not need to be real time. Embrace written communication outside your chat app. I cannot stress this enough – Slack messages are not asynchronous. 1:1, fine. But in a channel, categorically not. Someone a few timezones behind will wake up, start their day, and find the conversation has happened and moved on without them ever getting the opportunity to be part of it.

At DuckDuckGo, we use Asana to communicate asynchronously; Automattic uses custom blogging software. I’ve seen other companies use GitHub. I don’t think it really matters what is used, provided that everyone uses the same thing, and there is some way for people to opt into what is relevant to them (versus absolutely everything). Email can be used in this way, and might be better than a chat app, but email is not transparent, has no single source of truth and is not meaningfully shareable, making it a bad option overall.

Thinking asynchronously will shape the way you communicate. Prioritizing clear writing and consistently structured updates will make async communication more efficient. The first step I suggest towards more async communication is to delete your boring meetings! Replace any useful part of them with text based updates, and reclaim your time for more impactful activities (or Netflix, no judgement here).

2. Enable autonomy

Why: People need to be able to get on with things when they are working, and not have to rely on other people being around. If you’re a manager, you need to be able to let people get on with things without having to constantly intervene or answer questions.

Enabling autonomy means getting organized about your communication of priorities, resources, helping people understand how decisions get made and what parameters they operate within, and trusting people to get things done.

Documentation helps a lot; it helps people help themselves. For example, our onboarding is well documented in checklists, so that from someone’s first day they can make progress on things, regardless of who is around – key to onboarding people across timezones.

It’s also important to document decisions. Even if a decision happened in a meeting, it’s important to write it down (see also: async) so that people who weren’t in the meeting can still be aware. Think also about how decisions get made, because when you understand the parameters it’s easier to move things along. Operate with specific checkpoints, such as a tech design review, rather than random meetings and drawn out code reviews.

Part of enabling autonomy is being organized. If you need input, you need to plan for it so you don’t get stuck (this is where the checkpoints are useful). If you need to give input, you need to be proactive in sharing information upfront and be clear about your availability.

Autonomy is often seen through an individualistic lens, but team-level autonomy is a product of healthy collective practices. As individuals we don’t just get autonomy we need to make sure that we support other people’s autonomy.

3. Build Connection

Why: Better team relationships make for better team functioning.

It might seem from point 1 that I am anti-meeting. I am not, I am anti-boring-meetings-that-could-be-replaced-with-a-document. In practice, this does mean I am anti most meetings. The reality is that we do not build any kind of human connection pretending to listen to status updates, and the value of meetings in offices for building connection was probably largely in the time before and after.

Office culture builds structure around work and takes connection for granted. Good remote culture is the opposite: build structure around the connection, and let the work happen.

Once you’ve deleted your boring meetings, you’ve freed up time on your calendar for fun. Play games! Share feelings! Have adhoc 1:1s! One of my favourite meetings each week starts with an extremely random question. Prioritizing building connection is particularly important during onboarding, as it is what helps people feel a sense of belonging.

>>

Making remote work work requires some rethinking of what you’re doing and why. The outcomes don’t change, but the way you get to them might. The good news is, even if you return to the office, there is still value in async communication, more autonomy and team connectedness. So why not give them a try?