Team composition when review is the constraint

Every rule of thumb about team composition came from a world where writing the code was the expensive part.

All of them.

Five to eight people, because that's the coordination limit on a group producing work.

A senior-to-junior ratio assuming juniors write a lot of code slowly and get better by doing it. Ownership boundaries drawn wide enough that a team could hold the context needed to build.

All of it sound. All of it downstream of one assumption that quietly stopped being true.

Then generation stopped being the constraint.

And the composition that was optimal for producing changes isn't the one that's optimal for absorbing them.

Sized for review capacity, not for work available

Stop sizing teams by how much work there is.

Always a weak instinct. Actively dangerous now, because available work is effectively unbounded once a team can generate a plausible attempt at anything before lunch.

Size instead for how much change the team can genuinely absorb: read, understand, take responsibility for, and be woken up about at three in the morning. That capacity is a property of the people and of the systems they hold in their heads, and it did not go up when the tooling arrived.

If anything it went down.

Reviewing four changes across three services you half know is harder than writing two in a service you know completely, because the load was never the diff itself, it's the context you have to rebuild before the diff means anything at all.

So the cognitive ceiling deciding team size drops, per person, as the ratio of reviewing to writing climbs.

Precisely backwards from how most capacity planning treats it.

Unfashionable consequence. Teams should probably own less surface than they did.

Same people. Narrower boundary. Deeper context, and more capacity to judge what's arriving.

Review comes off people before it goes on a rota

For twenty years, review was something you did in the gaps between your own work.

That survived because the volume was low enough for the gaps to hold it.

They don't hold now.

The obvious response is to allocate the time properly. Name who's on review this week, the way you'd name who's on interrupts, and take a real slice of their other work away. Right move if human reading is going to stay in the normal path, and it's where most teams start.

Usually the wrong place to stop.

Allocating human hours against a queue that machines fill is a race you lose on arithmetic. The thing filling the queue doesn't have hours. Whatever slice you carve out gets consumed, and then the argument becomes how much more of the week to hand over.

What holds is a machine first pass over everything, with human review reserved for escalation.

Not a person reading every diff on a schedule. A person reading the ones the first pass flagged, plus the ones whose blast radius earns a human regardless.

What that buys isn't saved time. It's judgment spent where judgment is the scarce input, rather than on confirming that four hundred generated lines do what the tests already proved.

Rotation still matters for the escalation half, for the same reason it always did: it stops review landing silently on whoever is most conscientious, which is otherwise exactly where it lands.

Then keep the one rule governing everything else about flow. Nobody starts new work while the review queue is red.

Already the cheapest WIP limit available. Now load-bearing, because the gap between how fast work starts and how fast it gets absorbed has never been wider.

Don't build a review team

The idea arrives within about two quarters, and it sounds efficient.

Specialists who are good at review, doing it full time, freeing everyone else to produce.

It's the QA department again. New badge.

Separating the writing of a change from the judging of it does the damage it always did.

Reviewers accumulate no context about why the work is happening. So they check mechanics, and miss the only question that matters.

Whether this is the right change at all.

Producing teams learn that quality belongs to somebody else's function. And the review team becomes a queue with a service level, which is the precise structure the rest of this track is trying to dismantle.

There's a worse version.

Review-team membership becomes a seniority tier, and the job is reading other people's output all day, forever. Miserable role. The people qualified for it have the most options of anyone in the building, and they will use them.

Keep review inside the team that owns the code. If capacity is short, the answer is a narrower boundary, better tooling, a machine first pass, or simply fewer things in flight at once.

Not a department.

What happens to the ratio

The tempting arithmetic: agents cover the junior work, so hire fewer juniors and more seniors, and the seniors review.

Tempting because the first half is arguably true. The second half is where it falls apart.

A team of only seniors, all reviewing, has nobody growing into the ability to review.

You've optimised for this year's constraint by removing your only supply of the thing that just became scarce.

Two years of that and you're bidding against every other company for the same small pool, at whatever price the market decided that scarcity is worth.

The junior question has its own lesson and I won't relitigate it here.

The org-design half is simpler. Whatever the ratio ends up being, you need people at every level doing enough real reviewing to build the judgment that makes review possible. Which means juniors reviewing too, on work sized to what they can hold, with somebody accountable above them.

Accountability is the part that can't be delegated to the pipeline, and it's worth being precise about what that means, because it isn't a signature. A human approving each merge is exactly the thing the pipeline can and should replace. What it can't replace is a named owner for the code once it's running: one team responsible for it, one leader accountable for it, and a person who gets paged when it breaks at three in the morning. Which quietly sets a floor on how small the senior population can get, and it's a floor most staffing plans haven't calculated.

Slack stops being optional

Utilisation was already the wrong thing to maximise and this makes the point harder to ignore.

Review is variable work.

A change arrives when it arrives, takes as long as it takes to understand, and the hard ones don't announce themselves.

A team booked to capacity has nowhere to absorb that variance, so it queues. And the queue now sits in front of your constraint rather than in front of a keyboard.

Sixty to seventy percent planned is the number I hold generally, and where review is the binding constraint I'd treat that as a floor rather than a target. It's an easier argument to make than it used to be, too, because the cost of getting it wrong now shows up in a queue metric inside about six weeks.

The check worth running

Take the last month.

Count changes merged per person, and hours of review those changes consumed. Roughly is fine. Then be honest about how many were read properly rather than approved because the queue was long.

Second number meaningfully bigger than the first? Your teams are no longer sized for what they do.

Not a failure of the tooling. Not a hiring problem yet either. It's a structure built for authorship, still being asked to run a system where authorship is the cheap part.