How to Review Code Across Timezones

A four-line change once took three days to merge on a team I worked with. Not because it was hard. The author was in Bangalore, the only reviewer who knew that part of the codebase was in Toronto, and the two of them shared about ninety minutes of waking overlap a day. The author opened the PR at the end of her Tuesday. The reviewer got to it Wednesday his time, left one comment asking why she'd changed a default, and logged off. She answered Thursday morning her time, he approved Thursday evening his time, it merged Friday. Four lines. Three days. The code was never the slow part.

Every engineering team has a review queue. On a co-located team it moves fast because the reviewer is eight feet away and you can lean over and say "can you look at this?" On a distributed team that same queue quietly becomes the single biggest thing standing between your work and production, and almost nobody measures it.

The pull request is a dependency with a bedtime

Here's the reframe that changed how I think about this. An open pull request is a blocked task. The author can't cleanly move on until it merges, and the thing unblocking it is another person's attention. On a team in one office, that attention is available more or less continuously through the workday. On a team spread across the planet, it's available for whatever narrow band of hours your two calendars happen to share, and not a minute more.

So the review isn't waiting on effort. The Toronto reviewer would have spent maybe six minutes on that four-line PR. It was waiting on him being awake at the same time as a decision needed making. That's the whole problem in one sentence: the cost of review on a distributed team isn't the reviewing, it's the round-trips, and each round-trip is priced in sleep cycles. This is the same shape as a handoff that lands while the other person is offline, except it repeats on every back-and-forth instead of once.

Every question costs a full day

Do the arithmetic on a single review comment and it stops looking small. When author and reviewer have little or no overlap, every exchange is a day. Reviewer asks a question at the end of their day. Author sees it, answers it, at the start of theirs, which is the middle of the reviewer's night. Reviewer reads the answer their next morning. One question, one answer, roughly twenty-four hours gone, and most of it was two people asleep.

A PR that needs three rounds of back-and-forth isn't a little slower across timezones. It's three days minimum, and that's if nobody takes a day off or misses the notification. I've watched a good change take a week to land because it drew four rounds of thoughtful comments, each one individually reasonable and collectively most of a sprint. The reviewer wasn't being difficult. The medium was.

Once you see review as a series of day-long round-trips, the fixes stop being about reviewing harder and start being about needing fewer trips. That's the game. Cut the number of times the ball has to cross an ocean.

Small pull requests are a timezone strategy

The one habit that helps most here is shrinking the PR. This is decent advice on any team and near-mandatory on a distributed one, for a reason that has nothing to do with code quality and everything to do with round-trips.

A 600-line PR is a magnet for comments. It touches more things, invites more opinions, and hides the one real problem among ten style nits, so it reliably generates several rounds of discussion, which on your team means several days. A 40-line PR gets a glance and an approve. It's not that reviewers are lazy about small changes. It's that small changes genuinely have less surface for a reviewer to catch on, so they clear in a single trip instead of four.

So the discipline is to break work into pieces that can each be reviewed in one pass. Land the refactor in its own PR, separate from the feature it's clearing the way for. Send the boring rename by itself so it doesn't clutter the diff that actually needs eyes. Yes, this is more PRs and more overhead per PR. On a co-located team that overhead might not be worth it. When each review round is a calendar day, it pays for itself the first time a change merges in twelve hours instead of three days.

Give review a clock, not a vibe

Most teams have an unwritten rule that you should review PRs "promptly." On a distributed team, "promptly" is a word that means nothing, because the reviewer's prompt is the author's midnight. You need an actual number, and it has to be written in the reviewer's day, not the author's.

Pick a norm and say it out loud. Something like: a review request waiting when you start your day gets looked at before you pick up your own deep work. Not same-hour, which is impossible across timezones and would just shred the reviewer's focus, but same-working-day on the reviewer's side. That single commitment collapses the worst case. A PR opened in Bangalore on Tuesday evening gets its first pass during Toronto's Wednesday, guaranteed, instead of whenever the reviewer happens to notice. A review SLA is really just a written rule for how fast a reply should come, and in whose clock, pointed at the one queue that most directly gates shipping.

The clock matters as much as the number. "Review within a day" is ambiguous the moment it crosses a border, the same way every vague time reference quietly costs a team hours. Anchor it to the reviewer's working day and the ambiguity disappears.

Don't let one person be the only reviewer

The Bangalore-to-Toronto delay had a second cause hiding under the first. There was exactly one person who could review that part of the codebase, and he lived twelve hours away. When your only qualified reviewer for a subsystem sleeps while the author works, you've built a bottleneck that no amount of PR-splitting fixes.

The fix is slow and worth it: make sure more than one person, ideally in more than one timezone, can competently review each important area. That means deliberately routing reviews to spread knowledge instead of always sending payments PRs to the one payments expert. It's slower for a few weeks while the second reviewer comes up to speed, and it feels inefficient. Think of it as the review version of writing down how things work so the answer doesn't live in one head. A subsystem only one sleeping person can approve is a subsystem that ships on that person's schedule, and you will feel it every single week.

Write the review, don't schedule the call

When a review gets complicated, the reflex on a struggling team is "let's just hop on a call." Sometimes that's right. Usually, across enough timezones, it's a trap, because scheduling that call means waiting for the next overlap window, which might be tomorrow, which is slower than just writing the thing down would have been.

A good written review does more work than people expect. Explain the concern fully, in prose, the way you'd explain it if the author couldn't ask a follow-up for eight hours, because they can't. Give the reasoning and not just the verdict, point at the specific line, and suggest the change concretely enough that the author can act on it without a second round. This is async-first communication in its purest form: assume the other person is asleep and write something complete enough that they don't need you awake to use it.

There's a real cost here. Writing a thorough review comment takes longer than saying it out loud. But you're trading a few extra minutes of writing against a full day of round-trip, and on a distributed team that trade is almost always worth making.

When you should just get on a call

I don't want to pretend async review handles everything. Some conversations are faster live. A sprawling architectural disagreement, where two engineers keep talking past each other in comments, can burn a week of round-trips going nowhere when thirty minutes of talking would settle it. The rule of thumb I use: if the same point comes back a third time in writing, the medium has failed and it's time for a call. Everything short of that, write it down. Protect the live hours for the arguments that need them, and let ordinary reviews flow through async, so nobody's deep-work block gets sacrificed to a meeting a paragraph could have replaced.

Make Every Review Deadline Read Right

Review moves faster when nobody's guessing what "by end of day" means. Timely converts every time mention in Slack to each person's own clock automatically, so "I'll review this before 3pm" or "let's sync at 10 if the thread stalls" lands correctly whether your reviewer reads it in Toronto or Bangalore, and no round-trip gets lost to a misread hour.

Add Timely to Slack — Free · See how it works