How We Run a Five-Person Team Across Four Timezones

The Problem Enterprise Remote Advice Won't Solve

Most writing about distributed teams assumes you have dozens of people, a head of "people ops," and enough overlap that you can always find someone awake. A five-person company spread across four time zones has none of that. When two people share a three-hour overlap window and the other three share a different one, the standard playbook—daily standups, "cameras on," recurring syncs—falls apart.

The real challenge isn't keeping people busy. It's preventing the gaps between work sessions from becoming information dead zones. Everything we've learned about running this way comes back to one idea: design for the gaps, not the overlaps.

Async Handoffs Over Status Updates

A standup tells you what someone did yesterday. A handoff tells the next person what to do right now. The difference matters when six hours pass between one person logging off and the next logging on.

Every work session ends with a written handoff—a short note answering three questions: What changed? What's the next decision? What will block progress if it isn't addressed?

This sounds like overhead. In practice, writing a handoff forces you to think about the work from the next person's perspective, which catches confusion before it compounds. A bad handoff surfaces in hours, not days—because the person reading it will immediately ask a clarifying question in the thread.

We tried templating these early on. It didn't stick. What stuck was a norm: if your handoff doesn't let someone else pick up the work cold, rewrite it. The standard is usefulness, not format.

Overlap Windows Are for Decisions, Not Updates

We have roughly two natural overlap windows each day where at least three people are awake and working. Those windows are scarce. Treating them like open office hours wastes them.

Our rule: overlap time is reserved for decisions that need real-time conversation. Everything else—status, questions with known answers, code review, design feedback—happens asynchronously. If you can write it down, write it down.

This means most synchronous calls last fifteen minutes or less. We don't schedule them on a recurring calendar. Someone posts a topic, tags the people needed, and proposes a time inside the overlap window. If no decision needs a call that day, no call happens.

The result: when we do get on a call, everyone arrives having already read the context. We're not narrating a situation; we're resolving it. That density makes the overlap windows feel like more than enough.

Decision Logs: Institutional Memory for Small Teams

A five-person team has no institutional memory except what it writes down. People forget why a decision was made. Context drifts. Someone revisits a settled question because the reasoning was never recorded.

We keep a decision log. Each entry captures the question, who was involved, what we decided, and—most importantly—why. The "why" prevents re-litigation. When someone wonders "should we reconsider X," they can read the original constraints and see whether any changed.

This log isn't a governance exercise. It's a practical tool that saves us from the most expensive failure mode on a small team: re-debating settled questions when we should be building.

The Trade-Offs We Accept

This approach has real costs. Some conversations take a full day to resolve across async threads that would take ten minutes in a room. Nuance gets lost in text. New team members need time to learn how to write handoffs that actually work.

We accept those costs because the alternative—forcing synchronous rituals onto a team that physically cannot be synchronous—creates a worse problem. It funnels all coordination through the one or two people who overlap with everyone else, burning them out and creating a bottleneck that defeats the purpose of a distributed team.

What We Optimize For

The goal is not to simulate an office. It's to let each person do their best work during their best hours and hand it off cleanly to the next person.

Three principles guide how we evaluate whether this is working:

Continuity. Can someone pick up work from a handoff without asking a single clarifying question? If yes, the system is working.

Decision velocity. Are decisions sitting unresolved for more than 48 hours? If yes, we're under-using our overlap windows or the wrong people are in the loop.

Re-litigation rate. Are we reopening the same questions? If yes, our decision log is incomplete or people aren't reading it.

None of this requires special tooling. It requires the discipline to write things down and the honesty to admit when a process isn't earning its keep. For a small team crossing four time zones, that discipline is the entire infrastructure.