Shipping Code 24/7 With a Distributed Team

Our codebase never sleeps. Someone on the team is always shipping.

This isn't a flex about hustle culture. Nobody at Surface Labs is pulling all-nighters or working weekends because they feel pressured to. We're distributed across time zones — and by design, that means when our US-based engineers log off for dinner, our team members in other time zones are picking up where they left off.

The result: while other startups wait for Monday morning standup, we've already shipped three times.

How it actually works

The key word is "async." Not "always on." The difference matters.

We don't have synchronous standups. We have async updates — every engineer posts what they shipped yesterday, what they're working on today, and what's blocking them. This happens in a shared channel, at whatever time their workday starts. Nobody needs to be online at the same time for the team to have full context.

PRs don't wait for a specific person to be online. We've structured code ownership so that at least two people in different time zones can review any given PR. When an engineer in timezone A opens a PR at end of day, an engineer in timezone B reviews it at start of their day. The PR merges before engineer A wakes up. No Slack pings. No "hey, can you review this?" blocking messages.

Deploys happen continuously. We ship to production multiple times per day — not because we're moving recklessly, but because our CI/CD pipeline, test coverage, and feature flag system make it safe to deploy whenever a change is ready. A deploy doesn't need a ceremony. It needs passing tests.

The rituals that make it work

Written context, always. Every PR has a description that explains the "why," not just the "what." Every design decision is documented in a brief doc before implementation starts. This isn't bureaucracy — it's the only way async works. If someone picks up your work 8 hours later, they need to understand your thinking without scheduling a call.

Clear ownership. Every project has an owner. Not a "team." Not a "pod." A person. That person makes decisions, breaks ties, and is accountable for delivery. When ownership is clear, async coordination is easy. When ownership is ambiguous, everything requires a meeting.

Weekly sync — the one meeting that exists. We have one synchronous team meeting per week. 30 minutes. Focused on decisions that require real-time discussion — architectural trade-offs, priority changes, cross-team dependencies. Everything else is async.

Trust over surveillance. We don't track hours. We don't monitor screens. We track output — what shipped, what's working, what's not. If the deploys are happening and the metrics are moving, the process is working. If they're not, we fix the process, not the people.

The competitive advantage

Speed compounds. A team that ships Monday, Tuesday, and Wednesday while another team is still in sprint planning has a structural advantage that grows every week.

Our distributed setup means we're effectively running a 16–18 hour development cycle without anyone working more than 8 hours. Features get built, reviewed, deployed, and iterated on faster than they would with a co-located team operating on a single timezone's schedule.

This isn't theoretical. We've shipped features that went from design to production in 48 hours — across three time zones, with three engineers who never had a real-time conversation about it. Written context did all the work.

What we got wrong at first

It wasn't smooth from day one. Early on, we had too many synchronous meetings (a habit from co-located culture). We had PRs that sat for 12+ hours because only one person could review them. We had context that lived in people's heads instead of in docs.

We fixed each of these one at a time. Dropped meetings. Expanded review permissions. Made documentation a non-negotiable part of every PR and design process.

The lesson: distributed teams don't fail because of time zones. They fail because of poor information architecture. Fix how information flows and the time zones become an advantage, not a limitation.

How does your team handle async work? What tools do you swear by?