Mob review for high-stakes changes

Single-reviewer async code review handles 90% of changes well. The other 10% — high-stakes changes that touch authentication, payments, schema migrations, or core architectural seams — need more eyes and more bandwidth than async can provide. Mob review is the structured format that answers that need without becoming an open-ended meeting.

A mob review is a synchronous 30-60 minute session where 3-5 engineers walk through a PR together, with the author driving (screen-sharing) and the others contributing questions, suggestions, and challenges in real time. The output is either a merged PR (with the mob's collective approval) or a clear list of work the author will do before the next mob session.

When to mob

The decision rule is structural, not personal. The PR earns a mob session when at least one of the following is true:

• Auth or authorisation surface change. Anything that adjusts who can see or do what. Cost of a missed defect is high (data exposure, privilege escalation); failure modes are often non-obvious from the diff.
• Database schema migration. Especially anything that's not additive — column drops, renames, type changes, foreign-key alterations. The cost of a missed defect is data loss or production lockup.
• Payment or financial calculation logic. Direct revenue/customer impact; regulatory exposure; the kind of bug that becomes a postmortem.
• Public API contract change. Breaking changes, new endpoints, new required fields. The reviewer's mistake propagates to every consumer.
• Core algorithm or data-structure change in a hot path. Performance regressions in critical paths can be hard to detect in CI but devastating in production.
• Change to a file with >5 historical incidents linked. Some files are bug factories; team-specific historical data is the best signal.

Teams with these triggers explicit see roughly 1-3 mob sessions per week. Teams without explicit triggers tend to under-mob (skipping high-stakes changes because nobody initiated it) or over-mob (mobbing every PR because the team is risk-averse). Both extremes waste collective time.

The session format

A well-run mob session has six phases. The total time should be 30-45 minutes for most PRs; 60 minutes is the cap. Anything that needs more belongs in a design review followed by a normal async PR.

Phase 1: Context (5 minutes)

Author presents the change at a high level: what it does, why it's being made, what the constraints were, what alternatives were considered and rejected. This isn't reading the PR description aloud — it's the context that lives in the author's head and didn't make it into writing.

The mob asks clarifying questions only; no design challenges yet. The goal is shared understanding of the problem space.

Phase 2: Walkthrough (15-20 minutes)

Author drives, screen-sharing the diff. They go file-by-file (or logical-grouping by logical-grouping), explaining what each section does. The mob follows along.

The walkthrough should be at a pace where mob members can absorb without re-reading. If the author is going too fast (mob members ask "wait, what does that do?"), slow down. If too slow (mob members start checking Slack), the change is probably too large for a mob session — split it first.

Phase 3: Open questions (10-15 minutes)

The mob raises questions, concerns, and alternative approaches. The author engages with each. The discipline is to surface every concern, even ones the asker isn't sure about — "I'm not certain this is a problem but..." is exactly the right opener.

Common categories of mob-raised concerns:

• Boundary conditions the test suite missed
• Failure-mode handling that's silent or absent
• Concurrency that could deadlock or race
• Backward compatibility for in-flight clients
• Migration rollback path if the change goes wrong in production
• Observability — will we know in production if this breaks?

The phase ends when the mob runs out of substantive concerns, or when the time-box hits.

Phase 4: Decision (5 minutes)

The author and mob jointly decide:

• Approve and merge as-is: rare for a session that found real concerns
• Approve with follow-up commits the author owns: most common; mob is comfortable with the direction, has confidence the follow-ups will happen
• Request changes, schedule re-mob: needed when concerns are substantial enough that the next version warrants another collective look
• Reject, send back to design: rare but valid when the mob surfaces fundamental issues that need design-level rework

The decision is explicit and recorded in the PR.

Phase 5: Record the decisions

The author posts a comment on the PR summarising the session: who attended, decisions made, follow-ups owned. This becomes the audit trail when the change is referenced later — by the author, by an incident postmortem, by a new engineer trying to understand the rationale.

Phase 6: Async follow-through

The author works the follow-ups. Other mob members are not on the hook to re-review unless explicitly assigned in the session record — the mob session was the review, not the prelude to it.

What mob review is NOT

Mob review is not pair programming with extra people. The author has already written the code; the mob is reviewing it, not writing it. The synchronous element is for collective review, not collective authoring.

Mob review is not a design meeting. If the session devolves into "should we even be doing this?", the change is too early — back to design. Mob review assumes the design is settled and the implementation is the subject.

Mob review is not consensus voting. The session produces an approve/changes/reject decision; the mob doesn't need unanimity. Strong dissent from one mob member is information the author and primary reviewer weight, not a veto. Treating mob review as voting produces watered-down decisions and resentful dissenters.

Mobbing across timezones

The hardest version of mob review is across timezones. The practical compromises:

• Async-mob hybrid: the author records a 15-minute walkthrough video; mob members watch async, comment in the PR; a 30-minute synchronous follow-up resolves the substantive discussion.
• Regional mobs: changes that affect a regional team's surface get mobbed within that region's timezone; the global team is informed via the PR record.
• Scheduled mob windows: the team designates 1-2 windows per week (e.g. Tuesday 9am UTC, Thursday 5pm UTC) where mob sessions can be scheduled. Authors who need a mob plan to one of those windows.

Each compromise has costs; the right choice depends on how often the team needs to mob and how distributed they are.

Frequency and norms

Healthy mob discipline shows three patterns:

• Mobs happen on a regular cadence — typically 1-3 per week for a 6-12 person team. Less than weekly suggests under-mobbing; more than 5/week suggests the team is mobbing PRs that don't warrant it.
• Mob attendance is roughly balanced across the team. Specific engineers carrying the mob load is a sign of unhealthy dependency on a few seniors.
• Mob sessions produce decisions, not endless discussion. The 60-minute cap should bite occasionally; it should never be habitually overrun. Overrun is a signal the session was poorly scoped.

When mob review replaces a security review

For changes in the auth/payment/data-integrity category, a well-run mob session often replaces what would otherwise be a formal security review. The trade-off:

• Mob is faster (45 minutes vs days of back-and-forth with a security team)
• Mob has more product context (the team building the feature understands it better than an external reviewer)
• Security team is freed for the changes that genuinely need their depth (cryptography, novel auth flows, compliance-critical paths)

The discipline is rigour: a mob that approves a security-sensitive change without surfacing the boundary conditions, failure modes, and observability gaps has missed the point. Healthy teams calibrate over time by tracking whether mob-approved security changes produce postmortem-worthy escapes.

Common failure modes

Three patterns to watch for:

• The author-defends-everything mob. Mob raises concerns; author has a counter for each; no concerns get addressed. The author's job is to take concerns seriously, not to win the debate. Fix: explicit norm that the author thanks the mob for concerns and writes them down for triage, even if they ultimately disagree.
• The senior-monologue mob. One senior engineer dominates while everyone else stays quiet. The mob's collective insight is wasted. Fix: rotate mob facilitation; facilitator explicitly invites quieter members.
• The mob-as-rubber-stamp. Mob session happens but the mob nods along. Decisions surface that should have surfaced in the session don't. Fix: track post-merge concerns linked to mob-reviewed PRs; if rate is high, the sessions aren't working.

The Stride pattern

At Stride, mob review is the explicit format for: any change to billing-mode logic, any change to authentication or session handling, any database migration that's not purely additive, and any change to the canonical content data modules (where a bug propagates to every consumer). The cadence is roughly 2 mobs per week; the median session length is 40 minutes.

Sessions are scheduled in the team's #engineering Slack channel with a calendar invite; the PR title is prefixed mob: to make the queue visible. Notes are pasted into the PR as the session's first comment.

Related reading

For the cadence-and-latency picture, see Async code review without 24-hour latency. For the SLO targets that frame review effort overall, see Service-level objectives for code review. For the question set the mob actually walks, see Review checklists that catch bugs.