Shipping Code 24/7 With a Distributed Team
Mahdin M Zahere
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?
Loved by top marketers
"We feel pretty embedded in Surface, especially since we did the PLG stuff there. I would consider Surface to be like a pretty core part of what is running our website, which is a good thing."

Maddy Fennessy
Growth Marketing Lead
“If we turned off Surface tomorrow, we’d lose a lot of inbound. We’re almost entirely inbound-driven, so Surface is a critical part of how we operate.”

Shubh Agrawal
San Francisco
"We actually saw that 37% more users on average converted with the new form that they built for us"

Alexandra Doan
San Francisco
"We’re growing at the speed of light, and Surface is one of the few vendors keeping up with us. I'd pay whatever it takes to solve this problem—and Surface solved it."

Pujun Bhatnagar
CEO
“Whenever I had a feature request, the Surface team would update me throughout the process and follow up after launch to make sure everything was working correctly. It really feels like a white-glove experience.”

Angela Kou
Chief of Staff

"We used Typeform in the early days. It was great but you can tell when a company outgrows it. Surface gives us the mechanics we liked from Typeform, but with enterprise-grade control over brand, format, and functionality."

Ian Christopher
CEO

