The short version
- Across a time gap, every clarifying question on a pull request costs a day. Two rounds of questions is a week for a change that took an afternoon.
- The fix is in the description, not the process. A reviewer who can decide without asking turns a three day review into a same day one.
- Four things a description must carry: what changes, why this approach, what you rejected, and where you want the reviewer to look.
- Small changes are the other half. A large change across a time gap is a week of round trips whatever the description says.
In one office, a reviewer with a question turns round and asks it. The whole exchange costs ninety seconds and never appears anywhere. With nine hours between author and reviewer, that same ninety seconds becomes a comment, a night, a reply, another night, and an approval on day three.
The arithmetic of a review round trip
Count in round trips rather than hours. A pull request that needs no questions is approved in one crossing. One question is two crossings, which on a large gap is two days. Two rounds of questions is most of a week.
Now notice what a developer does while waiting. They start something else, then come back and re read their own change to remember it, then context switch again for the second round. The waiting is not the only cost.
The fix is not to ask reviewers to be faster. Reviewers are usually replying within an hour of reading. It is to remove the questions.
Four things the description must carry
| Field | Question it removes |
|---|---|
| What changes, in behaviour | "What is this for?" Written as behaviour, not as a list of files touched. |
| Why this approach | "Why not do it the obvious way?" One or two sentences. |
| What I rejected | The single highest value line. It stops a reviewer proposing something you already tried. |
| Where to look, and what I am unsure about | "Is this ready?" Point at the risky part and say what you want checked. |
The third row does the most work. A reviewer in another time zone who thinks of a better approach has two options: leave a comment and cost a day, or approve with a doubt. Telling them what you already ruled out, and why, resolves it before it happens. The same logic as a decision log entry, applied to one change.
The fourth row is the one authors resist, because admitting uncertainty in a review feels weak. It is the opposite. A description that says "I am not sure the retry logic is right, please look hard at that" gets a better review and a faster one.
The reviewer's side
Three habits, all about not costing the author a day unnecessarily.
- Separate blocking from non blocking. Prefix comments that are merely suggestions. An author across a gap cannot ask which comments they must address, so they address all of them, which costs another crossing.
- Approve with comments where you can. If the only issues are style, approve and let the author decide. Holding approval for a preference is a day.
- Ask everything at once. Read the whole change before commenting. A drip of questions over two rounds is two days for something that could have been one message.
Set a review deadline in your own terms: every open review is looked at within your first working hour. That way the author knows the maximum wait, which matters more than the average. See response times in writing.
Size is the other half
No description saves a large change. A thousand line pull request across nine hours will generate questions, and those questions will be structural, and structural questions cost more than one crossing to resolve.
The practical rule for distributed teams is stricter than for co located ones: if a change would take more than twenty minutes to review, split it. The cost of a bad split is an extra merge. The cost of a large change across a gap is a week.
Where a change genuinely cannot be split, spend one live slot on it before writing any code. Agreeing the approach in the thirty minutes of overlap you have is cheaper than discovering the disagreement three days into review.
When the question is not about the code
A good share of review delay is not about the change at all. It is a reviewer wondering whether this conflicts with what someone else is doing, whether the client agreed to the new behaviour, or why the schema was set up this way in July.
The author may not know either. The person who does is asleep.
This is what StandIn is built for. At the end of the day each engineer spends about ninety seconds on a brief: what moved, what is open, what is blocked, what is next, mostly drafted from the work that already happened. A reviewer at 09:00 in another zone can ask where a piece of work stands or what was agreed, and get an answer from that brief in the person's words, with a source under it. It never guesses, and when the answer is not in the record it says so and names who to ask. The review stops waiting on questions that were never about the diff. See working across time zones and context loss in engineering handoffs.
Common Questions
Should we require a reviewer in the same time zone?
It makes reviews fast and knowledge local, which is the trade. Where the team is small, the better rule is that the reviewer is whoever is next online, with descriptions written well enough that anyone can review.
Is pair programming a better answer?
Where there is overlap, for hard changes, yes. It removes the review entirely. It also spends scarce shared hours, so it is worth reserving for the changes that would otherwise take a week.
What about merging without review when the reviewer is asleep?
Reasonable for low risk changes with a stated rule about what qualifies and a post merge review. Unstated, it becomes the default under deadline pressure and the review habit erodes.
How do we measure whether this is working?
Measure the time from opening to first comment, and the number of comment rounds. The second is the one that reveals a description problem, and it is the one that responds to these habits.
Executives had assistants. Everyone else had an out-of-office.
Give your whole team the coverage that used to stop at the corner office.