How to run code review on a remote team
Code review on a remote team is mostly waiting. A pull request goes up, the author pings someone, the reviewer is in another time zone, and the change sits for a day before anybody reads it.
Make the request visible, make the ask specific, and give the hard reviews a place to talk. Post every review request in one channel, say what kind of review you need, reply the same working day, and take anything that needs a conversation into a walk-in voice room beside the channel.
The usual way
Remote code review often looks like this.
- The DM ping. "Can you look at my PR?" One person saw it. If they are busy, nobody else knows it is waiting.
- The vague ask. The request says "review please". The reviewer cannot tell if it needs a quick look or a careful read, so it waits for a free afternoon.
- The comment ping-pong. Twelve review comments go back and forth over three days on a question two people could settle in five minutes of talking.
- The lost decision. The reason a design changed is buried in a resolved comment nobody will open again.
A format for a distributed team
1. Post every review request in one channel
Pick one channel per team for review requests. Every pull request that needs a reviewer gets one message there, same shape every time.
- Link: the pull request.
- What it does: one sentence.
- What I need: a quick look, a careful read of the migration, or a second opinion on the approach.
- By when: today, this week, or no rush.
A request in the channel is a request the whole team can see, pick up, and answer. If the named reviewer is out, someone else can take it.
2. Name the kind of review you want
"What I need" is the most useful line in the request. It tells the reviewer how long to block out and where to look.
- Quick look. Small change, low risk. Read it, approve it, move on.
- Careful read. Name the part that needs it: the migration, the permissions check, the public API.
- Approach check. Before the code is finished, ask whether the direction is right. Cheaper to change now.
3. Reply the same working day
Agree on one rule: a review request gets a reply within the reviewer's working day. The reply can be the review, or it can be "I'll get to this tomorrow morning". Either way the author knows where it stands.
When the reviewer picks it up, they react or reply in the thread so two people do not read the same change.
4. Talk through the hard ones in an open voice room
When a review turns into a back-and-forth, stop typing. Use a walk-in voice room beside the review channel instead of booking a call.
The author and reviewer walk in, settle the question, and walk out. Anyone else with context can walk in too. Then one of them writes the outcome on the pull request and in the thread, so the decision is on record where the code is.
5. Close the thread
When the pull request merges, the author replies "merged" in the request thread. The channel then reads as a list of what is open and what is done.
Make it repeatable
- Pin the request format. New teammates copy it from the pin.
- Keep it out of DMs. When DMs hide the decision covers why.
- Pair on the big ones. For a change that is easier to build together, see How to pair program with a remote team.
- Record design calls. If a review settles a design question, add it to the team's decision log.
How Bullpen fits
Bullpen is team chat with walk-in voice rooms and AI helpers on the roster. A code review can live in one thread in one channel, from the request to "merged".
Requests live in the channel. Every review request sits in the same place, so what is waiting is one scroll.
The hard conversations happen in the channel's walk-in voice room. It stays open beside the channel. People walk in to settle a review question and leave when it is done.
Wren writes the notes. Wren is an AI helper. In that walk-in voice room, Wren posts notes and action items back to the channel the room belongs to, so what was agreed out loud lands next to the request.
Scout finds the earlier decision. Scout is an AI helper on the same roster. Mention Scout and ask why the team chose that approach last month. Scout answers from what was said and links the message it came from.
Nix keeps "by when" honest. When a request says "by Thursday", mention Nix in the thread and the reminder arrives in the channel on the day. How to keep track of follow-ups in team chat covers the details.
Try it on your next pull request
Post your next review request in the team channel with the four lines above, and fill in "What I need".