Why DevOps is Burning Out Developers

Workplace stress costs the U.S economy hundreds of billions of dollars per year and is prevalent across all types of organizations and workplaces. If you have adopted or are in the process of adopting the devops methodology and culture, chances are your software developers are burning out as well.

Devops is about bringing operations and development teams closer. The two parties both need to be responsible for the successes and failures of their services. Developers are having to come to grips with a broader range of responsibilities that may even include supporting production events and urgent matters in addition to performing their existing development tasks.

According to recent studies, including one by Puppet Labs, adopting devops culture creates a significant change in the culture of IT and development organizations and can lead to the increasing phenomenon known as devops Burnout, which is costly for companies and is generally not addressed properly, if at all.

Why Do They Burn Out?

Devops-related burnouts occur due to the fact that although the framework of workplace processes has evolved, the culture around it has not.

 Developers who were used to practicing the traditional waterfall methods of development usually spent a few weeks, or even months, writing code and developing a product before handing it over to QA. If everything worked well, the project was then handed over to operations a few weeks down the line before being pushed to production. In addition, if issues arise, users could turn to tier 3 support and get code-level assistance without burdening the developers.

Developers working in a devops environment, however, do not have a long chain of command. They are responsible for their code from development through testing — and sometimes even all the way to production and end-user support. This entire process needs to be completed at a faster pace than in the past, and the workload can include updating production multiple times every day. For many companies, especially successful ones, this is an ongoing chase of continuously scaling further and further and putting growing pressure on engineering teams.

It is no surprise that developers are now more likely to crumble under stress — especially because they know that they are directly affecting the end-user experience. With the ability to create rapid changes and innovate quickly comes the acceptance of great responsibility that can increase stress levels and cause severe damages when not carefully managed.

Developers Don’t Work in Operations for a Reason

When comparing developers to operations teams, the differences are stark. In contrast to traditional developer roles, operations team members are used to multitasking and solving a variety of issues to support end users. They have practical experience with the mental robustness that is needed to deal with the challenges that they face on a daily basis.

As a result, the organizational decisions made by management should reflect the understanding that ops teams work differently. Just like any other employee, ops team members are susceptible to overload and burnout. However, due to their existing tools and organizational approaches to irregular work such as rotating shifts and a division into different layers (NOC, first and second tier), they are able to maintain a level of balance between team members. Ops teams have mentalities that developers do not have.

No tool or approach that resembles the ops mentality has been created to support the overall devops work environment, especially not specifically for developers.

So, What Can Be Done?

It is impossible to arrive at a concrete conclusion or solution because this topic has not been fully researched. However, I can speak from personal experience.

At Logz.io, we’ve seen the negative effect of burnout on developers. As the challenge to scale grows, the tempo of releasing to production becomes faster, and developers are often called to help with investigating production issues the effect on the team is imminent. We’ve realized that even with a super-agile environment, we need to create an atmosphere that encourages thorough research, quiet and low context switching, and assigning different shifts to support production issues.

Another approach is to look at a new class of profession known as SRE (Site Reliability Engineers) that has been created to help bridge the gap between development and operations. As a kind of support team for developers and the middleman between dev and ops, SREs aim to ease any built-up pressure, enable the effective development, and use the methods of software engineers to address an operations set of challenges.

At the end of the day, it is the developers who are fully responsible and have to ensure that everything is functioning sufficiently and that deadlines are met. However, they need to be aware of the risks as well as the balance that needs to be maintained. Team leaders need to create a supportive work environment and ensure that their developers understand how their own personal achievements tie into high-level product and organization objectives.

This point was emphasized in the Reddit discussion below:

It’s important to give yourself small achievements. One of the biggest causes of burnout is all work and no achievement. Make your milestones smaller and feel proud about them. Programming is not about the castles: it’s about piling grain after grain of sand and enjoying that.

Team members at risk of burnout need to be closely monitored. How much time do developers invest in delivery (including tests, fixes, and the assistance given to resolve production issues and technical debt)? Do developers work late? How many issues did they deal with in production last week?

Managers need to be sensitive to burnout signs such as fatigue, a lack of patience, an increase in bugs, and stress when trying to meet deadlines. Obviously, once you understand what someone is going through, you can solve the underlying problems much better.

A Final Note

Devops is a revolutionary change in IT culture that enables companies to reach their business goals and increase profits. When a culture changes, however, individual employees are affected on many levels.

Yes, it is important to accommodate continuous integration and continuous delivery. But it is equally important to incorporate tools and processes that support the human aspect of devops and enable engineers to have productive, balanced lives while coping with all of the new challenges that are now being thrown at them at work.

Note: This post was originally published on InfoWorld.