A report on the wellbeing of UK software engineers (developers and DevOps professionals) found 83 per cent suffering from some degree of burnout, with most agreeing that COVID-19 was partly to blame.
This survey [PDF] was conducted in June 2021 by pollsters Survation, on behalf of DevOps company Haystack, and although the number of participants was small (just over 250) it was conducted by interviews, rather than online forms which are vulnerable to low-quality responses.
The respondents were 26 per cent pure software developers, 30 per cent operations (such as DevOps or reliability engineering), and 44 per cent software engineers who do elements of both. There is no detail on company size but we were told that it spanned from very small to enterprise.
The bad news is that 55 per cent described themselves as experiencing moderate or severe burnout, and only 17 per cent reported no burnout at all. Most (81 per cent) considered that COVID-19 was to blame at least in part, and when questioned about why pointed to increased workload as the top factor, closely followed by "general anxiety caused by COVID-19."
In other words, software engineers are no different from anyone else when it comes to the general stress of living with a pandemic, and that combined with increased workload has imposed a significant burden.
Why has workload increased? Junade Ali, the computer scientist who commissioned the survey, told us that increases in "digitization" is the main factor. "When we go into a coffee shop, we have to scan the QR code to check in, a lot of purchases have been online, a lot of the media we consume has moved online. Every type of... business has had to move online... the pandemic has accelerated the digitisation of the world."
- Burn baby burn, infosec inferno: Just 21% of security pros haven't considered quitting their current job
- Tech won't save you from lockdown disaster: How to manage family and free time while working from home
- Edtech will save our schools from cuts and spare our teachers from burnout, booms UK.gov
- What can you do when the pup of programming becomes the black dog of burnout? Dude, leave
Haystack is keen to link developer burnout with "cycle time," defined in the report as "how quickly an engineering team can deploy ideas into production to get feedback from real-world users." Short cycle times are associated with high-performing developers. Haystack references Google's DORA (DevOps Research and Assessment) team, which divides teams from "Elite" (multiple deploys per day, cycle time of less than one day) down to "Low" (deploys less than once a month, cycle time of one to six months).
That said, the new report does not show any evidence that short cycle times increase burnout. In addition, UK software engineers are, according to this report, better than average when it comes to short cycle times, with 50 per cent claiming to deliver features in no more than two to three days.
The best Ali could come up with is that "Google's State of DevOps report found that [those in] companies with Elite performance are 1.8 times more likely to recommend their team as a great place to work... what makes people burnt out when they're delivering a lot of work tends to be that friction where there are higher demands for work when the process and tooling isn't there. If you are able to remove friction by having the ability to deploy quicker, that makes things smoother."
"We see managers are able to detect burnout but they aren't able to act on it, because these best practices haven't been incorporated into their organisations."
One might add that common-sense management practices – like good communications, not demanding excessive hours of work, and making sure team members take their holidays – could be at least as important in mitigating burnout.
Is it possible that emphasising the importance of short cycle times could have a negative effect, and end up with management yelling even more at developers to speed up their delivery? That would be a misunderstanding.
"When the Google team looked at these causal links, they found that before you even get to cycle time, one of the significant factors was psychological safety in teams. Are people able to raise the alarm for things? Are they able to discuss things? That tends to lead to shorter cycle times, less burnout, and business benefit."
Stress rises when the expectations of management are not aligned with what software engineers know to be achievable, or how they are required to achieve it. These problems are well known and the 2001 Agile Manifesto which favours "individuals and interactions over processes and tools" and "customer collaboration over contract negotiation" remains relevant.
Arguably the high levels of burnout reported are in part because pandemics are stressful, and in part because of continuing failure to adopt Agile methodology. Ali concurred.
"I've been an engineering manager for around eight years, " he said. "There's a lot of companies adopting 'Agile TM' but they don't really have business agility. They try to adopt a waterfall process and brand it as Scrum or SAFe [Scaled Agile Framework], but they aren't truly Agile. They haven't adapted, they're just the same old type of business calling themselves Agile." ®