Most offshore-hiring time-zone advice is bad in one of two directions. The "follow the sun" people promise you'll have a 24-hour productive workforce — work hands off your team at end-of-day and the offshore team picks it up. The "you need full overlap" people insist remote work fails without four hours of synchronous time.
Both are wrong, in opposite directions. The truth is more interesting: time-zone overlap requirements depend almost entirely on what kind of work you're hiring for, and most offshore relationships fail because the buyer mismatched the work shape to the timezone match.
I've worked Australian hours from the Philippines for years, serving clients in the US, UK, and Australia simultaneously. The setup works because each client's work shape matches the timezone arrangement. Where it breaks is when someone hires me for the wrong shape of work for our overlap.
The "follow the sun" myth
The promise: your team finishes at 5pm New York time, hands off work to a developer in Manila who picks it up at 9am Manila time (3 hours later). That developer finishes at 5pm Manila and hands off to a developer in London. The developer in London finishes and hands back to New York. Continuous productivity for 24 hours.
The reality: this works for exactly one type of work, which is parallelisable, queue-able, low-coordination work. Everything else breaks.
Why it breaks for normal product development:
- Engineering work isn't a baton you can hand off. The Manila developer needs context the New York developer has in their head. Documenting that context takes longer than just continuing the work yourself.
- Clarifying questions take a full cycle to answer. If Manila has a question for New York, the answer comes 12 hours later. Meanwhile Manila is blocked on whatever needed clarifying.
- Work that crosses timezone boundaries gets reviewed by people who weren't present for the original decision. The review surfaces concerns. Resolution takes another cycle. What should have been a one-day task takes a week.
Companies that try "follow the sun" with three teams across timezones almost always end up with one team doing the actual work and two teams doing low-stakes maintenance. The promised continuous productivity is illusory.
The exceptions where follow-the-sun does work: customer support queues (call centers, ticket queues), data entry / labelling, content moderation, bug triage (not bug fixing), and routine ops monitoring. These are queue-shaped tasks where context is contained in each item and handoff is built into the workflow. For everything else, "follow the sun" is marketing copy.
How much overlap you actually need
The realistic table:
| Work type | Minimum overlap | Why | |---|---|---| | Async-friendly work (writing, research, code) | 1–2 hrs/day | Async-tolerant. Overlap exists for real-time questions. | | Iterative development (feature work) | 2–4 hrs/day | Need fast feedback loop on direction changes. | | Customer-facing work (sales, support) | Full overlap with customers | Customer can't wait 12 hours for response. | | Product strategy / leadership | 4+ hrs/day | High-bandwidth communication required. | | Pair programming / mentoring | 4+ hrs/day | Real-time collaboration, can't be async. | | Queue work (data entry, content mod) | 0 hrs/day | Genuinely async, queue handles handoff. | | Tech support / on-call | Coverage during business hours | Whose business hours determine the answer. |
The mistake most companies make is hiring offshore for iterative development with zero overlap. The match is wrong. Either hire for queue work (zero overlap is fine) or find an offshore worker with real overlap with you (4 hours minimum for iterative work).
How AU hours from PH covers US/UK/AU
This is my actual schedule, included because it makes the overlap math concrete:
- I work roughly 8am–5pm Philippine Time (PHT). Same as Australian Eastern Standard Time (AEST) — minus 2 hours during AU daylight savings.
- AEST 8am-5pm overlaps with AU clients all day (perfect overlap), US East Coast clients 6-9pm their previous day (3 hours of evening overlap, which works for them), and UK clients 12am-9am (no useful overlap with UK working hours).
What I do for UK clients: their morning is my evening. I do their tickets first thing in their day so they have results by mid-morning. They do their thinking, send back questions by their end-of-day, I see them first thing the next morning. Async cycle is one business day, which is fine for most non-urgent work.
What I do for US East Coast clients: I work their previous evening. By the time their morning starts at 9am, I've finished a full day of their work. Most days they wake up to the question they asked yesterday already answered, plus 6 hours of work completed. They effectively get a "morning surprise" of progress every day. This is the rhythm that turns offshore hiring from "frustrating" to "magical."
What I do for AU clients: same hours as them. We're in sync all day. This is just normal in-country employment, except I happen to live in a different country.
The only case that doesn't work: West Coast US clients working 9am–5pm PT. That's 12am–8am Manila time. We have one hour of overlap (their 5pm = my 8am), which means we're effectively async with no live conversation. For most work this is fine; for iterative development it's painful. For West Coast clients I do batched morning work and we communicate through Loom videos rather than live calls.
What "async-friendly" actually means
Most companies say they want async work but don't actually structure work that way. They have all-day Slack channels with constant pings expecting fast responses, decisions made in synchronous meetings without written records, and "quick questions" that block the offshore worker until they're answered.
Real async-friendly work has these properties:
- Clear written briefs, not ambiguous Slack threads. The offshore worker reads the brief, understands it, executes. No 18 follow-up messages.
- Decisions documented somewhere durable (Notion, Confluence, a shared doc). When the offshore worker has a question about why something was decided, they can find the answer without DMing someone.
- Defined "I'm blocked" escalation paths. When the offshore worker hits a question they can't resolve from the docs, there's a clear way to flag it and a clear expectation about response time.
- Trust to make small decisions independently. The offshore worker shouldn't need to ask before every action. Define what they can decide alone, what needs input, and what needs explicit approval.
Companies that get these right successfully use offshore workers across 8+ hour timezone gaps. Companies that don't fail even with 4-hour overlaps because the work itself isn't structured for async execution.
Practical tactics that make timezone gaps work
Stuff I've seen genuinely move the needle:
Loom videos for hand-offs
Instead of a 30-minute meeting that requires both parties present, the senior person records a 3-minute Loom walking through what's needed. The offshore worker watches it during their day and acts on it. No timezone coordination needed.
The format works for: "here's what I want you to build this week", "here's the bug, here's how to reproduce it", "here's the customer's requirement, here's why I think they're wrong but we should accommodate them anyway".
"End of my day" written summaries
Last 10 minutes of the offshore worker's day, they write a brief summary: what got done, what's in progress, what's blocked. Sent to the client. The client reads it first thing in their morning. By the time they have questions, the offshore worker is starting their next day.
This single practice is worth more than four hours of synchronous meetings.
One synchronous touch per week
Most offshore relationships benefit from exactly one weekly sync, 30 minutes, video on. Not for status updates (those are written async). For relationship-building, judgment calls that need real-time conversation, and surfacing the things that are too uncomfortable to say in writing.
The mistake is over-doing this. Daily syncs across timezones burn everyone out. One per week is sustainable.
Decision logs in writing
Whenever a decision is made (even informally on a call), write it down somewhere durable with date and rationale. The offshore worker can refer to it later when context fades. The client can refer to it when they forget what was agreed. This sounds bureaucratic; in practice it eliminates the most common cross-timezone friction, which is "what did we decide last month."
What this means for your hire
If your work is iterative product development — feature builds, design iterations, anything where direction can shift mid-week — hire someone with at least 3–4 hours of daily overlap. For US East Coast clients that's anywhere in the Americas timezones. For UK clients that's Eastern Europe or West Africa. For AU clients that's most of Asia, including the Philippines.
If your work is clearly-scoped queue work — data entry, content production, manual testing, customer support tickets, transcription — overlap doesn't matter. Hire wherever the rate is best for the skill needed.
If your work is tech support — bugs surfaced by customers, infrastructure issues, urgent incidents — match the offshore hire to the timezone where your customers actually use the product. A B2B SaaS with mostly US customers needs offshore support during US hours, not 24/7 coverage.
If your work mixes shapes — which most SMBs do — hire one person whose timezone matches your most demanding work shape. The other shapes will work fine, just slightly less efficiently. Optimising for the demanding case is the right move.
What to do next
The last article in this series covers the management side: Treating Offshore Hires as Colleagues vs. Vendors. It pairs with the timezone tactics here — the right working hours don't help if the management practices are wrong.
If you'd like to talk about specific work and you're an AU-hours-friendly client (US East Coast, all of UK, all of AU, Asia), the Lead Steer monthly retainer is the most common shape clients land on.
---
Part of the Offshore Hiring pillar guide.