Working Across Time Zones Without Wrecking Your Sleep

The thing nobody tells you about working remotely across time zones is that the difficulty isn't the hours. It's that the hours move, and every move costs you about four days of feeling stupid.

Here's the system I use to keep clients in one hemisphere and my sleep in another, without the two destroying each other.

The real problem

Most advice treats time zones as an arithmetic problem: they're at +9, you're at -3, do the subtraction. That part is trivial. The actual problems are these:

• Your available overlap shrinks as you move, but your commitments don't.
• Meetings get scheduled in the overlap, which means the overlap gets consumed by meetings and the actual work happens outside it.
• Every client assumes their working hours are the neutral default. All of them, simultaneously.
• Recovering from a badly-timed call costs more than the call is worth.

The overlap-window math

Before any move, I calculate one number: usable overlap hours — the hours where their working day intersects mine, minus the first and last hour on each side.

I drop those hours because they're never real. Their 9am is inbox triage; their 5pm is nobody making decisions. If the honest overlap is under two hours, the move needs a different plan, not more optimism.

Zero usable overlap isn't a dealbreaker. It just means the relationship has to become genuinely asynchronous before you move, not after.

Four rules that made it sustainable

1. One synchronous slot, fixed, weekly. Not "whenever works". A single recurring window, defended, that everyone books into. If it's full, they wait a week or send it in writing. This is the single change that fixed the most.

2. Meetings are for decisions, not updates. Every status update becomes a written one. This isn't a productivity aesthetic — with two usable overlap hours, spending one on a recap is genuinely irresponsible.

3. Announce the window, never the location. Clients need to know when you're available. They very rarely need to know which country you're in, and telling them invites a conversation about whether you're on holiday.

4. Move on a Thursday. You lose Friday to travel and get the weekend to adjust. Moving on a Sunday means starting the working week already broken, which I did four times before I noticed.

Two usable overlap hours, defended properly, beats six hours that everyone treats as freely bookable.

Protecting sleep, specifically

Sleep is the thing that quietly pays for everything else, and it's the first thing a bad schedule takes. Three things I hold to:

• No calls in the four hours before my normal sleep time. Not because of screens — because of adrenaline. A tense 10pm call costs me until 1am.
• Adjust before the flight, not after. Shifting an hour a day for three days before a big move is far cheaper than shifting five hours on arrival.
• One recovery day per five hours of shift, budgeted as work time. If I pretend that day is productive, I schedule things into it and lose two days instead of one.

The part that's actually about saying no

Every system above is a way of saying no in advance so you don't have to say it in the moment. That's really all it is. The window, the async default, the recovery day — these are pre-made decisions that stop you negotiating with a client at 11pm when your judgement is worst.

The clients worth keeping have never had a problem with any of it. That has been consistent enough, for long enough, that I now treat pushback on a reasonable availability window as useful early information.

Making a relationship genuinely asynchronous

Zero usable overlap is workable, but only if the relationship becomes properly asynchronous before you move. Doing it afterwards, under pressure, is how people lose clients and conclude that remote work across time zones doesn't function.

Four things have to exist first:

• A written decision record. Somewhere both sides can see what was decided, when, and why. Without this, async work degenerates into people re-litigating settled questions because nobody can remember the reasoning.
• An agreed response-time expectation. Not "as soon as possible" — an actual number. Mine is one working day for anything normal and a named escalation route for anything genuinely urgent. Ambiguity here is what makes people check their phone at midnight.
• Handoffs written to be read cold. A message that assumes context the reader had eight hours ago is a message that costs a full day. This is a writing skill, it's learnable, and it's the highest-leverage one in async work.
• One reliable synchronous slot as a pressure valve. Even a fortnightly 30 minutes stops small misunderstandings compounding. Pure async with no human contact tends to fail slowly and then all at once.

I test all four for a month before committing to a move that kills the overlap. If the relationship can't run async while I'm still in a convenient time zone, it certainly won't once I'm not.

What a badly-planned move actually costs

I tracked this properly across four moves, because I kept underestimating it and wanted to stop arguing with myself about it.

Two patterns. First, the two disasters both involved scheduling something important in the first week — the shift itself was survivable and the commitments on top of it weren't. Second, the last move had the second-largest shift and the second-fastest recovery, purely because of pre-adjustment and a blocked first week.

My working number now: one recovery day per hour of shift, budgeted as work time. It's conservative for eastward moves and about right for westward ones. Pretending those days are productive is what turns a manageable week into a bad month.

Questions I get about this

Found an error in this piece? Tell me — corrections get made in the open with a dated note, never a silent edit. The log is public.