Burnout in software engineering - introduction

•burnout
Back

If you’ve ever found yourself staring at your screen at midnight, wondering how you got here again, you’re not alone. If you’ve felt that creeping cynicism about the work you once loved, this series is for you.

It seems that culturally we have accepted that burning out, or skating close to it, is an unavoidable cost of our profession. We’ve valorised long work hours. Sleep deprivation is seen as a badge of honour. The ‘always on 10x developer’ is the hero of the team. I’m here to convince you that we can do so much better!

Let’s start by establishing a shared understanding of the issue.

What is burnout and what is its impact?

There’s definitely a tension between productivity/creativity and stress — particularly in technical and creative fields. When that tension involves stress that is healthy and challenging, we experience flow and feel satisfaction. When it tips over into chronic stress, we are headed for burnout.

Here’s how burnout was defined (in 2019)

Burn-out is a syndrome conceptualised as resulting from chronic workplace stress that has not been successfully managed. It is characterised by three dimensions:

  • feelings of energy depletion or exhaustion;
  • increased mental distance from one’s job, or feelings of negativism or cynicism related to one’s job; and
  • reduced professional efficacy.

— The World Health Organization

Burnout is a growing global problem, with direct costs in increased healthcare demand and lost productivity.

Job stress is estimated to cost US industry more than $300 billion in losses due to absenteeism, diminished productivity, and accidents.

— The Workplace Stress Report 2022, American Institute of Stress

Here’s a summary of findings from a recent survey of 2008 participants from across the world.

  • The past three years have seen a steady growth in workplace burnout rates, but it seems to have stabilised at 38% this year (same as last year) with individual perception of wellbeing also staying the same.
  • Burnout is increasing for women and decreasing for men. The rate of women experiencing burnout has grown to 42% (38% last year) while the rate of men experiencing burnout has decreased to 30% (33% last year).
  • Managers aren’t getting the message about employee wellbeing. There is a wellbeing perception gap: 68% of managers say their people’s wellbeing is the same or better compared to 12 months ago. Meanwhile, 45% of participants say their wellbeing is worse in the same period.
  • Workplace burnout can breed loneliness. People who are experiencing burnout are 2x more likely to also suffer from loneliness than those not in burnout.

— The State of Workplace Burnout 2024

Software engineers and product teams

Bringing the focus to software engineers and product creatives, the problem seems to be particularly acute.

Only one in five professional developers are happy with their current job. We asked whether they were satisfied with their current role, and 48% indicated they were complacent while 19% were satisfied.

— 2024 Stack Overflow survey

Clearly this is a subject that deserves our attention. Not only so that we can guard our own mental health and well being, but also so that we can help our colleagues and teams with theirs. Ultimately, if we want to Get Things Done, understanding burnout can help us defend and even boost our productivity and that of our teams.

Some examples of behaviours and patterns that contribute to burnout in software and product teams:

This is all in my bio but I’m going to reintroduce myself in the context of this work. I’m Navin Keswani — I design and build products and lead engineering teams. I’ve worked across academia, government, consulting, and small product companies. I’ve developed a focus on burnout after seeing the effects on myself and on teams I have worked with. I believe that by understanding the myriad of factors at play we can skilfully beat burnout and find flourishing.

I co-founded Anamorphic Digital with Helen Lawson Williams, an organisational psychologist by training and an experienced management consultant. Helen’s deep understanding of burnout is both experiential and grounded in the research. Both Helen and I have observed that high performing teams and individuals are most vulnerable to burnout when we’re taught to be productive, and we’re rewarded for it in ways that don’t apply to recovery.

We have developed TANK, a system that helps beat burnout. We have found that point solutions for managing stress and prescribing generic activities for recovery (e.g. wellbeing and productivity apps) don’t work to combat burnout because they are hard to apply or they are piecemeal and difficult to integrate into a pragmatic system. Instead, since it’s a systems problem, we have devised a systems approach. We called it TANK to encapsulate the idea that the system’s stock is your energy level, its inputs are driven from recovery activities, and its outputs relate to activities that feel stressful. In summary, people need targeted support to learn how to convert bad stress into good stress; recover effectively; manage the balance between stress and recovery; and put enablers in place that make the system easy to run.

TANK-slide

The simple (and unfortunately not easy) principle is to:

  1. Find ways to reward more of what’s important
  2. Amplify rewards for recovery
  3. Reduce rewards for excess stress

That means finding better balance is about more than just setting out to “do more self-care”. It means finding ways to turn down the volume on the rewards for constantly doing more (including in our own self-talk), and turn up the volume on rewards for taking care of our own health.

In this series of posts, I will complement Helen’s writing by focusing on the application of this system to burnout in software engineering teams.

My goal is to bring to light specific patterns in managing and doing software development. These are patterns that help detect when individuals and teams are off balance — and that foster flourishing, joy and productivity.

In subsequent posts I will write about

  • heroic individualism in teams — Tarzanning from fire to fire
  • pair programming — what’s actually important in this way of working and where can it contribute to overwhelm and poor productivity
  • outages, errors, incidents and how we manage them — blame, rescue, and being the victim
  • agile ceremonies and processes — the perfect burn-down chart and other stories
  • values misalignment — the perils of working on a mission or in an environment that actively requires suspending our own values
  • connection and communication in teams — weaponised values, wilfully ignorant applications of disingenuity and other horrors
  • programmer boredom, happiness and motivation — where sucky work hides under the label of ‘tech-debt’ or ‘maintenance’ while shiny work gets likes on the socials

I have been interviewing people in our community to collect their experience and guidance on how to find flourishing while beating burnout. Chronicling these interviews is a great opportunity for me to learn, to re-think and shake loose some of my scar tissue, and to distill principles for you, my audience.

In my next post I’ll write about the heroic individual (anti-)pattern. I will examine the awkwardly misplaced rewards that fuel this pattern and suggest corrective ways to help both the heroes and the rest of us who are left cleaning up in their wake.

Until then, I invite you to reflect on which patterns you’ve observed in your own team. Have you encountered the ‘heroic individual’ dynamic or perhaps ‘weaponised values?’ We don’t have comments on this blog so please reach out directly—I’d love to hear from you.