Burnt out

Is DevOps making you sick?

JAXenter Editorial Team
Help image via Shutterstock

The transition to DevOps for many companies has been a successful move. However, now that the processes between development and operations are getting an overhaul, corporate culture has been left to its own, resulting in many burnt out developers.

The increasing fusion of application development and IT operations is one of the greatest revolutions in the IT world that has spawned in recent years. But in addition to the indisputable advantages arising under DevOps, the problems shouldn’t be underestimated.

What happens, for example, when framework and (corporate) culture don’t fit together? A burnt-out developer is the inevitable result says Tomer Levy, CEO of software company

SEE ALSO: Revisiting empathy, the essence of DevOps

According to an estimate from the WHO, stress-promoting working conditions attract – in the US alone – an annual cost of around 300 billion US dollars. A study by the Chartered Institute of Personnel and Development (CIPD) identified stress as the leading cause of long-term sick leave. For Levy, a takeover of DevOps means that the chances are “pretty good” that software developers are part of that statistic.

DevOps tries to breach the traditional trenches that exist between application development and IT operations and hopes to fill and overcome them as much as possible, to allow both areas to work closer together. This was naturally accompanied by broader responsibilities for developers. It is often spoken of in this context as a cultural change.


Levy believes that a cultural change can take care of increasing burnout cases among developers. In his view, while we’ve developed the necessary  processes for a successful transition to DevOps, the culture in the workplace hasn’t caught up.

As part of the traditional Waterfall model, developers spent weeks or months with writing code, eventually developing a product and delivering it to QA. At best, a few weeks was all it took to hand over to Ops and then into production. Questions from users were handled by specially-assigned support and weren’t left to the developers themselves.

… and now

In the case of DevOps, this chain no longer exists. Developers are now often responsible not only for development and testing, but are also required to accompany the code into production and end-user support. At the same time, the speed of the process has increased significantly, with some companies making updates to code several times a day or even several times an hour.

By having such an impact on the end-user experience, the higher rate of developers bowing under pressure is increasingly clear for Levy – especially when corporate culture has yet to catch up with the new operational processes being implemented.

Possible countermeasures

So what can be done to alleviate the pressure? While a concrete solution hasn’t been offered by Levy, he has shared some of his own experience-based approaches for others to consider.

One possibility is to provide a working atmosphere that allows thorough investigation and smooth transitions of work context, paying attention to the change in production problems for developers. Another approach Levy mentions is the use of SREs (Site Reliability Engineers), a relatively new profession, that serves as a quasi-support team for developers and as an intermediary between Dev and Ops.

Last but not least is the point that developers are always responsible for the functioning of software and their adherence to deadlines, but this is by no means sufficient. For Levy, the team leader and other leaders need to be on board in the process. This should provide a supportive working environment, allowing them to know how much time an employee spends testing, bug hunting and helping out on production problems.

SEE ALSO: Where DevOps can make a difference

Ultimately, part of their role is to keep a watchful eye on typical burnout symptoms such as fatigue, lack of patience and increased stress in meeting deadlines. Once you understand what employees are going through, Levy says that it becomes easier to solve the underlying problems – for the benefit of employees.

It should be noted, however, that the protagonists of the DevOps movement would hardly call a pure merging of Operations and R&D departments “DevOps”. Without the aforementioned cultural change, achieving peak DevOps isn’t possible and is at most a shift of tasks that disadvantage the developer in most cases.

Inline Feedbacks
View all comments