Proponents of DevOps typically pitch the concept as a great way to increase efficiency and productivity. By increasing collaboration between developers and IT operations engineers, they say, DevOps allows everyone to work more effectively toward common goals.
That's probably true in many cases. However, there's an argument to be made that DevOps also comes with a major downside: increased stress levels for the engineers responsible for keeping DevOps processes running.
Here's why DevOps may make the lives of engineers more challenging, and what organizations can do to ensure that they benefit from DevOps without driving their engineers insane.
How DevOps Benefits Businesses
To begin, let's look at what DevOps means and how it helps businesses.
DevOps is, of course, the idea that development and IT operations teams should work closely together — that close collaboration between developers and ITOps ensures that both teams can support each other.
DevOps was conceived to solve a challenge that many organizations faced in earlier decades, which is that developers often wrote code with little or no feedback from the ITOps team, which was then expected to deploy and manage applications that it played no role in helping to plan. That led to communication silos, inefficiencies, and, in some cases, tension between developers and ITOps engineers. By helping everyone work together on a continuous basis, DevOps allows organizations to avoid these pitfalls.
From a business perspective, then, DevOps is a great thing because it helps to ensure that engineers are as productive as possible. It minimizes wasted time and effort, and it typically increases the velocity at which businesses can push out new software — which in turn gives them a competitive edge in the market.
What DevOps Means for Engineers
For engineers themselves, though, DevOps is not always so rosy. DevOps forces engineers to do two things that can increase the stress of their jobs:
- Assume ownership of a broader set of responsibilities: Instead of being responsible just for software development or just for IT operations, DevOps requires engineers to take ownership of both types of processes.
- Adapt to faster-paced release cycles: DevOps goes hand-in-hand with practices like CI/CD, under which DevOps teams are often expected to release new application updates at least once a week, and sometimes as frequently as once a day. That's a big departure from the days of "waterfall" software development strategies, when new releases happened once or twice a year, if that.
Both of these factors can make engineers' jobs more intense. In a business that embraces DevOps, engineers are expected to do more, and do it faster.
It's possible, of course, that the efficiencies that DevOps introduces to software delivery processes make it possible for engineers to meet these tighter expectations with a lower overall level of stress than they'd experience in the absence of DevOps. Without DevOps, teams typically waste more time fixing code and pointing fingers at each other when something goes wrong, which is its own form of stress. By mitigating these challenges, a well-implemented DevOps strategy can make engineers happier overall.
But not all DevOps strategies are well-implemented, and there's an inherent risk in DevOps that a DevOps strategy will simply result in engineers who are more stressed out, and more likely to burn out. They might manage to churn out new releases faster, but that achievement comes at a high price in terms of engineer job satisfaction.
Keeping DevOps Engineers Happy
To avoid these problems, businesses that choose to adopt DevOps should ensure that they set reasonable expectations. For example, having new releases once a week might create too much pressure for engineers, at least at first. Setting more modest goals can help reduce the risk of DevOps engineer burnout.
Limiting the responsibilities of DevOps engineers can help, too. Although DevOps typically encourages the idea that everyone on the DevOps team shares collective ownership for every part of the software delivery process, it's often more realistic to have some engineers take the lead for certain processes (like development, testing, and deployment). There can still be a general sense of collective responsibility, but designating leads for different types of tasks can reduce the overall level of stress that each engineer feels by allowing team members to prioritize certain tasks instead of trying to own every single stage of the software delivery lifecycle.
And in some cases, organizations should simply limit the extent to which they adopt DevOps in the first place. Not every application needs to be continuously developed; some apps, such as legacy software, don't change frequently enough to merit being shoehorned into a CI/CD pipeline. By being strategic about where to implement DevOps, businesses can reduce the risk of foisting too many DevOps practices upon engineers who don't have the capacity to handle all of them.
Conclusion
When it comes to DevOps, there is such a thing as too much of a good thing. Although DevOps does offer great benefits to businesses while also helping engineers be more efficient and productive, it can stress out engineering teams, too. To protect against burnout, organizations should be careful to avoid going overboard on DevOps.
About the author
Christopher Tozzi is a technology analyst with subject matter expertise in cloud computing, application development, open source software, virtualization, containers and more. He also lectures at a major university in the Albany, New York, area. His book, “For Fun and Profit: A History of the Free and Open Source Software Revolution,” was published by MIT Press.
