I’ve worked remotely across time zones for four years, on a small team supporting a large customer base. I wouldn’t go back. I also think most of the arguments made in favour of remote work skip the one problem that actually causes it to fail.
The problem is trust, and I think the kind that matters gets almost none of the attention.
The trust that isn’t the issue
The stated worry is whether people are working. This is the version that gets the airtime, produces the monitoring software, and misses the point entirely.
It’s close to a non-problem in software. Output is visible: commits, pull requests, tickets, deploys, whether the thing works on Tuesday. Someone not doing the work becomes obvious quickly, and faster than in an office, where presence is very easily mistaken for contribution and often is.
Every hour spent on this version of the problem is wasted, and worse than wasted: monitoring communicates a belief about your team that they’ll correctly interpret and respond to accordingly.
The trust that is the issue
The real question is quieter, and it’s asked constantly, by good people doing good work:
Am I doing the right thing right now, and would anyone tell me if I weren’t?
In a shared room that gets answered continuously and for free. You overhear priorities shifting, and you see someone’s face when you describe your approach. All of it is ambient rather than deliberate, and it’s doing an enormous amount of work.
Remove it and the question stays, unanswered.
What fills the gap is a low-grade uncertainty that shows up as hedging, as over-checking, as waiting for confirmation before acting, and, most expensively, as people quietly working on the safe thing rather than the important thing, because the safe thing can’t be criticised.
That uncertainty is the tax. Not slacking. Hesitation. And it’s expensive precisely because it afflicts the conscientious most.
Why written process is the fix
Ambient reassurance has to be replaced with something explicit, and the only thing that works at a distance is written.
Documentation, here, means the answer to a question someone would otherwise have to wait to ask.
The test I use: how long does someone wait, on average, to find out whether their approach is acceptable? If the answer is measured in hours because it needs a specific person to wake up, the process isn’t written down well enough. Every one of those waits is a person stopped, and the cost compounds across a team and a spread of time zones.
What has to be written, roughly in order of how much pain the absence causes:
- How work is chosen, how something becomes a priority, and who decides
- What done means, the actual bar, including the verification steps, not a vibe
- The conventions, where things go, how they’re named, what the existing pattern is, so that following it doesn’t require a conversation
- What to do when blocked, precisely who to ask, and what to do when they don’t answer, which is the step everyone omits
- What went wrong before, the failures the process exists to prevent, so people can tell a live rule from a vestigial one
That last one matters more than it looks. Undocumented rationale is how process decays. A new person sees a rule with no visible reason, correctly identifies it as arbitrary, works around it, and rediscovers the original failure personally, at which point the rule gets reinstated by someone with a bad week.
The good news is that this whole list is now much cheaper to produce than it used to be: transcription, not knowledge, was always the bottleneck, and that’s the part that got cheap.
Hierarchy, said plainly
The less comfortable half.
Remote teams often have vaguer ownership than co-located ones, because vagueness is survivable in a room: you can read who’s actually deciding from how people sit and who gets looked at. At a distance it’s unreadable, and the effect is paralysis.
When ownership is unclear, one of two things happens: nobody decides, or everybody re-litigates. Both burn the same resource, which is the attention of people who should be building. I’ve watched a straightforward technical improvement sit untouched for weeks because it wasn’t clear whose call it was.
Clear hierarchy is the answer to “who decides this”, available without asking anyone. Everyone can then disagree efficiently, because they know where the disagreement goes and when it ends, which is most of what makes disagreement useful rather than corrosive.
The version I’d argue for:
- One named owner per area, and that name is written where people look
- The owner decides. Everyone else can input, and input closes
What actually makes it work
Ranked by how much difference it makes, from what I’ve seen:
Write decisions down with their reasons. The reason is what lets someone apply it to a case you didn’t anticipate, which is most cases.
Make the default async, and make it complete. A message containing the context, the question, and what you’ll do if nobody replies is worth ten that need a round trip. That last clause is the important one; it converts a block into a timer. In practice:
Deploying the search index change today. It’s behind a flag, rollback is one command, and I’ve tested against a copy of production data. Shipping at 16:00 unless someone objects before then.
Nobody has to reply for that to work. Compare it to “hey, thoughts on deploying the search change?”, which stops one person and can stop two.
Reduce the number of people who are load-bearing. Every process where one specific person is required is a process that halts at their time zone boundary or their bad week. This is the highest-value thing on the list and the easiest to ignore, because it works fine right up until it doesn’t.
Make the state of things visible without asking. If knowing the current state requires interrupting someone, then the interruption is the system working as designed, and the design is wrong.
An office pays for weak process with proximity; a remote team pays for it in waiting.
What did someone on your team wait for this week that a sentence written last month would have answered?