Journal — November 18, 2025 · 5 min read

Timezone Management — Working with US Clients from Asia

The actual system for working with US clients from Southeast Asia — one fixed overlap window, async by default, batching your day, and the boundary failure that cost me a month of sleep.

For a month I took calls at midnight, and by week three I was making the kind of mistakes I don't make.

That's the failure mode this post exists to prevent. The arithmetic is unforgiving and most people meet it by absorbing the damage personally, which works for about four weeks.

The raw numbers

Bangkok, Hanoi and Chiang Mai are UTC+7. Bali is UTC+8. India is UTC+5:30.

US Pacific is 14–15 hours behind Bangkok depending on daylight saving. US Eastern is 11–12 hours behind. That means:

  • A 9am Pacific call is midnight in Bangkok.
  • A 9am Eastern call is 9pm in Bangkok, which is the only genuinely civilised slot in the entire day.
  • A 4pm Pacific call is 7am the next morning in Bangkok, which is survivable.

Everything else is worse. Notice what this means: the overlap between a normal US workday and a normal Asian one is essentially zero, and no amount of goodwill changes that. The window has to be manufactured, and someone has to pay for it in inconvenience.

The system

1. One fixed window, agreed in writing

Every US client gets exactly one recurring overlap slot, and it goes in the contract or the kickoff doc, not in a Slack message that gets forgotten.

Mine is either 7:00–8:30am my time, which is late afternoon Pacific, or 8:30–10:00pm my time, which is morning Eastern. The client picks one when we start. Anything outside it is scheduled with 48 hours' notice or it doesn't happen.

The important part is that it's fixed. A floating overlap means your whole day is provisionally hostage, which is worse than a bad slot at a known hour.

2. Async is the default, not the fallback

If the only reliable synchronous contact is 90 minutes a week, then every process has to survive without it.

Written updates, on a schedule. Every working day, before I stop, a short post in the shared channel: what shipped, what's blocked, what I need a decision on. It lands in their morning. The client wakes up to progress and a clear list of questions.

Loom over meetings. A four-minute recorded walkthrough of a new screen replaces a 30-minute call, and it's better, because they can watch it twice and forward it to someone who wasn't invited. I've killed more calls with Loom than with any other tool.

PRs with real descriptions. Not "fix bug." What changed, why, what to look at, what I wasn't sure about. A reviewer twelve hours away cannot ask a follow-up question and get an answer the same day, so the answer has to already be there.

Decisions get a deadline. "If I don't hear back by your Thursday, I'm going with option B." This one line has saved more schedule than everything else combined. Without it, a blocked question costs a full day per round trip.

3. The overnight advantage nobody mentions

Here's the part that makes the arrangement genuinely good rather than merely tolerable.

I work a full day while they sleep. I push at 7pm my time. They wake up to a finished feature and a walkthrough video. They review during their day, while I'm asleep. I wake up to their feedback.

Two full working days pass in every 24 hours. When the async discipline is in place, this is faster than sitting in the same office, and clients notice. I've had a US founder tell me it felt like the project moved overnight, which it literally did.

The offset is only a cost if you fight it.

4. Batch the day into two blocks

My day has exactly two shapes:

Deep work, roughly 9am to 5pm local. No Slack open. Notifications off. Nobody in the US is awake, so nothing is being missed, and this is the single largest gift the timezone gap gives you.

Comms block, roughly 8pm to 10pm local. Slack, email, the call if there is one, the written update. Two hours, then closed.

The blocks are what make the arrangement sustainable. The moment they blur, you get the worst version of both timezones at once. I go into more detail on the daily shape of this in how I work as a digital nomad.

The client who wants you at 2am

Some will ask. Usually not maliciously — they simply haven't done the arithmetic and think 9am Pacific is a neutral time.

Do the arithmetic for them, out loud, once: "that's midnight where I am." Most people immediately move it. The ones who don't are telling you something useful about how the rest of the engagement will go.

If the role genuinely requires real-time US hours, that isn't a scheduling problem. It's a different job, and it should be priced as one or declined.

What it cost me

The month I mentioned at the top was with a US client early on. I said yes to a 9am Pacific standup because I wanted the work and it felt small. Midnight, every weekday.

I'd sleep from 1am to 8am on paper and actually lie awake until 2. By week three I was writing code I had to rewrite, missing obvious things in review, and irritable in a way that leaked into how I answered questions. My output dropped enough that the work I was protecting by saying yes was the work being damaged.

The fix took one message: I proposed moving the standup to their 4pm, offered a written summary in their morning instead, and said I'd remain reachable for anything urgent. They agreed in under an hour. It had never been a fight. I'd just never asked.

The rule

Publish your timezone in your calendar, keep a Slack status that says where you are and when you're next online, and treat your overlap window as a boundary rather than a starting position for negotiation.

The clients worth having will respect a stated constraint. The ones who won't were going to be a problem about something else anyway, and the timezone just told you early.