Deploy frequency is a symptom, not a lever

Deploy frequency is a fine thermometer and a terrible steering wheel. Organizations that decide to "increase deployment frequency" directly tend to produce ceremonies: release trains renamed, deploy scripts run twice for the dashboard, a Friday deploy that ships nothing. The number moves. Nothing else does.

The number is downstream of queues. A change that takes three days from merge to production spent those days waiting somewhere: for a reviewer with the right context, for a test suite that runs forty minutes and gets rerun on flakes, for an environment three teams share, for the weekly window someone instituted after an incident in 2022. Deploys are the drips at the end of that pipe. Widening the tap does not move drips through a clogged pipe.

So when we read low deploy frequency in a diagnostic, we treat it as an invitation to walk upstream and time the waits. The pattern that repeats: each wait is individually reasonable, each has a historical justification, and no single person has ever seen the whole chain laid end to end. The laying-end-to-end is most of the value of measuring anything.

Treat the frequency number the way a clinician treats a fever reading. Worth writing down at every visit, meaningful in trend, and never the thing you treat. The tradeoff of the upstream walk is that it produces findings about process people are attached to, which is harder than buying a deploy tool. The reversal condition: if your deploys are rare because they are genuinely dangerous, fix the danger first; frequency built on fear collapses at the first bad week. For what the upstream walk looks like when it actually lands, a delivery overhaul read as a worked example traces the three decisions that moved the number, none of them a deploy tool.