Three practices on my team exist because I started them, and none of them was my job. This post is about how a code-review queue turns into a view of what a team needs, and which changes survive when nobody is required to keep them.

the vantage point

I carry one of the highest code-review volumes on the team. That is not a boast, it is the mechanism. The review queue is where a team’s needs become visible before anyone names them. You see the same class of bug arrive from three people, the same question asked in three pull requests, the same feature stuck for a week waiting on a stage that adds nothing. Nobody assigns you to fix any of that. You either treat the team as part of the job or you approve the pull request and move on.

Three things were visible from that seat. Engineers were moving from front-end work into the back end without much support. A QA handoff stage slowed every release by the length of the queue. There was no regular place where the team said how the team itself was doing.

pair programming, as the default

Pairing existed as an exception: when something was hard enough, two people would sit on it. The change was making it the norm for anything nontrivial, so the question became “who are you pairing with” rather than “should we pair”.

For the engineers crossing from front-end into back-end work, this was the mentoring mechanism. A first backend service written alone takes a week and teaches the framework. Written in a pair with someone who has done ten, it takes two days and teaches the judgment: where the transaction boundary goes, what the resolver should not do, which query will be the slow one. The pair is the review, done before the code exists rather than after.

engineers test their own work

The handoff stage was a separate QA pass after the engineer said a change was done. It found real bugs. It also added a queue, and the queue meant a fix waited days for a check that took minutes, and the engineer who wrote the change had moved on to something else by the time the result came back.

Engineer-run QA moves that check upstream. The engineer who made the change tests it before calling it done, on a real environment, against the cases the change was for and the cases next to them. Quality did not drop. The wait disappeared, and the person best placed to know what a change could break was the one checking it.

The honest version of this: it only works if “done” means “tested”, and a team has to hold that line on itself. The review queue is where you see whether it holds.

a recurring health check

A short, recurring item in the team’s ceremonies where the team says how the team is doing. Friction, load, unclear ownership, the thing everyone is working around. Ten minutes on a regular cadence.

The alternative is that friction surfaces in an exit interview, or in a one-on-one where it becomes one person’s complaint rather than a shared fact. A standing agenda item makes it routine to say, and routine to fix.

the falsifiable part

Practices introduced by one person usually leave with that person. The claim here is that all three survived my direct involvement: I moved to other work, and the team kept pairing by default, kept testing its own changes, kept the health check. That is checkable by asking anyone on the team, which is the only kind of leadership claim worth making.

Practices that survive their author are the ones that fit. The ones that do not fit go quietly, and that is fine too. The review queue shows you what is needed. It does not tell you what will stick, and the only way to find out is to start it and step back.