What to do instead
Make code review a pairing device
Review already happens. Deciding who reviews whom, and rotating it, converts an existing process into the cheapest pair-making mechanism available.
The people this page is about, and which of them have ever worked together
- 01The senior engineerThe pair that came out of a shared on-call week
- 02The second engineer
- 03The designer
- 04The data analyst
- 05The product manager
five people · 10 possible pairs · 1 of them has worked on something together · 3 have only been in the same meeting · 6 have never done either
Five of the eight, with the manager left out so that what remains is what the team has without them.
When a team wants evidence without reducing people to a score, managers can read the practical guide and connect time and project patterns to a transparent discussion about workload.
The broader organisational question can also be checked against resources from Oxford Saïd.
Most teams already review each other's work. What almost no team does is decide who reviews whom, and that single decision converts a process that is already running into the most reliable pair-maker in this part of the site.
The default is self-selection: the author picks a reviewer, or the request goes to a channel and whoever is free takes it. Both reproduce the existing grid exactly. People ask the person they already work with, because that person will understand it fastest, and the review strengthens the pairs that needed it least.
Why a review is such a good pair
It has every property the core intervention asks for, and it already exists.
It is genuinely two-person work. Somebody made a thing and somebody else has to understand it well enough to have an opinion.
It has stakes. The reviewer's judgement affects the output, which means the exchange is informative about how both of them think.
It is small and bounded. An hour at most, and there is no planning overhead.
It recurs on its own schedule without anybody arranging anything.
And it transfers the thing that matters most: after reviewing somebody three times you know how they work, what they are careless about, what they are rigorous about, and what it costs to disagree with them.
The change
Write a rota. Each person reviews one named colleague's work for a fortnight, then rotates.
Use the grid to set the order. Start by pairing people who have never worked together, and specifically avoid pairing people who already do. The rota is where the deliberate part of deliberate pairing lives.
Keep the author's right to ask for a second reviewer when something is genuinely outside the rota partner's area. The rota is a default, not a rule, and making it a rule produces bad reviews and resentment within a month.
The predictable objection
Somebody will say that a reviewer who does not know the area gives a worse review. This is true for the first fortnight and false after that, and it is worth answering properly rather than dismissing.
A reviewer unfamiliar with an area catches a different class of thing: unstated assumptions, missing context, names that only make sense if you were there. Those are exactly the defects an expert reviewer reads straight past.
The fortnight of slower reviews is the cost. What it buys is a second person who understands that area, which is the thing the team did not have and the reason the review was fast before.
Beyond code
Nothing here is specific to engineering, and the same rota works for anything with a reviewable output: a document, a design, a dataset, a plan, a customer response. The mechanism is the same — somebody made something, somebody else has to understand it — and the default failure is the same, which is that people send work to whoever will approve it fastest.
The version for teams whose work does not produce artefacts is the duty rota: a shared on-call week, a rotating release, a support shift covered by two people. The handover at the end of the cycle is the exchange, and it is the mechanism that produced the one non-manager pair on the team counted throughout this site.
What to watch
Two failure modes, both visible within a month.
- The rubber stamp. If reviews come back approved in four minutes with no comment, the rota is producing a formality rather than an exchange and nothing is being transferred. The cause is usually workload, not indifference.
- The bottleneck. One person's work is hard to review and the rota keeps assigning it to people who cannot. That is a finding about the work rather than about the rota, and it is worth acting on separately.
Setting the rotation from the grid
The order is where the deliberate part lives, and it takes ten minutes to set for a quarter.
Write out the pairs that do not exist, in order of how cheap they are to make: near-misses first, then anybody with an empty row, then the rest. Then build the fortnightly rota so that it walks down that list. Six rotations in a quarter on a team of eight covers six pairs, which is more deliberate pairing than any other mechanism here delivers for the effort.
What you are avoiding is the alphabetical rota, or the one generated at random, both of which will pair people who already work together roughly as often as chance allows and waste a quarter of the slots.
The reason to start here
Of everything in this part of the site, the review rota is the one with the lowest cost and the shortest path to a result. The process exists, the time is already being spent, and the only change is who it is spent with. Four weeks of a rota on a team of eight produces more new pairs than an offsite, for nothing.