Hiring Across Time Zones: How Much Overlap You Actually Need, by Role
Published September 16, 2026 by SyncHours Team
"We need at least 4 hours of overlap" is a common hiring filter, applied as a blanket rule across every open role. It's the wrong level of granularity. A support engineer and a technical writer on the same team have completely different overlap requirements, and a blanket rule either blocks a writer who'd have been a great hire in Bali, or forces a support engineer into a schedule that can't actually cover the incidents they're hired to handle.
Three questions that actually determine the answer
- Does the role block other people's work in real time? A role where someone else is regularly waiting on a live answer — an incident commander, a deal-closing salesperson, an EA coordinating a leadership calendar — needs overlap. A role that produces output on its own timeline and hands it off asynchronously usually doesn't.
- Does the role depend on a specific external clock? Customer support tied to a specific market's business hours, or a role coordinating with a vendor or partner in a fixed location, is constrained by that external clock regardless of where the rest of the team sits — overlap with teammates matters less here than overlap with the customer.
- How much of the role is genuinely synchronous work? Pair programming, live design critique, and real-time debugging need overlap. Writing, solo coding, data analysis, and async code review mostly don't — they need occasional overlap for unblocking, not sustained overlap for doing the work itself.
A worked scoring table
Score each role 0–2 on the three questions above (0 = no, 1 = sometimes, 2 = yes) and the total maps cleanly onto a realistic overlap target:
| Role | Blocks others? | External clock? | Sync-heavy? | Score | Target overlap |
|---|---|---|---|---|---|
| On-call / support engineer | 2 | 2 | 2 | 6 | 6h+, or follow-the-sun coverage |
| Account executive / sales | 1 | 2 | 2 | 5 | Territory business hours, not team overlap |
| Engineering manager | 2 | 0 | 1 | 3 | 3–4h, enough for 1:1s and unblocking |
| Product designer | 1 | 0 | 1 | 2 | 2–3h for critique sessions |
| Backend / infrastructure engineer | 1 | 0 | 0 | 1 | 1–2h for async-first code review |
| Technical writer / content | 0 | 0 | 0 | 0 | No requirement — hire on skill, not geography |
| Data analyst | 0 | 0 | 1 | 1 | 1–2h for stakeholder walkthroughs |
The spread matters more than any individual row: on a seven-role team like this, only the support and sales roles genuinely need to be screened by geography. Applying a flat "4 hours minimum" filter to all seven would have needlessly excluded qualified candidates for four of them.
The interview process has its own, separate overlap problem
It's worth treating the hiring process itself as a different question from the role's steady-state overlap need. Even a technical writer role with a target overlap of zero still needs at least a handful of live interview slots, and it's common for a hiring team spread across two or three time zones to unintentionally schedule every interview in whichever window is easiest for the interviewers — which can quietly filter out strong candidates in distant time zones before the role itself was ever the constraint. If a candidate has to take a 6am or 11pm call just to interview for a role that won't actually require that once they're hired, that's a self-inflicted funnel problem, not a real requirement. Worth explicitly rotating interview slots the same way you'd rotate a recurring team meeting, rather than defaulting to the interviewers' convenience for every round.
Using this before you write the job post
Score the role before the requisition goes out, not after a great candidate turns out to be in the "wrong" time zone — the second scenario is where blanket overlap rules quietly cost companies strong hires. If a role scores a 4 or higher, state the actual overlap requirement in hours in the job post rather than a list of acceptable countries; a range of viable time zones is usually wider than recruiters assume once you calculate it directly. Check candidate locations against your existing team's hours on the SyncHours planner before ruling anyone out, and if the role's overlap need is genuinely high, see the fair rotation formula for how to keep that overlap burden from landing on the same person every week once they're hired.