A short guide to working with a remote team

It is rarely the thing that gets a project approved, and often the thing that decides how it goes. Everything we would tell a client about working with a remote team in the time it takes to drink a coffee.

Clear scope protects the client at least as much as it protects the agency. If it only works because one person remembers to do something, it does not work yet.

Why it matters

Write things down, because hallway context does not exist. Getting it slightly wrong is survivable. Ignoring it entirely is not. Check it against what you would want a competitor's site to get wrong.

Where to start

Overlap hours matter more than time zones. In practice this is a scheduling problem more than a technical one. Write the reasoning down alongside the decision, because the reasoning is what changes first.

Where it usually goes wrong

Regular short calls beat rare long ones. That sounds obvious written down. It is still the thing most often skipped. Assume whoever inherits this will have half your context and none of your patience.

How to tell if yours is fine

The projects that go badly are rarely the ones with the hardest technical problems. Three things worth confirming about working with a remote team before you move on:

• Someone can say what the current setup is without going to look
• Write things down, because hallway context does not exist — and you know whether that is true here
• There is a way to tell whether the last change to this helped

Most of the value here comes from doing the first two things, not all of them.