The Case for Slower Deploys

After a year of shipping twice a day, our team burned out. Slowing to one deploy per week didn't hurt velocity — it fixed our architecture.

I spent most of Q3 2024 staring at an incident console at three in the morning. The pipeline was green. The rollout was canaried. We ran deploy --canary --wait=300 and closed our laptops. By 03:14, the alerts started. A schema migration had landed in the wrong order across four services, and nobody on the on-call rotation understood why.

Velocity is not throughput

Our team shipped 47 deploys in September. Only 12 of them contained changes users noticed. The rest were hotfixes for the hotfixes, config toggles we had forgotten to remove, and rollbacks that burned an entire morning before anyone could write new code. We were moving fast in the narrow sense that CI said so. In every sense that mattered — reliability, team health, architectural clarity — we were dripping debt into the repo at a rate nobody dared measure.

$ The pipeline was green. The rollout was canaried. But something always broke at three in the morning — and the on-call rotation never had enough context to fix it.

In November we capped deploys at one per week. The first month was uncomfortable — product managers kept ops-channel threads titled "why can't we just." By January, the architecture had started to breathe. Services that had been coupled through deployment-ordering hacks got real API contracts. The test suite grew teeth. And the incident console went quiet for the first time in six months.