Brazil sits four to five hours ahead of U.S. Pacific time on ordinary Brazilian working hours, which gives a Pacific team roughly a shared morning and nothing else. Teams that struggle with that usually blame the time zone. The thing that actually broke is code review, and it broke because review is the one ritual that quietly assumes both people are at their desks.
Eastern-time teams rarely notice: the overlap is nearly the whole day. Pacific teams notice in week two. Here is what works.
The pull request has to stand on its own
In a co-located team, a thin PR description is fine because the author is three metres away. Across a four-hour window, a PR titled "fix checkout" costs a full day: the reviewer reads it at 8 AM Pacific, does not understand the intent, asks, and the answer arrives the next morning.
The rule that fixes it is small and it is the author's job: every pull request answers four questions in its own description.
- What changes for the user or the system? One sentence, not the diff restated.
- Why this approach? Name the alternative you rejected and why. This is the single highest-value line, because it pre-empts the most common review question.
- What did you not do? Scope you deliberately left out, so the reviewer does not report it as a gap.
- How do I check it? The command, the URL, the test, the thing to look at.
Four lines. They cost the author five minutes and they routinely save a day of round trip. If your team adopts exactly one thing from this piece, adopt this one.
Review on a clock, not on a whim
"I will get to it" is a perfectly good policy in one time zone and a bad one across four hours. Two commitments make review predictable:
- Anything opened before the end of the Brazilian day gets a first response during the next shared window. A first response can be "looks right, one question" — it does not have to be a full review. What matters is that the author is not blocked for a day waiting to find out whether they are blocked.
- The shared window is for interaction, not for solo work. Pacific teams that use the overlap to do their own deep work and then review in the afternoon have converted a four-hour overlap into a zero-hour one.
The overlap calculator shows the exact shared window for your zone, including how it shifts when the U.S. changes its clocks and Brazil does not. Put that window in the calendar as a real block; a window nobody defends is not a window.
Cap the round trips at two
The pathological case is not a hard review — it is an easy one that takes four days because each exchange costs a day. Adopt a hard rule: after the second round trip on the same pull request, whoever is holding it schedules fifteen minutes inside the shared window and finishes it live.
Two round trips is the right threshold because the second one almost always means the disagreement is about design rather than code, and design disagreements do not resolve well in comment threads in any time zone.
Split the work so the blocking direction is rare
Most overlap pain is a symptom of ownership, not of geography. If every change the Brazilian engineer makes needs approval from someone on Pacific time, you have built a pipeline with a daily stall in it. Two adjustments remove most of that:
- Give real ownership of a surface. A service, a module, a domain — something where they are the approver, not the approved. Ownership is what turns a nine-hour gap from a blocker into a handoff.
- Pair reviewers by time zone where you can. If there are two engineers in Brazil, most of their reviews should be each other's, with the U.S. lead reviewing the architectural changes rather than every diff.
This is also why a tech lead is sometimes the better first nearshore hire than a second senior engineer: the lead absorbs the approval role that would otherwise stall every day at 1 PM Pacific.
Use the handoff, do not fight it
The nine hours when the Brazilian engineer is offline are not lost time — they are the U.S. team's uninterrupted afternoon, and they are when the next day's work gets unblocked. The teams that do this well end the shared window deliberately: a three-line written handoff from each side saying what is done, what is blocked and what the other side should look at first.
Done consistently, that handoff is worth more than an extra hour of overlap, and it costs nothing. The time zone guide has the arithmetic for every U.S. zone, and the mistakes guide covers the ones that show up after the hire rather than during it.
Put the standup at the edge, not in the middle
A detail that costs teams an hour a day without anyone noticing: a standup scheduled in the middle of the shared window cuts the window in two, and the two halves are each too short for real collaboration. Move it to the first fifteen minutes of the overlap and the remaining hours stay contiguous.
Better still for a four-hour window: make the standup written and keep the live time for the things that need a human. A three-line update posted before the window opens — done, next, blocked — gives the U.S. team something to read with their coffee and turns the first live minutes into "let us unblock you" rather than "let us take turns describing yesterday."
When four hours genuinely is not enough
Be honest about the exception. If your product requires a daily live design session in the Pacific afternoon, or your on-call rotation needs coverage until 8 PM Pacific, four hours will not carry it and no amount of written discipline will fix that. The answer there is either to move the ritual into the shared window, or to accept that this particular role is not a fit for the time zone — and it is much better to say so before signing than to discover it in month two.
Everything else — review, planning, incident triage, architecture — works fine on four hours, provided the written artifacts are good enough that being offline is not the same as being unavailable.