How to Move Your Team to Graphite Without Breaking Review Habits

You adopt Graphite safely by piloting stacks with one squad for two weeks, leaving the merge queue off until the habit sticks, and only then enrolling the rest of the team. Teams that turn on every feature on day one usually abandon stacks within a month.

This is the team-level follow-up to Graphite. The CLI is easy; changing how fifty people open pull requests is the hard part.

Why do team Graphite rollouts fail?

Two reasons. First, mixed tooling. If half the team pushes with gt submit and half uses raw git push, the stack metadata goes stale and someone force-pushes over a branch.

Second, the merge queue. It is genuinely useful at scale, but turning it on during a workflow change means two new things break at once, and nobody can tell which one caused a bad merge.

What should the pilot squad do first?

Give one team of three to five engineers the CLI and nothing else. No dashboard, no merge queue. Their only job for two weeks is to create one stack per feature. Measure two things:

• Median time from first commit to merge.
• Number of stacks left open longer than three days.

If merge time drops and stale stacks stay rare, the workflow fits. If stale stacks pile up, the problem is process, not the tool, and a wider rollout will not fix it.

When should you enable the merge queue?

After the pilot, and only if your CI takes longer than about ten minutes. Below that, serialized merging is fast enough and the queue adds a step with little benefit. Above it, the queue pays off because it tests a batch of PRs together instead of one at a time.

Roll it out behind a flag on a single repo first. Watch for CI failures that only appear in the queue — batched runs surface flaky tests that individual PRs hide.

How do you handle trunk changes across many stacks?

Set one rule: everyone runs gt sync at the start of the day, before creating new branches. This keeps stacks close to trunk and avoids the multi-branch conflict cascade.

For repos with heavy trunk traffic, add a convention that stacks stay under five PRs. Long stacks magnify every rebase, and a five-layer stack left overnight is where teams get burned.

What changes in code review culture?

Reviewers stop ignoring the big PR — there is no big PR. The flip side is more pull requests to triage, so you need at least one reviewer who watches the stack and merges layers as they clear. Pick that person explicitly, or stacks rot at the top.

Quick Summary

• Pilot stacks with one squad for two weeks before a team-wide rollout.
• Require everyone to use gt submit; mixed tooling corrupts stack metadata.
• Enable the merge queue only if CI exceeds roughly ten minutes.
• Run gt sync daily and keep stacks under five PRs.
• Assign one reviewer to shepherd and merge each stack top-down.