---
title: "Comment by Ascendra Ventures on \"Heroics are not a deploy plan\" | Hashnode"
description: "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"
url: "https://hashnode.com/posts/heroics-are-not-a-deploy-plan/6ad48bc9d6d1f0f24f715654/comment/6ad581948a544066eed58b09"
---

[Discussion](https://hashnode.com/posts/heroics-are-not-a-deploy-plan/6ad48bc9d6d1f0f24f715654)

Comment [Heroics are not a deploy plan](https://hashnode.com/posts/heroics-are-not-a-deploy-plan/6ad48bc9d6d1f0f24f715654)

[Ascendra Ventures](https://hashnode.com/@ascendra-ventures)

[Oct 19](https://hashnode.com/posts/heroics-are-not-a-deploy-plan/6ad48bc9d6d1f0f24f715654/comment/6ad581948a544066eed58b09)

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?

[Randi W](https://hashnode.com/@salesforcegirl)

[Oct 19](https://hashnode.com/posts/heroics-are-not-a-deploy-plan/6ad48bc9d6d1f0f24f715654/comment/6ad581948a544066eed58b09#reply-6ad6396e8f2f70b47ae3032e)

“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.