Working a US/EU Team Overlap While You Move Across Timezones

Name the actual constraint

A team split between the US East Coast and Central Europe has a natural overlap window of roughly 4 hours (something like 9am-1pm ET, which is 3pm-7pm CET). That window already exists whether you're nomading or not. Your job as the moving piece is to protect your ability to land inside that window as often as possible, and to communicate clearly on the days you can't.

Pick your bases by timezone offset, not by vibes

Before booking a base for a few weeks or months, check where it sits relative to that core US/EU overlap:

• Western Europe / UK (GMT to CET): Best case. You're inside or adjacent to the EU side of the overlap by default.
• Eastern Europe / Balkans (EET): Still workable, usually just a 1-hour shift, easy to absorb.
• North Africa / Canary Islands: Similar to Western Europe, an underused option for nomads who want the EU overlap without EU costs.
• South/Southeast Asia: This is where it gets hard. Bangkok, Bali, and similar hubs sit 5-7 hours ahead of CET and 11-13 hours ahead of ET, meaning the natural US/EU overlap now falls in your late night or very early morning. Doable for a few weeks with discipline, exhausting as a permanent setup.
• Latin America: Underrated for this exact team split. Mexico City and Bogotá sit close to US time zones and only 6-7 hours behind CET, often giving you a workable morning overlap with Europe and near-total overlap with the US.

The system once you've picked a base

• Protect one hard overlap block per day, even if it's only 90 minutes, and defend it against your own travel plans (excursions, checkout times, flights) the same way you'd defend a client meeting.
• Front-load synchronous needs into that block. Anything that needs a live decision, a design review, an unblock, goes into the overlap window. Everything else moves to async.
• Use a shared, timezone-aware calendar tool (Calendly, Cal.com, or just a shared doc with UTC times) so nobody on the team has to do timezone math in their head. Write times in UTC or with explicit timezone labels in every scheduling message, never just "3pm," which is ambiguous the moment more than one timezone is involved.
• Flag zero-overlap days in advance, not after the fact. If a travel day means you'll have no live overlap at all, say so 48 hours ahead with a plan for how blockers get handled (a designated async point of contact, or a pre-recorded update covering likely questions).

Handling the Asia-base stretch

If you do want a few months in Southeast Asia despite the overlap cost, the two things that make it survivable:

• Shift your own schedule earlier, waking at 5-6am to catch the tail of US evening hours or European morning, rather than trying to stay up until 2am to catch the other side.
• Negotiate explicitly with your team for a defined "low sync" period, agreeing in advance which two or three weeks will run mostly async, so nobody's quietly frustrated by slower response times they didn't expect.

Bottom line

Treat timezone overlap as a resource you're allocating, not an accident of geography. Choose bases with the overlap cost in mind, protect a small daily sync window like it's a real meeting, and communicate zero-overlap stretches before they happen rather than apologizing for them after.