A design platform in the mould of Canva moves 90 engineers off long-lived feature branches onto trunk-based development with a merge queue. Six weeks later the mean branch still lives four days and the trunk is no healthier. Review this change. What did they actually need to change?

What is actually required

Short branch lifetime is the goal; the branching model is one of four things that set it. Decompose the four days:

time writing the change + time waiting for a first review + time in review rounds + time in the merge queue. Trunk-based development and a merge queue address the last term only. If the median wait for a first review is 9 hours and a 1,400-line change takes three rounds, the floor is close to three days whatever the branch is called.

So the diagnosis is a mismatch: the team changed the release shape when the binding constraint was the review shape. Nothing in the policy made changes smaller or reviews faster, so nothing moved.

What I would remove, and why it is safe to

Remove the rule that every change needs two approvals from a named group of four senior engineers. Four reviewers serving 90 engineers is a queue with a hard service rate, and it sets the wait regardless of branch policy. Replace it with one approval from anyone in the owning team plus a required second approval only for changes touching a declared sensitive path.

Remove any requirement that a branch be rebased and re-green before each review round. It converts reviewer latency into author latency and doubles the round trip.

The one change that matters

Make the reviewable unit small by making changes stackable. A feature becomes a chain of dependent changes, each a few hundred lines, each mergeable on its own behind a flag. Each link's lifetime is hours because each link is small enough to review in one sitting, and review guidance converges on roughly 200 to 400 lines as the point beyond which reviewers stop finding defects and start approving.

This costs real tooling: a stack needs an automated restack when a lower link merges, and reviewers need to see each link's own diff rather than the cumulative one. Without that, stacking is manual rebasing and engineers abandon it inside a month.

What I would leave alone

The merge queue. It is doing its job, and testing each change against the state that will exist after merge is the only thing that prevents concurrent merges breaking trunk.

Also leave any long-lived maintenance branch that exists because customers run old versions. That is not a discipline failure; it is a product commitment.

How I would argue this in the review

With a measurement, not a principle. Instrument four weeks of time to first review and the distribution of changed lines per change, then show that the model change could not have moved either. A policy argument against a branching model loses; a histogram showing 60% of elapsed time is reviewer wait wins, because it names a queue someone owns.

When this is the wrong answer

If branches genuinely live for weeks because they hold whole features behind no flag, the model change is the first move and review latency is second. Measure before deciding which. The error here was not the policy, it was shipping it without the measurement that would have ranked it.