The Four-Day Week for Global Teams: Whose Friday Gets Cut?

A four-day week is a straightforward policy for a company where everyone's in roughly the same time zone: pick a day, everyone takes it off, done. For a distributed team spanning multiple regions, the same policy has a question hiding inside it that a single-timezone rollout never has to answer — if everyone takes the same day off, does the team's combined working-hours overlap survive losing it, or does one already-thin overlap window disappear along with the day?

Why "everyone takes Friday off" can quietly break overlap

Consider a team split between London and San Francisco, whose working-hours overlap already runs a narrow band in the late morning Pacific time — a pattern covered in golden overlap windows by time zone pair. If both sides take Friday off, the team simply has one fewer overlap day a week, which is a clean and honest tradeoff — five days of coverage becomes four, evenly. The harder case is a team with three or more regions, where a single shared day off can eliminate the only day a particular pair of regions would have overlapped at all that week, rather than just shrinking coverage evenly across the board.

Three models, compared

Working out the staggered model

For teams choosing the staggered model, the day each region skips should be picked by which day costs the least combined overlap, not by convention. A region whose only real overlap with the rest of the team happens on a specific day should almost never take that day off — instead, look for the day each region already has the least meaningful synchronous interaction with the others, and let that be its day off. This sometimes means the "day off" isn't a Friday at all — a region with minimal Monday overlap might reasonably take Monday instead, which reads unusually from a single-timezone mindset but follows directly once you're optimizing for overlap survival rather than convention.

What to do about meetings that land on someone's day off

A staggered schedule inevitably creates weeks where a recurring meeting falls on one region's day off. Two honest options: reschedule the meeting for that week using the same fair rotation logic applied to a one-off conflict rather than a recurring slot, or explicitly convert that instance to async using the framework in the async-first decision framework. What doesn't work is silently expecting the person on their day off to show up anyway — that erodes the policy's credibility faster than almost anything else, since it signals the four-day week is real for some people and aspirational for others.

The productivity case doesn't disappear with staggering

The commonly cited results from four-day-week pilots — the UK's 2022 trial across 61 companies, most of which continued the policy afterward, reporting maintained or improved revenue alongside reduced reported burnout — were run mostly at single-location companies, so they don't directly validate a staggered distributed model. But the underlying mechanism they point to — that a meaningful chunk of a standard work week goes to low-value time rather than genuine output — applies just as much to a distributed team. Staggering trades some of the administrative simplicity of a shared day off for keeping that same productivity case intact without gutting the team's overlap.

Deciding which model fits your team

1. Map current overlap windows for every region pair using the SyncHours overlap planner, and check whether any pair's overlap is thin enough that losing a shared day would eliminate it.
2. If overlap is generous across all pairs, a fixed shared day off is simplest and works fine.
3. If any pair's overlap is fragile, stagger days off by region, picking each region's day around its lowest-overlap day rather than convention.
4. Set an explicit policy for what happens when a recurring meeting lands on someone's day off, before the first conflict happens rather than improvising it under pressure.