Discussion on "Heroics are not a deploy plan"

Randi W · 2026-10-18T09:05:13.014Z

The first coordinated deploy I watched closely wasn't a big one. A site was moving from being hosted in our CRM to being hosted by IT, and a few teams had to line up to make it happen. It was my first

A coordinated deploy that depends on one person staying late is a plan with a single point of failure, even when it works. I liked that your example was a small move, a site going from CRM hosting to IT, because the small ones are where nobody thinks a written plan is needed.

On the question in the replies about a minimum set for a small team, the list I would keep is short: a written statement of what deployed means for this change, one rollback step that has been tried at least once, a named owner for each team involved, and a check that runs after the release instead of someone clicking around. Anything beyond that can grow with the team.

A useful test for red tape versus a useful check is whether anyone can say which failure it prevents. If nobody can, people will route around it. Which check from that first deploy turned out to matter most?

“Which failure does it prevent?” is a great test, and I’d add a second: does it still fit?

Honestly, no single check from that deploy mattered most. What matters is not treating the process as finished. We watch for friction all the time and talk about it every sprint, not just at the end of a project. What fits a team one year might not fit it the next. Teams grow, shrink and change; systems change under them. A check that prevented a real failure last year can be pure red tape now, and a gap you could live with at five people can sink you at fifteen.

That’s what retros are for, and not only the team’s output: the process around the team too. What went well, what could be better, which step is the bottleneck now, what can be automated so nobody has to remember it. Try something for a sprint or two, then keep it, tweak it, or go back. Change is the only constant, so the process has to change with it.

The red tape vs useful checks split is the hard part. Heavy process teaches people exactly where to cut around it, which ends up worse than no process. Where did you land on a minimum set for a small team, the checks you would keep even with two people and hourly releases?

For two people and hourly releases, I’d keep four:

The change says how it ships. Steps and a rollback written on the ticket, not in someone’s head. Ours is a sub-task Jira creates from a label. The other person reads it. A real review of the steps and the rollback, not a click. With two people, that’s the whole review board. Tests that check behaviour, written while you’re in the code. Not coverage padding at the end. One check after every release that someone owns. Automated if you can, named if you can’t.

Everything else (CABs, multi-level sign-offs, freeze windows) earns its place as the team, the systems and the blast radius grow.

And the list isn’t fixed. Watch for friction and talk about it every sprint: if nobody can say which failure a check prevents, it’s red tape, and if something keeps slipping through, you’re missing a check. The right minimum for two people won’t be the right one at ten.

Search Hashnode

Heroics are not a deploy plan

Responses4