If a company wants to tout high-quality software, you might expect that organization's leaders would want to focus on reducing the amount of errors in releases.
Some companies may even opt to take an extremely risk-averse approach to releases, thinking fewer errors means superior software. However, that type of strategy can backfire over time.
When developers and engineers are held to such strict standards and processes, they can feel too constrained and fearful of stepping out of line. For the larger organization, that highly-focused attitude on avoiding mistakes can impact everything from retention to the ability to create any sort of meaningful progress that could separate a product from its competition.
This is one of the findings from our new report, "Release assurance: Why innovative software delivery starts with trust and psychological safety." To gather data for the report, we worked with an independent firm, Wakefield Research, to survey 500 developers of varying titles and industries.
The results help spotlight some of the ways companies are mismanaging releases and missing opportunities with modern development teams. We also offer some potential steps that can be taken to improve overall output.
Too much focus on errors impacts retention
There's an old adage that says pressure makes diamonds, and maybe that's true for some things. But when it comes to software, too much focus on minimizing mistakes does not necessarily add more value.
Sixty-seven percent of the developers we surveyed either have (or know someone who has) left a job due to an overemphasis on minimizing deployment errors. That goes back to the idea that if you're too cautious with software releases, it'll end up costing you.
From our perspective, developers who feel encouraged and supported by leadership to take risks often feel more confident in their work. And those incremental risks can lead to larger, organizational success.
Virtually all of the developers in our survey say applying new development approaches and solutions can positively affect business outcomes, especially by encouraging greater innovation among staff (53%), increasing adaptability (52%), and even improving the bottom line (49%).
In our report, the majority of development teams say their organization is actively trying to make things better for developers. And we did pick up a pretty high overall job satisfaction rate: 92% of developers say their teams are either very satisfied or somewhat satisfied with their current roles.
Trust improves productivity
If your organization is trying to improve the results for developers, that's a good first step. In fact, 86% of respondents who described their company as prioritizing developer outcomes for software releases as either a top or high priority also say they are satisfied with their roles. Contrast that with just 14% of developers who say they are satisfied with their position even though outcomes are not a top priority for their organization. If you don't feel like leadership has your back, you're probably not that happy at your job.
And business leaders can't just say they're trying to improve the performance of developers. Their efforts need to be observable. Virtually all of our respondents (99%) reported a desire to feel safe when taking risks in deployment, especially when it comes to internal buy-in, tools, and culture (94%).
If devs feel supported by their companies, management is more likely to see tangible results. As we found in the report, when leadership places the improvement of developer outcomes as either a top or large priority, 67% of developers say there's a much stronger focus on releasing updates faster as opposed to avoiding rollbacks. So, basically, dev teams that feel like their companies are looking out for them are also releasing more frequently.
To err is human though, and if you're releasing smaller updates at a faster pace, that seems to be a safer bet. More than half (56%) of our developers surveyed say they feel more confident in the deployment process with smaller, more frequent deployments rather than larger, less frequent deployments. This method allows for less consequential rollbacks, as well as provides the space and safety needed to try new things.
Adjusting approaches to risk reduction is not the sum total of a good strategy though. Everything from your processes to the actual psychological safety of teams matters.
Safety leads to innovation
When we talk about the term "psychological safety" in the report, we're referring to the notion that team members can feel free to mess up, speak up, or both, without the fear of getting punished or humiliated for it. When psychological safety is championed in a team's culture, that brings a confidence that not only spreads to developers and entire organizations, but also to those on the receiving end of software updates.
As teams feel more self-assured, they also start to innovate more. And the ability to experiment, which can lead to innovation, is a big focus for developers.
Eighty-six percent of developers feel it's a major priority for their careers to try new ways of working through experimentation. And when there's clearly so much appetite for experimentation, leadership should consider feeding it.
But you can't experiment or innovate if your company is too afraid of doing either. Fully 100% of the developers surveyed said taking risks and applying new development strategies can positively affect business outcomes, especially by encouraging greater innovation among staff (53%), increasing adaptability (52%), and improving the bottom line (49%).
None of this is to say organizations should be okay with letting their dev teams run wild and not worry about dropping sloppy, bug-filled features. There's definitely a balance to be found, and a path to get there.
Download our report now to get all the data and analysis, and learn the steps companies can take to improve their releases.
.webp)
