What if our CI is already slow? Won’t more checks make it worse?

Scope your checks. Run lint/type/fast tests on PRs; push heavy integration tests to a nightly or a pre-merge “train build.” Use concurrency groups to cancel redundant builds and shard tests. Faster signal beats bigger signal.

How do we handle multiple time zones without blocking on reviews?

Publish review SLAs that are local-time friendly, rotate reviewers across zones, and use CODEOWNERS to ensure at least one approver is available. For critical paths, adopt a follow-the-sun release train with clear handoffs.

We’re stuck on Bitbucket/GitLab. Do these patterns translate?

Yes. Required checks, code owners, pipeline stages, and policy-as-code exist across platforms. We’ve implemented equivalent gates with GitLab CI (`rules`, `needs`, `manual`) and Bitbucket Pipelines with branch permissions.

How do we keep ADRs from becoming shelfware?

Keep them short (one page), make a template, and require a link from PR descriptions when code implements an ADR. Review ADRs in weekly PR office hours; close stale ones aggressively.

How do we stop large PRs when product pushes big features?

Negotiate scope. Slice by capability flags or API endpoints. Use release trains so partial work ships safely behind flags. When a large PR is unavoidable (schema rewrites), schedule explicit reviewer time and hotwash afterward.

Culture · Oct 14, 2025 · 10 minute read

Remote-First Without the Broken Builds: Rituals, Metrics, and Leadership That Keep Code Clean

What actually keeps code quality high when your engineers rarely share a room: tight rituals, boring leadership, ruthless metrics, and CI that refuses to look away.

Back to all posts

Remote-First Without the Broken Builds: Rituals, Metrics, and Leadership That Keep Code Clean

Key takeaways

Implementation checklist