Engineering Velocity Improvements Without Scoring: Playbook

Stop review idle time: working agreements and merge queues

Treat review idle time as a workflow queue, then give that queue an owner. Rotate a reviewer role, and make that person clear PRs marked ready for review before starting fresh feature work. Treat fast feedback as a delivery capability, not a vanity metric (source: Accelerate (Forsgren/Humble/Kim, 2018)).

::callout{type="tip"} Working agreement: authors keep PRs in draft until basic CI passes; auto-assignment requests the right CODEOWNERS; the rotating reviewer starts with PRs marked ready for review. ::

Enable CODEOWNERS and auto-assignment so the first review request goes to the team that owns the touched paths. This removes the manual “who can review this?” hop from every PR.

Use a merge queue on busy protected branches. GitHub’s merge queue validates queued pull requests against the latest target branch and earlier queued changes before merge, which reduces broken-main risk when many PRs land close together (source: GitHub Docs — Merge queue (consulted 2026-05)).

Gate “ready for review” on basic CI: compile, lint, unit tests, and ownership checks. A reviewer should spend attention on design, correctness, and operability, not on failures a machine already detected.

Keep PRs single-purpose. Split mechanical refactors, schema changes, and behavior changes when they can be reviewed independently. Aim for shorter review and integration time, not a leaderboard of PR counts.

Make CI give answers sooner, not later

::steps :::step{title="Fail fast before expensive stages"} Run lint, type checks, and unit tests before integration jobs. Gate slower stages behind those results, so a syntax error or broken mock fails before databases, browsers, or deployed test environments start. :::

:::step{title="Cache dependencies and build outputs by real inputs"} Cache package-manager directories and build artifacts. Key each cache from lockfiles, compiler config, and relevant source paths, so CI reuses work until those inputs change (source: GitHub Actions Docs — Caching (consulted 2026-05)). :::

:::step{title="Keep PR test feedback tight"} Shard long test suites across parallel jobs when the runner supports it. For monorepos, run affected tests from the changed package graph when dependency mapping is reliable enough to avoid missed coverage. :::

:::step{title="Quarantine flakes without hiding them"} Move flaky tests behind an explicit quarantine flag, exclude them from the merge gate, and report them in a separate job. CI should preserve actionable signals; noisy checks train teams to ignore failures (source: Google Site Reliability Workbook (2019)). :::

:::step{title="Push green status where reviewers already are"} Show required CI status directly in the pull request, and post build recovery in the team chat channel used for reviews. Reviewers should return when the build turns green, not after another manual refresh. ::: ::

Shrink batch risk: trunk-based flow with flags, safely

Keep branches short-lived: merge small slices to trunk as soon as review and CI pass. Frequent integration reduces merge drift and rework because conflicts surface while context is fresh (source: Accelerate (Forsgren/Humble/Kim, 2018)).

::comparison-table

headers:

• 'Default'
• 'Operational rule' rows:
• ['Short-lived branches', 'Start from trunk, merge back after review and green CI; do not park integration work in personal branches.']
• ['Flags', 'Put unfinished behavior behind a flag that defaults off in shared environments.']
• ['Preview environments', 'Create an ephemeral environment for user-facing pull requests before merge.']
• ['Flag retirement', 'Assign an owner and expiry condition when the flag is created.']

---

::

Treat flags as release controls

Use feature flags to decouple deploy from release: ship code to trunk, progressively enable it, then roll back by turning the flag off immediately when behavior is wrong (source: LaunchDarkly Docs — Feature flag best practices (consulted 2026-05)).

Default unfinished code to off in every shared environment. Run CI against the default path and the guarded path for changed areas, so merged code does not break only after the flag flips.

Every flag needs an owner and an expiry condition: ticket closed, rollout complete, or experiment ended. Remove stale flags with the code path they guarded to limit long-term complexity.

Preview user-facing changes before merge

For user-facing changes, create ephemeral preview environments from the pull request. Product, design, or support can validate copy, routing, permissions, and error states before merge.

A weekly, no-metric cadence to fix your biggest constraint

Pull event timestamps from Git and CI: PR opened, first review submitted, approvals recorded, first passing CI run, and merge time. Plot time-in-state by workflow state, not by author.

::steps :::step{title="Pick the constraint"} In the weekly session, sort states by total waiting time. Choose the single longest state and write one default change to test before the next session. :::

:::step{title="Change defaults, not effort"} Do not ask engineers to chase stuck PRs manually. Enable a merge queue, auto-assign reviewers, or cancel redundant CI runs so the system removes avoidable waiting. :::

:::step{title="Replay the same view"} Recreate the same simple chart next week with the same Git and CI events. If the longest state improved, keep the change. If it did not, roll it back and try the next lever. ::: ::

::callout{type="tip"} Keep names out of the chart. A blameless, system-focused loop reduces gaming, avoids politics, and keeps the discussion on defaults the team can change. ::

Copy‑paste defaults for GitHub/GitLab to move faster today

::card-grid :::feature-card{title="Default repository policy"} Set CODEOWNERS to the smallest reliable owner set per path: one team for /api, one team for /web, and no catch-all owner unless that group actively triages PRs. ::: ::

Protect main in GitHub branch rules or GitLab protected branches. Require only checks that finish quickly enough for review flow; move slower, non-blocking checks to post-merge.

For protected branches, use the same required statuses in the merge queue, then block direct pushes to main (source: GitHub Docs — Merge queue (consulted 2026-05)).

Auto-cancel in-progress CI when a contributor pushes a newer commit to the same PR. Limit branch concurrency so stale commits stop occupying runners.

Use labels as the PR state machine: ready-for-review means reviewers may start, awaiting-author means reviewers stop, and needs-qa means validation is needed before merge.

::cta{title="Paste into your repo README" link="#copy-paste-defaults-for-githubgitlab-to-move-faster-today"} Required before merge: path owner approval, fast required checks, merge queue, no direct pushes to main, auto-cancelled stale CI, and an explicit PR state label. ::