Building software with engineers in 12 timezones
Practical patterns we've learned from running distributed engineering teams across four continents.
The first thing you discover when you run a globally distributed team is that nothing about your standup matters anymore. The 9am Tuesday call that holds a co-located team together becomes 11pm for one person and 4am for another, and the team will quietly fall apart around you while you keep going through the meeting motions.
What replaces it is writing. Written sprint plans, written tickets with acceptance criteria, written PR descriptions, written demo notes. The bar for "is this clear?" is much higher because you can't grab someone at the coffee machine to clarify.
The patterns that actually work
After five years and a few hundred projects, here are the patterns we keep coming back to:
1. Two-week sprints with public, written plans
Every sprint starts with a written plan committed to the project repo. Not a Jira board state — an actual sprint-43.md file that describes the goals, the planned work, the risks, and the demo target. It's reviewable, it's diffable, and a year from now you can read why a decision was made.
2. Friday demo videos, not Friday demo calls
Loom or a screen recording posted to the team channel beats a 9pm call across a 12-hour timezone gap. The video is searchable later. New team members can binge the back-catalog to onboard.
3. Dual leadership
Every Upaok pod has two leads — a tech lead and a delivery lead — in different timezones. Whatever hour someone needs an answer, one of them is awake.
4. The "single thread" rule
If a discussion is happening in three Slack channels, two PR threads, and a Notion comment, it isn't actually happening. We move every thread to one location — usually the GitHub issue — and link from everywhere else.
5. Quarterly in-person
Distributed doesn't mean never meeting. Most of our long-running pods do a 4-day in-person every quarter. It's expensive. It's worth it.
Things that don't work
We've tried "follow the sun" handoffs (one team passes work to the next at end-of-day). They're appealing on paper. In practice the handoff cost eats the throughput. What works is parallel work on different things, not serial work on the same thing.
We've tried mandatory overlap windows that span more than three hours. The team that loses sleep loses morale within a quarter.
The bigger point
The premise of Upaok is that the best engineers are everywhere. But the process to work with engineers everywhere isn't a free lunch — it has to be designed deliberately. Most of our engineering management work is making the process simple enough that brilliant engineers in different parts of the world can do their best work without being on the same call.
That's the trade. Get the process right, and the geographic ceiling on your hiring goes away.
All posts