Pair Programming Fixed Our Pull Request Bottlenecks

Modern Software Engineering (Dave Farley) — clip from The Engineering Room podcast · video · 2025-07-11 source ↗ Reader 🖥️

Lean & Toyota Way Pair & Mob Programming Psychological Safety Pull Requests & Async Code Review Trunk-Based & Continuous Delivery

Pair programming did not just make pull-request review faster for this team — it made the pull-request gate itself unnecessary, because the review, the four-eyes compliance requirement, and the knowledge-sharing that PRs exist to provide were already satisfied continuously by working together, which let the team drop branches entirely and move to minutes-long commit-to-production cycles.

practical · narrative — A first-person case-study interview: a team lead recounts, conversationally with Dave Farley, how adopting pairing dissolved their pull-request bottleneck and what changed afterward. The argument is carried by anecdote and self-report, not formal evidence.

Structure

Part	Role
Origin: large PRs and PR daisy-chains forced the tech lead to mandate reviewing together instead of throwing work back and forth.	context / trigger
Claim that pairing makes PR review redundant: the work arrives already reviewed, PR approval becomes a 2-3 second formality, and the team treats it as 'just compliance' satisfying a four-eyes requirement rather than real review.	thesis statement
Mechanics: flow-state protection from interruption, driver/navigator rotation every 7-10 minutes, direct onboarding into rotation, continuous micro-learning baked into daily work.	evidence — how pairing produces the review/knowledge-sharing substitute
The 'waste clock': once pairing exposed the cost of small frictions (slow local builds, duplicate CI runs on branch + main), the team removed branches entirely because merge conflicts had become almost nonexistent.	evidence — second-order effect of pairing
Organizational friction: a change-management culture (ITIL-style, big infrequent releases) resists high-frequency deployment, contrasted with the team's own history (a single flown-in release manager in 2011-12 vs. five minutes commit-to-production now).	context / counter-force
Outcomes: very few production defects, and when they occur the minimal change size makes the fault obvious.	conclusion / result

Key terms

waste clock
A self-devised ritual/mindset for continuously surfacing small, individually-tolerable inefficiencies (a two-minute build, a duplicate CI run) that compound into real cost — framed as something everyone, not just developers, is subject to.
four eyes
The compliance requirement that two people be involved in a change — satisfied, in this team, by the pair itself, with the pull-request approval reduced to a rubber-stamp artifact that merely records the requirement was met.
feedback junkie
A half-joking label for the state of having adapted to fast feedback loops so thoroughly that any slower loop becomes intolerable — presented as the 'only downside' of continuous improvement via tightened loops.

Propositions

explicitWorking in pairs made large pull requests unnecessary because review happens as the work is produced, not after it's finished.conf: high
explicitThe team satisfies its 'four eyes' compliance requirement through pairing itself, not through genuine PR review; the pull request has become a compliance formality rather than a real review gate.conf: high
supportsFour Eyes Without Pull Requests · p7 — Direct real-world confirmation of the claim that teams keep PR approval mainly because they assume compliance demands the artifact, even once the actual review has already happened elsewhere.
explicitThe team measured their own pull-request overhead at roughly two to three seconds per PR because approval is automated/aliased and the review itself already happened during pairing.conf: high
supportsFrom Async Code Reviews to Co-Creation Patterns · p2 — The guest explicitly cites Dragan Stepanović's research on PR wait-time-per-size as the framework for understanding their own near-zero (2-3 second) review overhead under pairing — an explicit, named cross-reference between these two sources.
explicitBreaking a developer's concentration costs roughly 15 minutes to regain flow state; pairing acts as a buffer against outside interruptions (email, Slack) because the other person absorbs or deflects them.conf: high
explicitBecause pairs maintain tight shared context, merge conflicts became almost nonexistent, eliminating the practical need for feature branches.conf: high
supportsOn Pair Programming · p3 — Concrete case of pairing-plus-trunk-based-integration making delayed PR review not just redundant but actively in the way, matching the claim that pairing and trunk-based CI are complementary and PR review is weaker once code already merges.
explicitThe team eliminated running CI twice (once on a feature branch, once on main) once they recognized it as pure waste after branches became unnecessary — a change the guest says an individual working alone couldn't have pushed through against team pushback.conf: high
explicitcorroboratedReal pairing is distinguished from one-off mentoring by fixed-interval driver/navigator rotation (every ~10 minutes for pairs, ~7 minutes for larger groups); new team members (junior or senior) are onboarded directly into this rotation rather than given separate mentoring sessions.conf: high
supports ←Software Teaming: A Mob Programming, Whole-Team Approach · p3 — Independent corroboration of the same specific detail — roughly seven-minute driver/navigator rotation for larger groups.
explicitPairing produces continuous micro-learning (IDE shortcuts, design quirks, small efficiency tricks) baked into daily work, which the guest considers faster and more effective than teams that rely on separate, documented knowledge-sharing sessions.conf: high
supports5) Vidar Moe: Det eneste Vidar vil er å ha det lett · p8 — Both sources independently converge on pairing as the most effective channel for knowledge transfer, continuous and incidental rather than a separately scheduled activity.
explicitcorroboratedAfter adopting pairing, the team reports very few production defects, and when they do occur, the minimal size of each change makes the fault's location almost always obvious.conf: high
supports ←Software Teaming: A Mob Programming, Whole-Team Approach · p14 — The book's cited defect-rate reduction for paired/teamed work is the theoretical backing for the independently reported near-zero production defects after adopting pairing.
implicitA change-management culture built around infrequent, large, carefully-gated releases (the guest's ITIL reference) is organizationally threatened by high-frequency deployment, independent of whether the practice that enables it (pairing) actually works.conf: medium
explicitPairing's long-run benefits are real but resist measurement — the team experiences the improvement without being able to quantify it, which the guest treats as an acceptable (even expected) limitation rather than a weakness of the practice.conf: high

Arguments

Adopting pairing as a team's working default removes the pull-request bottleneck rather than merely making pull requests faster or smaller.

Explicit premises:

Review already happens live during pairing, so the post-hoc PR gate adds no new review value.
The compliance 'four eyes' requirement is satisfied by the pair, so PR approval becomes a formality rather than a control.
Shared context from pairing nearly eliminates merge conflicts, removing the practical need for long-lived feature branches.
Once branches became unnecessary, previously invisible waste (duplicate CI runs on branch and main) became visible and removable too.

Implicit premises:

PR review's actual value comes from 'two people genuinely engaged with the change,' not from the artifact or the merge gate itself — so any practice that produces that engagement without the gate is at least equivalent.
A team's collective authority (vs. one developer alone) is required to remove organizationally-accepted waste, because individual complaints about small, normalized costs get dismissed.

Inferences:

Removing the PR gate doesn't just save review time — it exposes a backlog of adjacent waste (slow local builds, duplicate pipeline runs) that the gate had been obscuring, which a team can then also eliminate.
If four-eyes compliance can be satisfied by the pair itself, the PR's remaining function in a pairing team is purely an audit-trail artifact, not a review mechanism — raising the same question Morris's and Laforgia's pieces ask: how do you produce that audit trail without reviving the PR gate?

Narratives

Discovering that a two-minute Maven build (accepted for years as 'how the world is') became intolerable once two people were sitting together waiting for it, which triggered a chain of further waste-elimination.
→ Supports the proposition that pairing makes previously invisible costs visible, driving them to be fixed — illustrates the 'waste clock' mechanism.
Contrast between 2011-12, when one person flew down from Tromsø to personally decide every release, and today's five-minutes commit-to-production.
→ Dramatizes the magnitude of change from gated, centralized, big-batch releases to pairing-enabled continuous delivery.

Questions addressed

✅ What triggered this team's move away from pull requests?
Large pull requests and PR daisy-chains were disrupting flow; the tech lead instituted collaborative review instead of asynchronous back-and-forth.
✅ Does pairing conflict with being an introvert?
No — the guest reports that introversion does not mean antisocial, and the social/fun dimension of pairing became a genuine source of satisfaction, not just a productivity tool.
⭕ Does this approach generalize beyond a single four-person team, or hold up under a stricter external audit of the 'four eyes' compliance claim?

Gaps

incompleteThe account is entirely single-team, self-reported, and fixed at four developers; there is no discussion of whether the same dynamics (near-zero merge conflicts, direct onboarding into rotation, waste-clock visibility) hold at larger team sizes, across multiple teams sharing a codebase, or under distributed/remote-only conditions.
Read next: extract-on-pair-programming.json already raises pair-rotation frequency and distributed-pairing as open questions (g4, g5); this video adds a concrete single-team data point but doesn't resolve the scale question.
incompleteTreating the PR approval as 'pretty much a compliance thing' is asserted as sufficient, but the guest never describes an actual external auditor's reaction to this substitution — only that it satisfies the team's own internal sense of the requirement.
Read next: extract-four-eyes-without-pull-requests.json's own g1 names this same unresolved question (no empirical data on auditor response) for its more elaborate composite control — this video's informal version has the identical evidentiary gap.