5 Tips to Keep Code Review Meetings on Time

A code review call reaches minute 25 and the team is still on the same abstraction.

The author thinks the current design is fine because the next quarter may need the extension point. The reviewer thinks the abstraction is early and will make the current change harder to maintain. Someone has the PR open. Someone else is sharing a screen. The call has five minutes left, but the disagreement has no shape.

Live code review is expensive, so it should have a narrow job. A review call should resolve the blocking question or name the evidence that would resolve it, then return the rest of the work to the pull request.

Here are five ways to keep that call useful and on time.

1. Call only when the thread stops converging.

Do not turn a PR into a meeting because the diff is large or someone has opinions. Written review should stay the default for issues that can be explained clearly in text.

Microsoft's code review guidance recommends a quick talk when a few back-and-forth comments do not resolve a disagreement, followed by updating the PR with what was agreed and why: https://github.com/microsoft/code-with-engineering-playbook/blob/main/docs/code-reviews/process-guidance/reviewer-guidance.md.

That is the right trigger: the written thread has stopped changing minds.

A call is useful for:

• a design trade-off where both options are reasonable;
• a reviewer who lacks context that the author can explain faster live;
• a high-risk change where the decision needs shared confidence;
• mentoring or onboarding where the conversation is part of the learning.

A call is usually wasteful for:

• naming, formatting, and style issues;
• comments that need a clearer requested action;
• unrelated concerns outside the PR scope;
• reading the diff together from the first file.

The decision rule: schedule a call when the next written comment would repeat the same disagreement.

2. Pre-read the diff and bring the blocking point.

A live review should not become a group reading session. If people arrive without reading the PR, the meeting spends its best minutes building context that belonged before the call.

Code Review Meeting best-practices guidance makes this distinction clearly: a review meeting should clarify context and design so async review can continue, rather than review code line by line: https://bestpractice.unisbadri.com/en/pull_or_merge_request/code_review_meeting/.

Before the call, write the blocking point in one sentence:

• "Should this be a small explicit adapter or a generic integration layer?"
• "Is this cache invalidation safe enough for the current release?"
• "Do we accept this dependency now, or keep the local implementation?"

If there are more than two or three blocking points, the PR may be too large for one review call. Split the call by decision, split the PR, or move some comments back to async.

3. Mark each comment as blocking, optional, or evidence-needed.

Many review calls run long because nobody knows which comments are merge blockers.

Use three labels during the call:

• Blocking: must change or be explicitly accepted before merge.
• Optional: useful suggestion, not required for this PR.
• Evidence-needed: the team needs a test, benchmark, product requirement, or design note before deciding.

This keeps taste from wearing a blocker costume. It also gives the author a fair way to push back. If a comment is blocking, the reviewer should explain the risk. If it is optional, the author can choose. If evidence is needed, the call should stop debating and assign the evidence.

Practitioners argue about this constantly. In one r/ExperiencedDevs thread, a commenter wrote that useful review comments need both what should change and why; another warned that calls without written records disappear: https://www.reddit.com/r/ExperiencedDevs/comments/1p2eyqh/was_told_my_pr_comments_were_unclear/. Both points belong in the meeting.

The call should convert fuzzy disagreement into one of those labels.

4. Ask what evidence would change the decision.

When code review gets stuck, people often repeat preferences. The faster move is to ask what would decide the issue.

Examples:

• Performance concern: what benchmark result would make the approach acceptable?
• Architecture concern: what upcoming requirement requires the abstraction?
• Maintainability concern: what example shows the current version will be hard to change?
• Scope concern: what can ship now, and what should become a follow-up issue?

This question changes the meeting from persuasion to evidence. If nobody can name evidence that would change the decision, the team may be arguing taste, authority, or anxiety. The lead then needs to make a call or move the question to a broader design discussion.

Show KeyPress gives a useful review-call trigger: move the review to a call when the thread has stopped converging, then write decisions back into the PR because the call leaves no record and the review does: https://showkeypress.com/code-review-walkthrough-screen-share.

That record is the difference between a decision and a conversation people remember differently.

5. Write the disposition before leaving.

The last five minutes of a code review meeting should not introduce new comments. They should write the disposition.

Use this format in the PR:

• Decision:
• Required change:
• Optional follow-up:
• Evidence still needed:
• Owner:
• Review state:

Example:

• Decision: keep the explicit adapter for this PR.
• Required change: add the retry test the reviewer requested.
• Optional follow-up: open a design note for the generic integration layer if the second provider is scheduled.
• Evidence still needed: none for merge.
• Owner: author updates today.
• Review state: reviewer will re-check tests after push.

Minute Minder helps with this final step by making the Google Meet boundary visible from the calendar event. A custom reminder can fire near the end: "5 min left: write PR decision or evidence needed." Minute Minder does not record, transcribe, summarize, or inspect the code. It gives the facilitator a timing cue before the call loses the written record.

Google Meet's built-in timer can also be started manually by a host or co-host on the web, per Google Meet Help: https://support.google.com/meet/answer/16380429?hl=en-GB. For code review calls, the stronger habit is the custom reminder tied to the meeting's closure task.

Minute Minder can also draft a time-boxed agenda from the calendar invite, which helps if the invite says exactly which PR and which blocking comments are in scope. Minute Minder stays out of the code decision. The team still owns the technical judgment.

When live review is the team's default.

Some teams do live review by design. A small team may pair-review every change. A classroom or mentoring group may use live review for learning. A safety-critical team may require synchronous discussion for certain changes.

That can work if the record still lands in the PR. The risky version is the undocumented call where a decision happens in Google Meet, then the PR thread shows only a vague "discussed live."

If the call is worth having, the conclusion is worth writing. Otherwise the team has created a second review system that future maintainers cannot search.

A code review meeting should end with the PR more resolved than it was before. That may mean the author changes code. It may mean the reviewer accepts the trade-off. It may mean the team names the missing evidence. Any of those outcomes is useful if it is written down before the meeting ends.

Sources

• Microsoft code review guidance: https://github.com/microsoft/code-with-engineering-playbook/blob/main/docs/code-reviews/process-guidance/reviewer-guidance.md
• Code Review Meeting best practices: https://bestpractice.unisbadri.com/en/pull_or_merge_request/code_review_meeting/
• Show KeyPress, code review walkthrough: https://showkeypress.com/code-review-walkthrough-screen-share
• Google Meet Help, timer: https://support.google.com/meet/answer/16380429?hl=en-GB

FAQ

When should a code review move to a meeting?

Move a code review to a meeting when the written thread has stopped converging and the next comment would repeat the same disagreement. Keep routine comments in the PR.

How long should a code review meeting be?

For most PR disagreements, 15 to 30 minutes is enough if the diff was pre-read and the call has only two or three blocking points. Longer calls often mean the PR or decision scope is too large.

What should be documented after a code review call?

Write the decision, required change, optional follow-up, evidence still needed, owner, and review state back into the PR. The call should not replace the review record.

Can Minute Minder help with code review meetings?

Yes. Minute Minder can show the calendar-based Google Meet timer and display a custom reminder such as "5 min left: write PR decision or evidence needed."