We shipped 40 releases last quarter. Here's what we learned about pacing.

Why pacing matters more than velocity

Forty releases in a quarter sounds like a brag. It isn’t. It’s roughly three a week, and for most of that period it felt less like speed and more like a treadmill we’d forgotten how to slow down.

The number itself was never the goal. What we were actually optimizing for was the gap between noticing a problem and having it fixed for customers, and that turns out to be a different metric with different failure modes.

What broke first

Around release twelve, our changelog stopped being readable. Individually every entry made sense. Collectively it read like noise, and customers told us so. Shipping frequently only helps if people can tell what changed and whether it affects them.

We fixed it by writing the changelog entry before the work started, not after. If we couldn’t explain the change in one sentence a customer would care about, that was a signal the change wasn’t shaped right yet.

The rule we landed on

Ship as often as you can explain. Not as often as you can deploy. Those are different limits, and the second one is much higher than the first — which is exactly the trap.

Eighteen months on we release slightly less often and hear about it considerably more. That trade has been worth making every single time.