PASS Summit West 2026, November 9-11|Register now

To learn and improve, we cannot be afraid to fail

Guest post

This is a guest post from Rob Richardson.

Rob

Deployment stress doesn’t just come from high-profile public outages. It often starts much earlier, when a fear of failure seeps into team culture.

Rob Richardson, Software Craftsman

Rob certainly knows the stress and embarrassment of public deployment failures. "But overall" he reflects, "I’ve had more stress in my career from internal failures. You check in code, the build goes red, and straight away it’s 'Who broke it?', 'Who’s to blame?'"

Managers often unwittingly reinforce this blame-first culture. "To achieve business goals quickly, they want developers to be as perfectly efficient as the machines running the software," Rob explains, "and they’re quick to show frustration when we aren't."

This becomes a deeper source of stress, subtle but corrosive. "Developers start to avoid risk. Innovation stalls, and ironically, deployment risks grow." To truly make deployments safer and less stressful, developers can't be afraid to fail:

"We must give ourselves grace. We’re not machines. Human error is normal, and learning from mistakes is essential if we're to deliver good software".

Instead of encouraging blame, foster a learning mindset: "Never just fix the symptoms," Rob advises. "Be curious, dig deeper into the root cause, and improve the process".

He puts this mindset into action with two simple practices: after any build failure, make the machine do more: add a new test, strengthen an existing check. And after every sprint, go find the noisiest error and the noisiest false-positive log message. Fix the error and remove the log message. "Very soon, your logs will be much more valuable, and you can spot and fix issues long before they reach customers."

Even with this learning mindset, Rob knows that not every situation is under our control. "There will still be high stress days," he says, "when a production fix is needed immediately, and the business needs override any carefully designed process".

And how does Rob reset after one of those days? "Go to a place bigger than yourself," he suggests. "For me, this is a very spiritual place. For you, it might be a hike in nature. Go there, wherever it is, and just enjoy the majesty of it. You’ll come back rebalanced, ready to learn and improve again.”

Get the next stories straight to your inbox.
Sign up for the Redgate Update and we’ll send them as soon as they’re published. You’ll also get industry news, Redgate announcements, event invites, and more.

This document contains proprietary information and is protected by copyright law.
Copyright © 2026 Red Gate Software Limited. All rights reserved

Read next

Blog post

Rollbacks, Red Eyes And Unreliable Deployments

This series is about the stress of database deployments on the people behind them, and the small, steady changes that help relieve it. – Felicity Questier, Redgate Software. Behind every unreliable deployment are the people carrying the pressure. From delayed releases to weekend firefighting and the fallout for teams and customers, these data professionals share the day-to-day challenges they face and the small improvements that help make deployments, and life, just a little less stressful. Click below to read their stories. Naga Santhosh Reddy Vootukuri Principal Eng. Manager, MS Azure SQL “Break it early to ship it safely.” Read Sunny’s

Go to the Blog post

Loading comments...