“Burnout” happens across all jobs and industries, especially tech. However, developers have always been particularly at-risk of falling victim to burning out, and the COVID-19 pandemic, and the resulting digital shift driven by software, has only escalated this problem. Just look at the trends, as 38% of developers are releasing software monthly or faster, up from 27% in 2018, creating a high-stress reality. This increased pace and immense pressure surrounding software development have made burnout an even bigger reality than before, at a time when developers couldn’t be more essential to maintaining business continuity. The negative consequences of this trend have mental and physical health implications for developers who are finding themselves in a constant cycle of aggressive productivity. The telltale signs of burnout, like missing key deadlines, lack of motivation, last-minute sick days, and careless mistakes, should serve as major red flags for leadership. And, while burnout clearly impacts developers, their corresponding organizations are also more likely to experience side effects such as elevated security risks due to attention lapses. If you’re seeing these signs, it’s important to take a moment to evaluate the conditions your developers are working under and provide the necessary resources to address burnout accordingly. Here’s how.

Increase Training, but Make It Enjoyable

One of the most effective tactics in preventing burnout is to ramp up secure coding education and training. While this might feel counterintuitive as if it’s adding yet another task to developers’ plates, when done right, these initiatives can have lasting effects that help them become more aware of common security issues and capable of remediating them in a timely manner. Where many training programs often fall flat is that they’re boring, forced, and take developers out of their usual routines and workflows, all big reasons why they often get a bad rap. In order to really break through to developers and make a real impression — and in turn, drive real change with how security is implemented into software development — training initiatives should take a more gamified approach to keep developers engaged and entertained. For instance, these training modules can be turned into tournaments, which promotes friendly competition. You can add fun prizes or (virtual) events for folks to come together and learn while having a little fun. I also recommend delivering lessons in short, frequent bursts to keep security top-of-mind in their daily operations without the draining stigma associated with half or full-day training sessions. These integrated bite-size, relevant training modules can be inserted directly into a developer’s daily routine so that developers do not have to endure hours of out-of-context training sessions. If you provide your developers with the proper training to think about security from the beginning stages, you have the ability to curb stress later on by minimizing the chance of major vulnerabilities.

Share Security Responsibility and Ownership

There’s a common misconception that security is the responsibility of developers and developers alone. Not only is it untrue, but it’s also an inadequate mindset given today’s evolving threat landscape. It takes a village when it comes to security and there needs to be concrete alignment between DevOps and AppSec teams and employees in other departments to create a comprehensive security program. I recommend having the AppSec team lead the strategy around security procedures, with input from the developers who are on the frontlines executing it in the wild. If there are apparent gaps in security protocols, developers should advocate for the tools and resources they need to achieve a strong security posture. The application security testing (AST) space is made up of many different solutions, with one goal in common — to secure software. Generally, static application security testing (SAST) and software composition analysis (SCA) are two of the better known and used solutions. Though, in the last few years, we’ve seen more attention on Interactive Application Security Testing (IAST) as well. Regardless of the AST tool your organization invests in, ensure it aligns with your overall AppSec strategy and fits seamlessly into your existing workflows and CI/CD pipelines. Nothing will make developers resent the idea of security more than trying to fit a square peg in a round hole when it comes to testing solutions. Remember that the end goal is to alleviate their workload and optimize their coding processes in a secure manner.

Automate, Automate, Automate

Many functions in the world have become automated to make our lives and jobs easier. Just as self-driving cars are no longer an abstract thought of the future, key functions within the developer role and the AST tools they use are now being automated to make security simpler. In fact, 30% of DevOps leaders are prioritizing “software development life cycle” (SDLC) automation in 2021, according to an analyst study. It’s no hidden secret that developers often view security as a burden as part of their day-to-day coding processes. However, more often than not, this scenario plays out because they don’t have access to tools that make embedding security into their CI/CD pipelines seamless and easy. By implementing automated security testing tools — especially those that cover proprietary and open source code — scans can be automatically triggered, with results prioritized based on severity. With this ability, developer workflows are streamlined and they’re able to find and fix flaws more confidently without compromising speed and security, ultimately allowing them to do what they do best and love most — coding. Modern automation tools create a seamless way for developers to catch and fix vulnerabilities during the earliest coding phase. In turn, developers can easily address and remediate security bugs and functional flaws while reducing the overhead of manually opening, validating, and closing security tickets. This alone saves countless hours for developers.

Have the Tough Conversations

Providing the right training and automation tools is just the tip of the iceberg. Alleviating some of the aforementioned burdens on developers doesn’t automatically mean they are less stressed. If you’re in a leadership role or are tasked with managing a development team, check-in with them frequently. Having a constant pulse on the morale of your employees and their stress levels will empower you to make the necessary changes before it reaches a point of burnout. Yes, software needs to be built and delivered faster, but this shouldn’t come at the expense of developers’ mental and physical health. Collaborate with leadership and encourage an open-door policy so that developers can come to you to talk about issues they are facing in their day-to-day work environment. This will ensure less burnout and turnover, while also boosting morale and leading to greater software integrity, quality, and security. This article originally appeared in the The New Stack.