--- title: "Discussion on \"Heroics are not a deploy plan\" | Hashnode" description: "Discussion on \"Heroics are not a deploy plan\". On rubber-stamp approvals, test classes written at midnight, estimates nobody practiced, and what changed when we stopped relying on heroes." url: "https://hashnode.com/posts/heroics-are-not-a-deploy-plan/6ad48bc9d6d1f0f24f715654" --- [Feed](https://hashnode.com/feed) / Discussion # [Heroics are not a deploy plan](https://salesforcegirl.hashnode.dev/heroics-are-not-a-deploy-plan?utm_source=hashnode&utm_medium=feed) On rubber-stamp approvals, test classes written at midnight, estimates nobody practiced, and what changed when we stopped relying on heroes. Oct 18 · 9 min read · salesforcegirl.hashnode.dev Updated 4d ago Read the article - [#devops](https://hashnode.com/tag/devops) - [#software-engineering](https://hashnode.com/tag/software-engineering) - [#testing](https://hashnode.com/tag/testing) - [#cicd](https://hashnode.com/tag/cicd) - [#salesforce](https://hashnode.com/tag/salesforce) - [#agile](https://hashnode.com/tag/agile) - [#tdd](https://hashnode.com/tag/tdd) - [#leadership](https://hashnode.com/tag/leadership) ## Written by [Randi W](https://hashnode.com/@salesforcegirl) @salesforcegirl · Lakeport [View profile](https://hashnode.com/@salesforcegirl) See a need, fill a need: Untangling real-world Salesforce orgs, building healthy engineering teams, & shipping software without the burnout Vendor demos show pristine systems, but real-world orgs are 10-year-old hoards of competing triggers, forgotten packages, and technical debt. And the teams running them are often burning out trying to keep the wheels turning. I’ve spent just under 20 years in the enterprise trenches—from making desk waffles to boost morale on support calls at LogMeIn to building team health frameworks and leading systems engineering at SurveyMonkey and Salesforce. I write about untangling messy systems, building solutions for complex systems and why genuine team care is just as critical as clean architecture. ## Responses 4 Markdown supported · ⌘↵ to post [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. [Abhinav Sharma](https://hashnode.com/@abhinavs1920) [Oct 18](https://hashnode.com/posts/heroics-are-not-a-deploy-plan/6ad48bc9d6d1f0f24f715654/comment/6ad51ff2906aba25211e81ea) 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? [Randi W](https://hashnode.com/@salesforcegirl) [Oct 19](https://hashnode.com/posts/heroics-are-not-a-deploy-plan/6ad48bc9d6d1f0f24f715654/comment/6ad51ff2906aba25211e81ea#reply-6ad639618f2f70b47ae302e6) 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.