The deploy nobody wants to press

When deploys move from weekly to monthly, the story is rarely 'we got careful.' It is usually that nobody trusts the button, and the team has stopped learning in production.

Release fear is measurable. Lead time, change failure rate, and time to recover tell you whether the problem is process theatre or missing instrumentation.

Treat fear as a metric, not a mood

We start by writing down the last five releases: who pressed deploy, what broke, how long recovery took, and whether anyone would press it again without a war room.

1. 01
   Deploy frequency and batch sizeLarge batches hide risk. If every release is a festival, you cannot tell which change caused the outage.
2. 02
   Change failure rateNot every incident is a deploy failure — but if most incidents trail a release, the pipeline is lying about readiness.
3. 03
   Time to recoverRollback paths, feature flags, and on-call ownership matter more than another staging environment.

What we instrument first

Release fear is a measurable problem. What we instrument first when a team has stopped shipping weekly.

A deploy button people avoid is a product defect in the delivery system.

First wins that restore cadence

Feature flags on the riskiest paths, a one-command rollback, and a smoke suite that actually runs on every candidate build. Cadence returns before architecture rewrites finish.

A short test

Ask the newest engineer on the team to deploy a one-line config change on a Thursday afternoon. If the answer is 'not without three people,' you have your first backlog item.