Pairing is expensive; so is the wrong async loop
Remote pairing burns scarce overlap: two people, one clock, plus reload tax on both sides when the call ends. Async pull request review is cheaper per minute and scales better across time zones. Neither is morally superior. The useful question is which mode finishes correct work with less total calendar cost.
GetToWork rule of thumb: default to async review with a clear ask; escalate to live pairing when the problem is a shared mental model, not a missing comment. Label that as a planning heuristic, not a study result.
This sits next to planning Feature versus Review days. That piece protects deep feature time from review thrash. This one decides when review should stop being async and become a short paired session instead. Depth still means a stable working set: deep work for developers.
Decision framework: four questions
Answer in order. Book pairing when you hit a yes that async cannot clear within one review cycle.
1. Is the blocker a missing shared model?
Yes examples: unfamiliar legacy module, unclear domain rules, incident where two hypotheses compete, first integration with a vendor API nobody has used. Two people looking at the same failing path often beats three async rounds of "try logging X."
No examples: naming nits, missing tests you can describe in a checklist, style, straightforward bug with a clear repro. Stay async.
2. Have two async review rounds failed to converge?
Count maintainer review plus author reply as one round. After two full rounds on the same design disagreement, a twenty-five-minute pair usually costs less than round three plus round four plus resentment.
If round one already produced a clear path and only polish remains, stay async.
3. Is the work high blast-radius or hard to reverse?
Migrations, auth, payments, data deletion, security boundaries: prefer a short design pair or a paired walkthrough of the risky path before merge, even if the PR looks "small." Async can still hold the record afterward.
Low blast-radius UI copy and isolated refactors rarely need live pairing for safety.
4. Is onboarding or knowledge transfer the real goal?
Teaching a teammate a subsystem by PR comments alone is slow and incomplete. Timeboxed pairing (driver/navigator, forty-five minutes, one learning outcome) is often the point - not a failure of async culture.
If nobody is learning and the PR is ordinary, do not pair for vibes.
Cost sketch you can do in two minutes
Assume:
- Pair length: 45 minutes
- Attendees: 2
- Reload tax after the call: 30 minutes each (GetToWork planning assumption - time your own week if you want a personal number)
- Total calendar cost: about 2.5 person-hours
Compare to async:
- Reviewer read + comment: 30 minutes
- Author revise: 45 minutes
- Second review: 20 minutes
- Possible third ping-pong: 40 minutes
- Total: about 2.25 person-hours when it converges cleanly
Async wins when it converges in one or two rounds. Pairing wins when you can already see the ping-pong coming - especially when debugging interrupts mean each async gap also destroys someone else's deep block.
If the alternative is five tiny clarification tickets, remember that five small tickets can cost more than one feature. One paired session that removes a nest of unblockers can be the cheaper shape.
Worked example: flaky payment webhook
Author opens a PR fixing a missed webhook signature case. Reviewer asks for more tests. Author adds tests that still flake in CI. Reviewer asks for a different stub. Author disagrees about where validation belongs. Two days pass. Both people are irritated. Feature remains unmerged.
Pair instead: twenty-five minutes sharing the failing CI log, agree validation lives at the edge adapter, write one characterization test together, author finishes alone async. Decision recorded in the PR description.
Calendar cost of the pair: lower than another two days of half-attentive back-and-forth across time zones.
When async PR review is clearly enough
- Clear acceptance criteria and screenshots
- Author left a test plan and risk notes in the PR body
- Change is localized and reversible
- Reviewer can run or reason about the change without a tour
- Disagreement is preference-level and a team style guide already decides it
Raise the quality of async before you raise the volume of pairing. A PR that says "please review" with no ask forces live conversation to invent the ask.
Pairing protocol that respects the calendar
- Agenda in the invite: one problem sentence, link to PR or failing test, hard stop.
- Roles: driver types, navigator directs; switch once if teaching.
- Timebox: twenty-five or forty-five minutes. If unfinished, write the next async steps before hang up - do not "just continue" into the afternoon by default.
- Residue: three bullets in the PR or ticket: what we decided, what we tried, who owns the next commit.
- Protect Feature days: do not sprinkle ad hoc pairs across a deep feature block. Batch pairing into a labeled window when you can.
Camera optional. Shared editor or shared terminal required. Status small talk optional and short.
Anti-patterns
Pairing as surveillance. Watching someone type ordinary code because trust is low. That is management debt, not engineering practice.
Endless pair as social default. Full-day pairing remote is exhausting for many people and destroys parallel throughput. Use it as a tool, not a lifestyle brand.
Async avoidance. Booking a pair because writing a clear PR description felt harder. Write first.
Review theater after a pair. If you already agreed the design live, do not demand a performative async rewrite of the same debate. Check for the agreed tests and ship.
Time zones and pairing windows
If your team spans regions, do not "just jump on a call" at the worst hour for the person who already holds the context. Reserve one or two short overlap slots per week labeled for pairing and hard debug only. Outside those slots, async is the default even when someone is impatient.
A twenty-five-minute pair at a fair overlap beats a sixty-minute pair that forces one engineer into late evening fog. Tired pairing produces confident wrong decisions. Put the fair slot on the team calendar the same way you protect a Feature day.
What to put in the PR before you ask to pair
Raise the odds that async still wins:
- Decision you want from the reviewer (approve path A, pick between two designs, confirm risk).
- Test plan and what you already ran.
- Risk notes for blast-radius areas.
- Screenshot or failing log excerpt, not a vague "it broke."
- Time you are blocked until (UTC).
If you cannot fill those five, you are asking for a tour guide, not a review. Pairing may still be right - but name it as a model-building session, not as "quick review."
Measuring whether pairing is paying off
For two weeks, tag each pair invite with the question that triggered it (shared model, failed async rounds, blast radius, onboarding). At the end, count how many produced a merge or unblocked decision within a day. If most tags are "felt faster" with no residue and no faster merge, you are socializing, not compressing confusion. Cut volume and raise the bar back to the four questions.
Before and after
Before: Team culture says "we are async." Hard bugs still take a week of comments. Overlap is spent on status meetings instead of the one paired debug that would have ended the thread.
After: Team keeps async default. A posted rule lists the four questions. Overlap is reserved for shared-model work and onboarding pairs. Ordinary PRs stay written. Calendar cost drops because the expensive mode is used on purpose.
Remote pairing earns its cost when it compresses confusion that comments cannot. It wastes its cost when it replaces a checklist. Use the four questions, timebox the call, and leave residue so the next person does not need a sequel.