Working remotely, asynchronously

The whole team I work with is async. Some of us are in Georgia, some in Korea, some in Japan, some in Seattle, and I’m in Manipal. Seattle and I are twelve to thirteen hours apart. When my day starts, theirs is basically over.

It sounds like a scheduling problem, and it partly is. But most of what makes this work turns out to be writing, planning ahead, being flexible, and being someone people can count on. This is the list I try to follow, and the one I’d like from anyone I work with.

1. Pick fixed hours, and stick to them

The easiest way to make async work is to be predictable. I keep set working hours, and I treat them as fixed. If people know when I’m online, they can plan around me instead of guessing.

With a team spread like this, there isn’t one hour that suits everybody. Georgia and I overlap almost all day. Korea and Japan overlap with us for a few hours around midday. Seattle’s day lands in my evening. So the overlap is always between two or three people, not all of us, and that’s fine as long as we know who’s around when.

Tell the team your hours and your time off early, in a place everyone can see.

Be the one who adapts, and share the awkward hours

If you’re the one with the odd hours, the easy thing is to wait for everyone else to adjust. It works better when everybody bends a little, so I’m happy to take a call in my evening for Seattle, or early for Japan and Korea, when it really helps.

The key is to rotate it. If the same people always get the 6 am or the 11 pm slot, they’ll burn out and resent it. So take turns, and don’t schedule a meeting for a time you wouldn’t take yourself.

A few small things help a lot:

• Always write times with a zone, or in the other person’s zone. “End of day” means something different in every one of those cities.
• Record meetings and share notes, so nobody has to attend live to stay in the loop.
• Learn each other’s public holidays and time off. Japan, Korea, Georgia, the US and India all have different ones, and they don’t line up.
• Don’t expect an instant answer from someone who’s asleep, and don’t take a slow reply personally.

2. Get unblocked before you’re blocked

If something stops me, the other side may not be awake for another ten or twelve hours. So I try to spot those things at the start of a task, not halfway through it.

Before I begin, I ask myself what I might need that I don’t have. A decision on the spec, access to a service, a permission, an API key, a review. Then I ask for those first, while the other person is still around. It’s much cheaper to wait on a reply while I work on something else than to hit the wall and sit there.

Related: always have a plan B. A second task I can pick up means a blocked hour is never a wasted hour.

3. Ask complete questions

The biggest async killer is a vague question. “Is this ok?” gets “which part?” as an answer, and that costs you a whole day.

A good question has the context, what I’ve already tried, what I’d do by default, and when I need the answer. Then the other person can reply with one word.

4. Write handoffs that stand alone

At the end of the day, I write down where things are. Someone who wasn’t in any of my conversations should be able to pick it up without asking me a thing.

Same idea for the rest of the work. Keep one source of truth, so decisions live in the ticket or the doc and not in a call. Open draft PRs early. Share work in progress. If it was decided out loud, write it down afterwards.

5. Reply fast, even if the reply is “seen”

This one is simple and it matters a lot. Don’t let emails and messages sit. If I can answer in a minute, I answer. If I can’t, I say “seen, I’ll look at it by tomorrow morning” so the other person knows they’re not stuck.

In a remote team, a quick reply is how people feel looked after. It also keeps everyone else moving.

6. Keep deadlines, and be honest when you can’t

I try to hit the dates I give. When I can’t, I say so as early as I can, with a new ETA and the real reason. Not a vague “a few things came up”, but what turned out harder than expected and what I’m doing about it.

Raising it on day two is cheap. Raising it on deadline day is not. Teams can work with bad news if it arrives early, and honesty about it builds more trust than hitting every date ever could.

7. Get good at writing

When you work remotely, most of what people know about you is what you write. Short messages, clear subject lines, the main point first, and then the detail. Plain words beat clever ones.

Text also loses tone. A message that sounds fine in my head can read cold on the other side, so I try to be a bit warmer and more explicit than I would be in person, and I assume the same good intent from others.

A few smaller habits

• Small pieces. Small tasks and small PRs are easier to review overnight than one huge change.
• Check your own work first. A bug caught after handoff can cost a whole day.
• Write things down as you go. Setup steps, decisions, and gotchas are easiest to record while they’re fresh.
• Own mistakes quickly. Say what happened and what you’re doing about it, and move on.

The short version

Be easy to work with when you’re offline. Tell people when you’re around, ask for what you need before you need it, write everything so it makes sense without you, and be honest and quick. None of it is hard. It just has to be done every day.

If you’re building a remote team and this sounds like how you’d like to work, come and say hi.