How to prevent developer burnout

Earlier this year, I led a joint research project between engineering productivity business Haystack Analytics and polling firm Survation, to understand the impact of burnout on developers. While there have been attempts to survey developer communities before, this represented the first time representative opinion polling was used to understand software engineers.

When it came to burnout, the results were shocking. We found that 83% of software engineers reported that they were suffering from burnout. The reasons for burnout were diverse, including high workload (47%), inefficient process (31%), and unclear goals and targets (29%).

The pandemic has made things worse, with 81% of developers reporting increased burnout due to the pandemic. The main reason cited for this was increased workload.

Against the backdrop of the personal stresses affecting many in society, software engineers found themselves playing a key role in rearchitecting society during the pandemic. From keeping us connected during lockdowns to contact tracing solutions for venues, this all required increased workload on software engineering teams.

Companies which succeeded during the pandemic were those that embraced technology and focussed on delivering what their customers wanted, despite trial and error being part of that feedback loop.

Companies which suffered the most have failed to use technology to test new business ideas and find new competitive advantages. In these poorly performing companies, the staff either undergo forced marches towards inevitable failure or don’t bother trying. Indeed, the leadership team may have already given up, continuing to cash executive pay cheques while talented staff leave and the clock counts down to the shutters descending on their business.

In its State of DevOps report, Google’s Dora team has found that one trait is particularly important in driving delivery performance: improving software reliability and preventing burnout. One of the key predictors for elite engineering performance was psychological safety. The research found that team cultures which embedded psychological safety were half as likely to experience burnout during the pandemic.

This is complemented by further research by Puppet, which has found that low-performing teams were 2.2 times more likely to have a culture that discourages risk than their high-performing counterparts.

The research went on to state that: “The result of all this is that those organisations that claim to be discouraging risk are actually following practices that increase risk, and many of their existing practices around risk management of infrequent deployments are simply risk management theatre.”

Psychological safety is seen as so essential to performance that professional engineering bodies, such as Engineering Council UK, reiterate it in their professional guidance on risk. Indeed, I found substantial evidence for the benefits of psychological safety in a report I recently wrote, EngProd 2021: A review on the state of developer productivity.

Companies have increasingly begun to look at adopting Engineering Productivity practices to enhance their team performance. The process of measuring team performance, identifying bottlenecks and working to remove blockers requires psychological safety. Teams which attempt to explain away negative performance or are unable to address root causes will struggle to enhance team performance.