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.
Risk management
For software engineers to produce reliable software, they must be able to correctly balance the competing forces of risk and reward while not fearing being shot for raising the alarm to unmitigated risk. For a business to grow, it must be able to take calculated and balanced risks using their professional judgement. No risk, no reward.
For software engineers, managers who are scared of admitting the limits of their own knowledge or are defensive about admitting mistakes should act as a huge warning sign. During job interviews, I believe it is important to ask a future manager questions such as: “When was the last time you didn’t know something?” or “Tell me about the last time you made a mistake?”
Messengers should not fear getting shot and success through calculated risks should be rewarded. Feedback should be taken, not just given. Defensive cultures, where leaders cannot admit to their mistakes or the limits of their knowledge, should serve as a red flag to engineers going through the recruitment process. Strong engineering leaders have the humility to accept their own humanity.
As I have seen in my own career as an engineering manager, fundamental to developing psychological safety in an engineering team is that the leadership admits to their own fallibility and are open to feedback on their own work.
Much is required to build successful software engineering teams, but what support do managers deserve if they don’t even permit their engineers a safe space to flag up risk?
Junade Ali is a software engineering manager and helps mentor engineering leaders at Haystack Analytics.
