What if our legacy repo makes small PRs impossible?

Start by carving seams: introduce module boundaries and file-by-file lints so changes can be isolated. Enforce small PRs in greenfield areas first, then refactor on a scheduled debt budget. We’ve split monoliths by adding adapter layers and stranglers before enforcing PR limits across the board.

We’re in multiple time zones. How do we hit 24h review SLAs?

Rotate PR Sheriffs across regions and use follow-the-sun handoffs. Automate Slack pings on aged PRs and set expectations that reviews top the queue after standup. A single overlap hour per region is usually enough.

Won’t two approvals slow us down?

Not if PRs are small. In our data, teams with small PRs and two approvals ship more frequently than one-approval teams with large PRs because review confidence is higher and rollbacks are rarer.

Can we do this on GitLab or Bitbucket?

Yes. Swap GitHub Actions with GitLab CI/CD or Bitbucket Pipelines, use their code owners/merge request approvals, and equivalent linters/review bots. The principles—small changes, enforced guardrails, clear SLAs—are tool-agnostic.

Culture · Oct 13, 2025 · 10 minute read

Remote-First Without Rotten PRs: Rituals, Leadership, and Metrics That Keep Code Clean

What actually works to keep code quality high when your engineers aren’t in the same building—complete with guardrails, playbooks, and hard metrics.

Drew Halvorsen

Principal Engineer, GitPlumbers

20 years across fintech and retail. Led platform teams at a Fortune 100 through remote transition, cut CFR in half. Ex-ThoughtWorks, ex-Stripe ecosystem partner. Opinionated about small PRs and big coffees.

In remote orgs, code review is your hallway. If the hallway is blocked, everything smells.

Back to all posts

Remote-First Without Rotten PRs: Rituals, Leadership, and Metrics That Keep Code Clean

Key takeaways

Implementation checklist