As important as it is for organizations to continue to innovate their software products quickly and with quality, that cannot be achieved in today’s world without ensuring “psychological safety” for its development teams.
Ravi Tharisayi, senior director of product marketing at feature management software provider LaunchDarkly, defined the term as a strong interconnection between software development as a process, the tools and the cultural environment in which all of these things come together.
“Increasingly, we see that this notion of sort of trust and safety are really key indicators and dimensions of how an organization is able to implement new innovations, implement new innovative ideas, implement new innovative processes, and evolve their software, deliver it in a way that’s actually impactful and really delivers the change that they’re looking for,” he said.
LaunchDarkly today released a report on psychological safety and innovative software delivery in conjunction with Wakefield Research, and its survey of 500 U.S.-based developers found that developers are seeking work environments that encourage taking risks. In fact, 93% of responding developers agreed that the confidence to safely release code updates empowers them to innovate more.
Experts agree this need for psychological safety has sprung for the new generation of workers, who want to work on meaningful projects, have the freedom to take risks to secure better outcomes, and who don’t want to be pressured to minimize deployment errors, according to the report. They look for organizations where leadership supports this kind of risk-taking; 100% of the respondents said taking risks and applying new development strategies can positively affect business outcomes, by encouraging the staff to innovate (53%), increasing adaptability (52%) and improving the bottom line (49%).
“There is this kind of confluence of really challenging factors,” Tharisayi said, “especially since the pandemic, where digital and software development has now become so core and so critical, where outages can really damage your business even more. It feels like every year, the cost of an outage feels more and more impactful to the business, that the stakes are higher and higher. And I think for us, you know, the thing that we see a lot is and I think part of what we’ve honed in on it, and why we come across it so much, is that there’s always been this fear of the point at which code gets to the customer, because that is really sort of the moment of truth, where you’re going to find out if the thing that you built and coded is actually going to work.”
One of the factors the report homed in on is the process organizations have for software development. Most developers (94%) say internal processes, tools or culture are necessary to feel safe about taking risks to deploy updates, according to the report. But 61% said their company’s heavyweight development processes are barriers to innovation.
In many organizations, the traditional model is to centralize everything, to create one standard way of doing things, and Tharisayi said that notion is facing some backlash. “I think there’s increasingly more of these sort of platform concepts where we’re going to give you the guardrails, and you’re going to have freedom to operate within those guardrails, here’s the three cloud providers that you can use and the set of policies that you can use. So you have some autonomy within these guardrails to operate as you as you want to. But it’s within a little bit more of a constrained guardrails.”
Too much standardization, which is process-heavy, creates a risk of not fitting the unique needs of particular teams. The flip side of that is too much decentralization and autonomy, which can result in such a diversity of processes that also is risky, so finding the right balance of decentralization is key.
“One of the things in the report that we highlighted was one of the indicators that we found around a culture of healthy risk-taking was organizations looking to explore ways to streamline processes, and especially related to governance and approval processes for code going to production,” Tharisayi said. “Still, in our survey, almost half of respondents indicated that most or all of their code changes require manual approval. And that sort of flies in the face of what some other research has come out, notably from DevOps Research Assessment that noted that heavyweight change approvals are negatively correlated with higher software performance. And so this whole thing around process, I do think is noteworthy in terms of fostering the right level of trust and autonomy within the teams, but also enabling the right level of guardrails that the diversity of process doesn’t get so out of control that it also in a way creates its own risk.”
The takeaway from respondents to the survey is that you can only feel confident to make the suggestions to improve things if there isn’t a fear of backlash. Innovation must be nurtured and fostered, without negativity around it.
“And I think that’s very much what the respondents in our survey were looking for,” Tharisayi said. “There is going to be a fear of risk, but also that there can be healthy opportunities to explore new ideas and take risks in a healthy way that allow you to optimize the entire process.”
