How much you need depends on the role and the company's working style, not on geography alone. Engineering roles often run on the least overlap because much of the work is independent. Customer-facing roles need the most, because they align to customer hours. And a category of genuinely asynchronous companies requires almost no overlap at all. Knowing which kind of role you are looking at tells you whether your location is a problem or a non-issue.
This piece explains what overlap is, how much different roles actually need, how async-first teams remove the requirement, and how to read a listing for its real timezone demands before you apply.
What "timezone overlap" actually means
Overlap is the window when everyone on a distributed team is within normal working hours at the same time. It is the only time real-time collaboration can happen; everything outside it has to survive an asynchronous round-trip, which can add up to a full day of delay to a single exchange. When a job posting mentions "timezone overlap" or "core hours," it is telling you when you need to be available for live collaboration, regardless of where you physically are.
The important point is that overlap is a function of working hours, not distance. Two people eight hours apart can still create four hours of overlap if one of them shifts their day. A developer in Lisbon working for a San Francisco company, for example, can build a workable overlap window by starting in the early afternoon local time rather than the morning. Location sets the constraint; the schedule resolves it.
How much overlap different roles need
The requirement varies widely by function, and understanding the pattern helps you judge a role before applying.
**Engineering: often the least.** Much software work is deep, independent, and asynchronous, handled through code review, documentation, and written updates rather than constant real-time interaction. Industry guidance converges on around two to four hours of daily overlap being enough for effective collaboration, covering a standup and some live exchange, with the rest done async. Some teams push lower. A staffing analysis notes that four hours of overlap covers a standup, a pairing session, and a few real-time exchanges, while below that threshold teams default to async even for tasks that would benefit from live input.
Product, design, and management: more. Roles that coordinate across engineering, design, customers, and leadership need more synchronous time than pure engineering, because cross-functional work depends on live alignment. A product manager one or two hours from the team's core has an easy time; one twelve hours away generally has to shift to evening or night work to make it function.
**Customer-facing roles: the most.** Sales, customer success, and support usually need four to six hours of overlap, but the alignment is often to customer working hours rather than to headquarters. A support engineer's overlap requirement is set by when customers need help, not by where the company is based.
Junior roles: more than the title suggests. Early-career employees typically need more real-time access to senior colleagues for questions, feedback, and mentorship, so a junior role may carry a higher overlap expectation than a senior one in the same function.
How async-first companies remove the requirement
A distinct category of company treats asynchronous work as the default rather than the fallback, and for these, timezone overlap can be close to irrelevant. Companies including GitLab, Automattic, and Sourcegraph hire engineers globally with minimal overlap requirements, relying on thorough documentation and asynchronous code review instead of shared hours.
The practices that make this work are specific and observable. Async-first teams post written standups at the start of each person's day rather than holding a live meeting, so status is discoverable regardless of timezone. They record demos for later viewing with async comments. They write decisions down in shared, searchable places rather than making them in meetings that half the team sleeps through, and they set explicit response-time expectations for work inside versus outside the overlap window. GitLab's public remote handbook, drawn from a workforce spread across more than 65 countries, recommends rotating inconvenient meeting times so no single timezone permanently absorbs the early-morning or late-night slot. Basecamp and Doist have similarly documented that reducing mandatory meetings while increasing async documentation improved, rather than harmed, their project velocity.
The takeaway for a job seeker: at an async-first company, your location is rarely disqualifying. At a synchronous-heavy company, it can be, even if the role is otherwise open to you.
The daylight saving complication
One detail that surprises people: overlap windows are not fixed year-round. Regions that observe daylight saving time shift by an hour twice a year, and they do not all shift on the same dates. In 2026, US clocks moved forward on March 8, while the EU changes on different dates in spring and autumn, which creates several weeks each year where a US-Europe team's usual overlap silently moves by an hour. If a role sits near the edge of a workable overlap window, those transition weeks can be the difference between a viable schedule and an unworkable one. It is worth confirming the real overlap during both standard and daylight-saving periods before committing.
How to read a listing for its real timezone demands
You can usually determine a role's timezone requirement before applying, if you know what to look for.
- Search the description for "timezone," "overlap," "core hours," "must be available," or a named zone such as "EST" or "CET." These state the synchronous requirement directly.
- Distinguish overlap with headquarters from overlap with customers. A customer-facing role may require you to match a customer region rather than the company's own hours.
- Look for signals of async-first culture: mention of written standups, documentation, recorded updates, or an explicit remote or async working policy. These indicate that overlap is likely flexible.
- Treat "remote, worldwide" paired with a demand for several hours of overlap with a single timezone as what it is: a role effectively limited to a band of longitudes, not genuinely open everywhere.
- If overlap is not stated and the role involves real-time collaboration, treat it as a question to ask early, since it determines whether your schedule is compatible at all.
The underlying principle is that "remote" does not tell you whether a role is synchronous or asynchronous. The overlap requirement does, and it is the single most useful thing to establish about a distributed role's day-to-day reality.
Frequently asked questions
Do I have to live in the same timezone as the company? Usually not. Most roles require a few hours of daily overlap, commonly two to four, which you can often create by shifting your working hours rather than relocating. Whether your location works depends on how much overlap the role needs and how much you are willing to shift your day.
How many hours of overlap do remote teams actually need? Most teams find two to four hours enough for meetings and urgent coordination, provided the rest of the work can happen asynchronously. Engineering often needs the least, customer-facing roles the most, and async-first companies may need almost none.
Can I work a US remote job from Europe or Asia? Often yes, but the further the offset, the more you may need to shift your hours. Europe and the US East Coast typically share three to four hours on standard schedules. US and much of Asia have little to no standard-hours overlap, so those arrangements usually require evening or night work or a genuinely async-first employer.
What is an async-first company? One that treats asynchronous communication as the default, using written updates, documentation, and recorded meetings instead of requiring everyone online at once. At these companies, documented by examples like GitLab and Doist, timezone overlap is rarely a barrier to being hired.
Why does my overlap window change a few times a year? Because daylight saving time shifts clocks by an hour, and different regions change on different dates. For a few weeks in spring and autumn, a cross-region team's usual overlap can move by an hour until both sides have transitioned.
References
- Roam, Timezone Overlap for Remote Teams: How Many Hours Do You Actually Need?
- Revelo, Time Zone Overlap vs Opposite Time Zones for Remote Teams.
- Kwiqwork, How to Manage Time Zone Differences with Remote Dev Teams.
- Hakaru, Time Zone Meeting Planner Guide: Scheduling Across Global Teams (on GitLab, Basecamp, and Doist async practices and DST).
- Asa, Timezone Overlap Calculator for Remote & Hybrid Teams.