Skip to content
BinaryScaler

Delivery

The release manager is a symptom

If deploying needs a coordinator, the problem is not coordination. Here is what we change first, and why the change advisory board usually survives it.

Written by
Dana Whitfield · Principal Engineer
Published
2 May 2026
Reading time
6 minutes

A release manager exists because deploying is risky. The role does not reduce the risk; it concentrates the coordination cost in one person so that everyone else can ignore it. That is a rational response to a real problem, and it is also a signal about what needs fixing.

The three things that make deploys risky

  1. Batch size. A release containing forty changes has forty suspects when something breaks.
  2. Irreversibility. If rollback means a database restore, nobody will authorise it under pressure.
  3. Invisibility. If you cannot see failure within minutes, you cannot respond within minutes.

Every one of those is technical. None is solved by a person with a spreadsheet, though a person with a spreadsheet can hold the situation together for years — which is precisely why the underlying problems persist.

Reversibility first

We start with rollback rather than batch size, because reversibility is what makes small batches safe to attempt. Feature flags decouple deployment from release: the code goes out dark, and turning it on is a configuration change with an instant undo.

Schema changes need the same treatment: expand, migrate, contract. Add the new column, write to both, backfill, switch reads, and only then drop the old one. Each step is individually reversible, which is what makes the sequence safe.

Then make the batches small

Once rollback is genuinely one click, deploying ten times a day becomes less frightening than deploying once a fortnight. Each deploy carries one change, so when a metric moves, the cause is unambiguous.

The change advisory board does not have to go

In regulated environments this is where the objection lands. It rarely holds. The board's legitimate interest is that changes are reviewed, evidenced and reversible — all of which a well-instrumented pipeline demonstrates better than a fortnightly meeting.

We have taken this approach through financial-services change control several times. The board stays; what changes is that its evidence is generated automatically, and its approval gates the flag rather than the deploy.

Deployment frequency

Typical after two quarters

Lower change failure rate

Smaller batches, faster detection

  • delivery
  • devops
  • platform

Author

Dana Whitfield

Principal Engineer

Fifteen years in payments and platform engineering. Writes about the operational side of delivery.

Meet the team

Want this applied to your system?

We will take a look at what you are running and tell you which of the above is worth doing first.