How to manage a remote team across time zones (2026)

Managing a remote team across time zones comes down to three decisions: how many hours people genuinely share, what happens in writing when they don't, and who absorbs the inconvenient hours when you do need to meet. Get those right and a team spread from Bali to New York can move faster than one office, because work keeps going while someone sleeps.

It's a common problem, not an edge case. In Buffer's State of Remote Work 2023, which surveyed 3,000 remote workers between 10 October and 28 November 2022, 62% said their immediate team spans multiple time zones and 74% said their company operates across them. Working across time zones was the single biggest struggle for 14% of respondents.

How much overlap a remote team needs

Aim for about two hours of shared working time between people who work closely together, and design everything else to work without it. Two hours is enough for a short live call plus quick back and forth on anything blocking. It also matches the cross-regional windows in GitLab's communication handbook, which suggests 8:00 AM to 10:00 AM Pacific Time (4:00 PM to 6:00 PM London or Lisbon) when Europe meets the Americas, and 7:00 AM to 9:00 AM Hong Kong with 4:00 PM to 6:00 PM Pacific when Asia meets the Americas.

A rough guide:

How to choose your window:

1. Write down each person's normal working hours in local time, then convert them to UTC.
2. Find where the UTC ranges overlap. That's your window. If it's under an hour, look at who could start an hour earlier or later by choice, not by default.
3. Protect the window for things that need a live answer: unblocking, decisions with real disagreement, one-to-ones. Don't spend it on status updates.
4. Recheck it every time daylight saving changes (more on that below).

Worked examples for common founder setups

These assume everyone works 9:00 to 18:00 local time. Offsets: Bali (WITA) is UTC+8 with no daylight saving changes from 2020 to 2029; Germany is UTC+1 in winter (CET) and UTC+2 in summer (CEST); Lisbon is UTC+0 in winter and UTC+1 in summer; the US West Coast is UTC-8 on standard time and UTC-7 on daylight time, with New York three hours ahead of it (UTC-5 and UTC-4).

What this means in practice. A Bali founder with Europe and US East Coast staff has no hour where all three are at their desks. The realistic pattern is two pairs: Bali and Berlin overlap in the Bali afternoon, Berlin and New York overlap in the Berlin afternoon, and Berlin becomes the natural relay. A Lisbon founder with a West Coast team has one hour, so either one side moves its day by an hour (GitLab's two-hour window has Lisbon at 16:00 to 18:00 and Pacific at 08:00 to 10:00) or the team accepts one live hour and runs everything else in writing.

If you're based in Bali, Bali Startup & Tech covers the local side of working from the island.

Daylight saving changes move your overlap

Daylight saving shifts your overlap because countries change on different dates, and some don't change at all. The US moved clocks forward on 8 March 2026 and back on 1 November 2026, and in 2027 changes on 14 March and 7 November. Lisbon changed on 29 March and 25 October 2026, and in 2027 changes on 28 March and 31 October. Germany follows the same rule: summer time runs from the last Sunday of March to the last Sunday of October. Bali doesn't change.

So for a few weeks each spring and autumn, Europe and the US sit an hour closer than usual. Between 25 October and 1 November 2026, Berlin is five hours ahead of New York instead of six, and Lisbon is seven hours ahead of Los Angeles instead of eight. Your Bali to Europe overlap also changes by an hour twice a year while your own clock stays put.

Rules change too. Microsoft notes that from 1 November 2026, British Columbia, Alberta and Manitoba will stay on permanent daylight saving time, and Outlook users there need to move to new time zone settings and check recurring meetings. GitLab's tip is simple: set recurring meetings in UTC so the time doesn't drift when one person's local clock changes. Then tell the team which weeks the local times will move.

Async defaults that make time zones work

Async should be the default because writing doesn't need anyone else to be awake. The 37signals guide to internal communication puts it as "Real-time sometimes, asynchronous most of the time" and says meetings are "the last resort, not the first option". GitLab's guide to asynchronous and non-linear working says non-linear days only work if the company works handbook-first, so "all meaningful takeaways from conversations are documented in their proper place".

Very few teams go fully async, and they don't need to. Only 3% of Buffer's respondents worked all async, 29% mostly async, 31% evenly split, 23% mostly sync and 14% all sync. Doist, writing about its own fully remote company in 2022, described its stack as about 70% async, 25% sync and 5% in-person meetups.

The defaults worth setting from day one:

• Written handovers. Everyone ends their day with a short note: what moved, what's blocked, what the next person needs. 37signals automates this: every workday at 16:30 Basecamp asks each employee "What did you work on today?", and every Monday "What will you be working on this week?". Doist replaced stand-ups with an automated weekly Twist thread.
• A decision log. One page or channel where decisions are written down with the reason and the owner. Doist recommends a directly responsible individual (DRI) model, where one person owns each area and makes the call. 37signals' line is "Writing solidifies, chat dissolves."
• Recorded video updates. Use a short screen recording for anything visual: a demo, a bug, a design walkthrough. Doist suggests screenshots and screen recordings with tools such as Loom, plus being explicit about what you need and by when.
• Response-time norms. Say how fast people should reply on each channel and stick to it. 37signals says: "Never expect or require someone to get back to you immediately unless it's a true emergency." GitLab states there's "no expectation to respond to messages outside of your planned working hours."
• Overcommunicate in each message. A question that needs three rounds of clarification costs three days across a 16-hour gap. Put the context, the link, the options and your recommendation in the first message.
• Long notice for deadlines. GitLab asks for announcements 72 hours (24 hours at minimum) before a due date, so people in Asia-Pacific and Europe don't miss something posted outside their hours.

If you run lean with AI agents doing some of the work, the same handover discipline applies to them. Our guide on how solo founders use AI agents covers that side.

Meetings across time zones

Meet live only when writing is slower or riskier than talking, and make the meeting usable by people who can't attend. Doist keeps synchronous time for building rapport, critical feedback or sensitive topics, brainstorming with lots of unknowns, project kickoffs, and genuine crises. That's a good list to copy.

When you do meet, GitLab's all-remote meetings guide is the most detailed public playbook:

• Send invites 72 hours ahead (24 hours at minimum) and mark non-essential people as optional.
• Link an agenda document in the invite, shared on the same notice, so people can decide whether they need to attend.
• Record group meetings that span time zones, and add the recording link to the agenda within 12 hours.
• Take written notes during the meeting even when recording. GitLab's communication page says written notes are more efficient to read than recordings.
• When a meeting falls outside some participants' hours, keep decisions and actions open for 24 to 48 hours so they can contribute asynchronously.
• For recurring global meetings, run more than one session and name them "Session 1" and "Session 2" rather than "APAC friendly", since "friendly" means different things depending on where you sit.

Rotate the inconvenient slot

When there's no overlap, someone has to take an early or late call, and it shouldn't always be the same person. A simple pattern is to rotate the slot weekly or monthly. For a Bali, Berlin and New York team, a UTC 13:00 call lands at 21:00 in Bali, mid-afternoon in Berlin and 08:00 or 09:00 in New York. The alternate slot puts the pain on the US side. As founder, take the worst slot more often than your team does: it's the cheapest way to show the norms are real.

GitLab also suggests nominating volunteers to host cross-time-zone meetings in the hours that suit their own zone, rather than the organiser always choosing their own convenient time.

Protecting people from the "always on" problem

The biggest risk of a global team isn't the gap in hours, it's people quietly working all of them. Microsoft's research on the triple peak day, published 16 November 2021, found that about 30% of the Microsoft employees it studied had an evening spike in work, and that the average Teams user sent 42% more chats per person after hours. Across time zones that pressure is worse, because there's always someone online.

37signals asks people to "write at the right time": a message at 5pm can keep someone at work longer, and one on Sunday can pull people back in for the weekend. The tools to fix this are already in the apps you pay for:

• Scheduled send in Slack. Click the arrow next to the paper plane icon to schedule a message for later; on mobile, tap and hold the icon. Scheduled messages sit under Drafts & sent.
• Notification schedules in Slack. Each person can set a notification schedule so they only get notifications on chosen days and hours. When notifications are paused, people sending a direct message can choose to notify them anyway if it's urgent, which keeps an emergency route open.
• Scheduled chats in Teams. Teams can schedule a chat message from the Actions and apps menu, but only in a conversation you've already started with that person.
• Working hours in Google Calendar. With a work or school account, working hours let people know you're unavailable when they try to book you. You can split your day into several periods, which suits a founder who takes an evening slot. It can only be turned on from a computer, and your admin may have disabled it.
• Multiple time zones in Outlook. The latest Outlook for Microsoft 365 can show up to three time zones in the calendar (Outlook 2019 and 2016 show two). The extra zone only appears in day or week view.

Then write the rule down: replies are expected within working hours only, here is the one channel for genuine emergencies, and here is who is on call for it. Doist, for example, uses Telegram with notifications on at all times for emergencies only.

Follow-the-sun handoffs for support and engineering

Follow-the-sun means work passes from a region ending its day to one starting theirs, so a ticket or fix keeps moving around the clock. GitLab's follow-the-sun coverage page is honest about the trade-off: it's "less efficient but faster" than one person working alone, because the handoff must be context-rich and the first person has to explain every deliberate design decision so the next one doesn't redo it. GitLab names a Follow-the-Sun DRI to coordinate each handoff and keeps the approach for escalations and high priority work, such as critical customer fixes, high severity security issues and corrective actions after a serious incident.

For a small team, that's the right instinct. Use follow-the-sun for an outage, a big customer's blocker or a launch, and keep normal work owned by one person end to end.

A handoff template you can paste into the ticket or channel:

1. Status in one line. What's the state right now (for example, "Fix written, not deployed").
2. Goal and deadline. What done looks like and when it's due, in UTC.
3. What I did. Steps taken, with links to commits, logs or the customer thread.
4. Decisions and why. Anything deliberate the next person shouldn't undo.
5. What's next. The exact next step, and the one after it if known.
6. Blockers and risks. Who or what you're waiting on, and what could go wrong.
7. Who to wake. The DRI and the escalation contact, with their local time.
8. Customer comms. What the customer was last told, and when they expect the next update.

Common mistakes

The most common mistake is treating the overlap as meeting time instead of unblocking time. Others to watch:

• Assuming offsets are fixed. Daylight saving changes on different dates in the US and Europe, Bali doesn't change at all, and some places change their rules. Recheck your overlap at every change.
• Making the founder's zone the default. If every meeting suits the founder, the team carries all the early and late calls. Rotate.
• Chat instead of documents. Decisions buried in a chat thread are invisible to the person who wakes up eight hours later.
• Rewarding after-hours replies. GitLab avoids recognising people for working outside their hours to reduce pressure to do it. Praise results, not response times.
• Status meetings. A daily stand-up across 15 hours of difference costs someone their evening. Written check-ins do the same job.
• Hiring before you've checked the hours. Work out the overlap before you hire in a new country, alongside the legal set-up covered in our guide to hiring remote employees internationally.

Checklist

• Everyone's working hours are written down in local time and UTC.
• Each pair of people who work closely has an agreed overlap window, or an agreed async-only arrangement.
• Recurring meetings are set in UTC, and you've noted the March and October to November daylight saving weeks.
• Every meeting has an agenda linked in the invite, written notes and, for cross-zone groups, a recording.
• The inconvenient live slot rotates, and the founder takes their share.
• Each person ends the day with a written handover.
• There's one decision log with an owner for each decision.
• Response-time norms are written down for each channel, with replies expected in working hours only.
• Scheduled send, calendar working hours and notification schedules are switched on.
• One emergency channel exists, with a named person on call.
• Follow-the-sun handoffs use the template above and have a DRI.

To compare notes on this with other remote founders, request an invite to Remote Builders.