I work from Denpasar, which is UTC+8. The team I work with day to day is in Florida, which is twelve or thirteen hours behind depending on the time of year. Before that I spent a few years with an agency in Melbourne, two or three hours ahead. Those two arrangements sound similar — "remote work" covers both — and they are almost nothing alike.
A three-hour gap is a scheduling inconvenience. You lose the start of their day and the end of yours, and everything else works the way it does in an office. A twelve-hour gap is a different job. Their morning is my night. There is no hour where we are both naturally at a desk. Anything I need answered before I can continue costs a full day, and there are only so many days in a sprint.
The things that make that workable turn out not to be tools. Everyone has the same tools. They're habits, and most of them are about how questions get asked.
Never ask a question you can't proceed without
This is the single biggest one. If I finish my day with "should this button go in the header or the sidebar?" sitting unanswered in a channel, I have booked myself a morning with nothing to do on that task. Do that twice and the week is gone.
So questions get asked with a decision already attached. "I'm putting this in the header because X — say so if you'd rather it went in the sidebar and I'll move it." Now the work continues either way. If they agree, silence was the right answer and nothing was lost. If they don't, I move a button, which is cheap. The expensive version was waiting.
This only works if you're genuinely willing to be told no, and if you pick defaults that are cheap to reverse. Something structural — a schema change, an auth model, a third-party commitment — is worth actually blocking on. The skill is knowing which is which, and that's mostly a judgement about how hard it is to undo.
Overlap is a budget — spend it on decisions
There is usually some overlap available if both sides stretch a little. It's a small and expensive resource, and it gets wasted constantly on status updates: what I did yesterday, what I'm doing today, things that are visible in the repository and the tracker without anyone saying them aloud.
Status is asynchronous by nature. Save the live hours for the things that genuinely need back-and-forth — an ambiguous requirement, a design that isn't going to work, disagreement about an approach. Those resolve in six minutes of conversation and can take three days in writing.
The corollary: when a written thread starts going in circles, stop writing. Two people re-explaining themselves in a channel across a twelve-hour gap is the most expensive failure mode available. Schedule the fifteen minutes.
Write the handoff, every day
My end of day is the middle of their night. What I leave behind is the only version of me they have for the next twelve hours, and "pushed some changes" is not a handoff.
What's actually useful is short and specific: what's done and deployed where, what's in progress and what state it's in, what I'm blocked on and what I assumed in order to keep going, and what I plan to pick up next — so that if that plan is wrong, they can say so while I'm asleep and I find out before I've spent a day on it.
That last part is the one people skip, and it's the one that saves the most time. Announcing your next move asynchronously turns their review window into something useful instead of something that only ever catches work already finished.
Small changes, more often
A large pull request in an overlapping time zone is annoying. A large pull request across twelve hours is a multi-day negotiation: they review it during my night, leave comments, I address them during their night, and each round trip is a full day even when the actual work is twenty minutes.
Smaller pieces aren't just better practice here, they're arithmetic. Something that can be reviewed and merged in one pass costs one day. The same work in three rounds costs three. That pressure has made me a better engineer in ways that had nothing to do with time zones — it forces work to be decomposed into pieces that stand on their own, which is what it should have been anyway.
Documentation is not overhead, it's the substitute for asking
In an office, undocumented knowledge is fine, because the cost of retrieving it is turning around and asking. Remove that option and every undocumented thing becomes a day-long round trip for whoever hits it next.
This is why I write the setup notes, the deployment steps and the "why is it like this" comments — not out of diligence, but because I've been the person at the wrong end of that gap trying to work out whether a bit of weirdness was deliberate. On the teams I've worked with, writing that down has consistently been the highest-value unglamorous work available.
Be honest about hours, not heroic
It's tempting, especially early in a relationship with a client, to be permanently available — to answer at 2am because that's when they wrote. It works for a few weeks. Then it becomes the expectation, and you are doing a job with no end to it.
What works better is being specific and reliable instead: these are my hours, this is the overlap I'll always make, this is how fast you'll hear back from me in it, and here's what counts as an emergency worth waking me for. Clients are almost never asking for round-the-clock availability. They're asking not to be uncertain about when they'll get an answer. Those are very different requests, and only one of them is sustainable.
The part nobody mentions
A twelve-hour offset means long uninterrupted stretches — most of my working day happens while the people who might interrupt it are asleep. That's genuinely the best deep-work condition I've had, and it's why the arrangement suits me rather than merely being tolerable.
But it only pays off if the day is set up so that nothing stops it. All of the above is really in service of that one thing: making sure that when those hours arrive, there is nothing standing between me and the work.