Best Practices for Team Leave Policies in Distributed Teams

The question that isn’t as simple as it sounds

“Who’s out today?” is a simple question for a single-office team — everyone shares the same calendar day. It stops being simple the moment a team spans more than one time zone, because today itself becomes ambiguous: is it the requester’s local calendar day, the approver’s, or whoever happens to be checking?

This isn’t a hypothetical edge case for most modern teams. Buffer’s 2023 State of Remote Work survey — 3,000 remote workers surveyed globally, collected October–November 2022 — found that 14% of respondents named working across time zones as their single biggest struggle with remote work, and separately, 92% of remote teams span at least two time zones by structure alone. A leave policy that quietly assumes everyone shares one calendar day is built on an assumption most distributed teams don’t actually meet.

Practices that actually hold up across time zones

Anchor every leave record to the employee’s own timezone, not the admin’s. A date range submitted by someone in America/Los_Angeles and reviewed by an approver in Europe/Warsaw needs to resolve to the same calendar days regardless of whose clock is doing the checking. Storing an explicit IANA timezone per person — not inferring it from whoever happens to be looking — is what keeps “the 15th” meaning the same thing to everyone involved.

Make the forward-looking window explicit, not implicit. “Who’s out this week” means something different depending on which day the week is anchored to. A “Today / Next 2 weeks / Next month” selector, rather than a single fixed view, lets a distributed team check availability on terms that make sense for whatever decision is being made — a same-day question needs a narrower window than sprint planning two weeks out does.

Decide public holidays per team, not organization-wide. A distributed organization spanning the US, UK, and Germany doesn’t share one holiday calendar — assuming it does either double-charges someone’s balance for a holiday their region doesn’t observe, or fails to exclude one their region does. This is worth configuring explicitly per team rather than picking one region and hoping it’s close enough for everyone.

Don’t let approval routing assume same-timezone availability. An org-wide default approver who’s asleep during the requester’s entire working day creates exactly the kind of silent delay the Confluence-specific piece on this series covers — the request isn’t lost, it’s just sitting unattended for hours nobody currently online can do anything about. A fallback path (a second approver, or an automatic escalation after a set delay) matters more for distributed teams than co-located ones, where “just ask in person” isn’t an option.

Keep contractor and non-account-holder handling explicit. Distributed teams disproportionately rely on contractors across jurisdictions specifically because remote work makes that easier — which makes logging leave for people without an Atlassian account a distributed-team-specific need more often than a co-located team’s.

How OutSync applies this

Every employee record OutSync stores — including manual members added for contractors without an account — carries an explicit IANA timezone, used specifically to anchor date-range leave requests to that person’s own calendar day rather than whoever’s checking. The “who’s out” panel’s Today/Next 2 weeks/Next month window, the per-team public holiday region, and the org-wide-default-with-fallback approval routing are the same features covered elsewhere in this series — the point here is that none of them are distributed-team-specific add-ons. They’re the same design decisions a single-office team benefits from too, just decisions that become non-optional the moment a team spans more than one clock.

Related reading

• The Ghost Resource Problem: Why Sprints Plan Around People Who Are Out
• Confluence Team Availability: Keeping Documentation Teams in Sync