Pair Programming Across Timezones

Priya in Bangalore had been stuck on the same race condition for two days. It only showed up under load, only sometimes, and it lived deep in a payments subsystem that exactly one other person understood: Marco, in Lisbon. Their working hours overlapped for about ninety minutes a day, right at the end of hers and the start of his. On the day she finally got him on a call, they spent the first thirty minutes in the team standup and another twenty on a status sync about an unrelated project. That left them maybe fifteen real minutes on the bug before Priya had to leave to catch her train. Marco said he'd "take a look." He looked async, left three comments, and the actual fix landed four days later after a slow back-and-forth that a single focused hour together would have closed on the spot.

Nobody decided to handle it that way. That's the point. The overlap window was there, it was just spent on the things that felt like defaults, and the one thing that genuinely needed two people in the same room at the same time got the scraps. This happens on distributed teams constantly, and it's why so many of them have quietly stopped pairing altogether.

The practice that disappeared

Pair programming was never universally loved, but on a co-located team it happened whether or not anyone called it that. You'd roll your chair over. Someone would lean on your desk and say "wait, show me that again." A junior would watch a senior debug and absorb, in twenty minutes, a way of thinking that no document teaches. None of it was scheduled. It was a byproduct of sharing a room.

Distributed teams delete that byproduct and then never replace it, because replacing it takes a calendar and the calendar is the enemy. Pairing needs a live block where two specific people are both awake, both focused, and both free. Across a nine-hour gap those blocks are rare and precious, and it feels responsible to protect them for "real meetings." So pairing gets reclassified as a nice-to-have, the first thing cut when the day is tight, and within a few months a team that used to solve hard problems shoulder to shoulder is solving them entirely through pull request comments written eight hours apart.

I think that's a genuine loss, and a mostly invisible one, because nothing breaks loudly when you stop pairing. The bugs still get fixed, just slower. The juniors still ship, just without ever watching how a senior actually works. The cost shows up as a team that's a little slower and a little lonelier than it should be, and no line in any dashboard explains why.

Some work is worse async, not just slower

The async-first argument is right about most things. Status belongs in a written update, not a meeting that eats everyone's focus block. Most code review should be thorough written comments in a queue, not a call. Most decisions can wait for a proposal and a deadline. If you've read anything else on this blog you know I'll almost always tell you to push a thing async.

Pairing is one of the exceptions, and it's worth being precise about which work earns a live hour. A gnarly bug where the feedback loop is "try something, watch what happens, react in real time" is miserable async, because each cycle of that loop costs a full sleep. So is teaching. When a senior and a junior work through a problem together, the value is in the thinking made visible, the small asides and dead ends and the "here's why I'd never do it that way" that never survives being written up after the fact. Ambiguous design work is the third case: two people sketching toward something neither can fully specify yet, where the point is fast, messy, interruptible back-and-forth. Run that through a comment thread and you get a week of people talking slightly past each other.

The tell is the round-trip count. If solving the thing will take one clean handoff, async is fine, maybe better. If it needs five or ten quick exchanges to converge, every one of those exchanges is a night when it's async, and the same work compresses into one shared hour when it's live. That's not a small difference. That's the difference between a Tuesday afternoon and most of a week.

Spend the overlap on the pairing, not the standup

Here's the reframe that would have saved Priya four days. Your overlap window is the single scarcest resource your distributed team has, and pairing on hard problems is close to the highest-value thing you can do inside it. So stop letting lower-value synchronous rituals colonize it by default.

The standup did not need to be live. It could have been a thread everyone posts to on their own schedule. The status sync definitely didn't need to be live. Both of them ate the only real chance for the one activity that did, and they ate it because they were on the calendar and pairing wasn't. When you decide who takes which meeting slot, treat a booked pairing session as more protected than a status meeting, not less. If the overlap is ninety minutes and a hard bug is blocking someone, the standup is what moves to async that day. Pairing is the thing you build the window around.

You also have to make pairing legible as work. On a lot of teams, two engineers on a call for an hour reads as less productive than two engineers each heads-down in a corner, so people feel vaguely guilty about it and skip it. That instinct is backwards for the class of problem pairing is for. An hour of two people unblocking a four-day bug is one of the best trades your team will make all week. Say so out loud, so nobody has to defend it.

When you can't overlap at all, pair anyway

Sometimes the gap is just too wide and there's no shared hour worth the name. That's real, and it's where a little craft helps, because "pairing" doesn't have to mean two faces on a video call at the same instant.

Ping-pong through the pull request. One person writes a failing test and a rough first pass, pushes, and hands off with a note about where they're stuck. The next person, waking up as the first goes to bed, takes the baton, pushes their piece, and hands it back. It's slower than a live session but far faster than a normal review cycle, because each of you leaves the code in a state the other can pick up cold. This is really the handoff note applied to a single problem instead of a whole task, and it only works if the note is good.

Record yourself instead of writing everything up. When a senior wants to show a junior how they'd approach something, a ten-minute screen recording talking through the actual keystrokes carries most of what an over-the-shoulder session would, and the junior can watch it at their hour and rewatch the confusing part. It's not as good as being there. It's dramatically better than a paragraph that says "you should refactor this." And for the genuinely creative divergent work, some of it can move to a written, think-before-you-read format where the async structure is a feature rather than a consolation prize.

Don't let the same person always take the 6am session

One last thing, because it poisons the whole practice if you ignore it. When a pairing block only fits at the very edge of someone's day, that edge tends to land on the same person every time, and it's usually not the one who shares hours with headquarters. If the junior in Manila can only pair with the senior in Denver at 7am her time, and that becomes the standing arrangement, you've built her growth on top of a permanent early alarm while the Denver engineer pairs comfortably at mid-afternoon.

Rotate who eats the awkward hour. Have the senior take the uncomfortable end of the day sometimes so the junior doesn't carry it alone every week, the same way you'd rotate the odd meeting slot rather than parking it on one person forever. Pairing is supposed to be how your less experienced people get better and feel less alone in the work. If the only version of it available to your far-timezone folks costs them sleep, they'll stop asking, and you'll have recreated the exact isolation you were trying to fix.

None of this is an argument to pair on everything. Most of the work should stay async, and pairing on a task that didn't need it just burns your rarest hours on a problem a comment could have solved. The skill is telling the two apart: knowing which bug, which lesson, which half-formed design genuinely needs two minds live, and then spending your overlap on that instead of on the standup you could have posted in a thread. Get that judgment right and the timezone gap stops eating your hardest problems one sleep cycle at a time.

Stop Losing the Overlap to Timezone Math

The hardest part of pairing across timezones is often just finding the window: when your ninety minutes of overlap actually falls, and whether a proposed session lands mid-afternoon for one person or at 6am for the other. Timely converts every time mentioned in Slack to each person's own clock automatically, so when you say "let's pair at 3pm my time," the engineer nine hours away sees exactly when that is for them and whether it's fair to ask. Less arithmetic about whose morning it is, more of your scarce overlap spent on the actual problem.

Add Timely to Slack — Free · See how it works