Developer Burnout — Signs, Impact, and Prevention

What is burnout?

Burnout is an increasingly widespread and destructive mental health challenge for knowledge workers across professions and industries. Left unchecked, it is a silent killer of productivity, happiness, and team success.

Unlike other types of stress, burnout is typically chronic and workplace-related. It is a result of unresolved and persistent stress that leaves workers feeling drained and unable to reach their full potential. According to the World Health Organization:

Burn-out is a syndrome conceptualized as resulting from chronic workplace stress that has not been successfully managed."

Burnout manifests in different ways for different people. For many workers, burnout is often associated with feelings of tiredness, helplessness, cynicism, and a drop in performance and motivation.

The World Health Organization's definition of burnout specifies three key dimensions of burnout:

• 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.

How common is software engineer burnout?

Burnout is an especially prevalent challenge for engineering teams and tech workers. Developers frequently navigate fast-paced and high-growth work environments, building mission-critical software—often without the systems, processes, and culture needed to support their work.

Recent Gallup surveys reveal most workers, about 76%, experience burnout. More specifically, 28% of workers responded that they experience burnout very often or always. Less than a quarter of workers feel they rarely or never experience burnout.

In certain industries, such as game development, engineers are expected to work long hours and against strict deadlines. They often need to make last-minute changes before launch during a frenzied period of work infamously dubbed "crunch time." In one example at Rockstar Games, management admits to perpetuating a culture of burnout and hardship. According to Time:

The chief executive of Rockstar Games, publisher of the hugely popular Red Dead Redemption 2, bragged in an interview last year that people there were working 100-hour weeks to finish that game in time for its scheduled release date.

Chaotic release schedules and deployment setbacks are surprisingly prevalent across the world of software development. Companies rely heavily on engineers to ship code faster and provide value to customers, but often lack the DevOps practices to support them. Instead, developers often face delays, deployment pains, and organizational fear and mistrust that disrupt their team's flow.

Such recurring organizational hurdles lead to chronic frustration—and ultimately developer burnout.

What causes software engineer burnout?

Burnout often arises from issues within the organization, rather than the individual. Many engineering teams fail to sufficiently address the causes of burnout because they focus on fixing people and not the systems that support them—or fail to support them.

According to Accelerate, a research-backed guide to building high performing technology teams, the six main organizational risk factors for developer burnout are work overload, lack of control, insufficient rewards, breakdown of community, absence of fairness, and value conflicts.

Work overload arises from unrealistic expectations about the quantity or quality of work developers need to satisfy. Impossible deadlines, poor project timeline estimates, and insufficient planning push developers to work beyond what is physically and mentally sustainable. Developers who work long hours, nights, and weekends are more likely to burn out than those with better work-life balance.

Workload, however, is not the only risk factor for burnout. Contrary to popular belief, teams with balanced workloads can still experience serious developer burnout. Developers can burn out working 100 hours per week, but they can also burn out working just 20 or 30 hours per week.

In situations with manageable workloads but poor workplace culture, other organizational risk factors can lead to chronic stress and create unpleasant work environments. These risk factors disrupt an individual or team's development flow, making work consistently and unnecessarily difficult or challenging.

Lack of control in decision making processes leads to detachment from an organization's mission. When developers feel an inability to influence or contribute to decisions that affect them and their work, it breeds mistrust and creates distance between workers and managers.

For example, developers are sometimes forced to use tools they find ineffective. Developers can be at the mercy of slow workflows across the stack, from change approval boards to code reviews to data requests. In some organizations, development and operations may be making decisions about team practices without input from each other, creating organizational tension.

A breakdown of community also leads to an unsupportive, hypercompetitive, and stressful workplace. Moreover, harassment and bullying leave developers feeling isolated and fearful. Without community support or unbiased feedback, developers must grapple with additional stressors that detract from their quality of life.

Absence of fairness (a lack of fairness in decision making) and insufficient rewards, (a lack of positive reinforcement and feedback) also leave developers feeling not in control of their work and outcomes.

Cultures that rely on blame—not organizational learning—perpetuate a lack of fairness and recognition. Rather than solving underlying system weaknesses, organizations sometimes blame and shame developers for engineering challenges, such as buggy code, change failures, or missed deadlines.

Lastly, value conflicts that result in a mismatch between organization, team, and individual values create chronic stress. For example, a developer who values individual privacy working on ad tracking software can be worn down by the constant internal tug-of-war between her personal values and her company's mission.

What is the cost of developer burnout?

Stanford researchers estimate burnout leads to nearly $190 billion in healthcare costs each year and contributes to more than 120,000 deaths.

In addition to healthcare costs, burnout leads to lost productivity, sick time, costly disabilities, and turnover. It's estimated that workplace stress costs the U.S. economy more than $500 billion per year. Researchers believe nearly 550 million work days each year are lost due to stress and burnout.

For engineering teams, developer burnout leads to slower delivery speed, lower quality code, poorer project outcomes, and higher turnover. In the long run, burnout can also stifle innovation, creativity, and organizational learning.

How can managers spot signs of developer burnout?

It's important to understand that people react differently to burnout. Workers can experience several symptoms all at once, or just one or two at a time. Some workers experience mostly mental symptoms, while others experience physical and bodily changes.

It's also important to remember that burnout is not a binary state. Instead, workers move up and down a 'burnout gradient' depending on their changing environment and workload.

Mental and emotional symptoms of burnout include:

• Tiredness or exhaustion: You feel too emotionally drained to engage fully with your work or coworkers.

• Cynicism or negativism: You view your role as increasingly stressful and frustrating.

• Detachment and alienation: You feel distant from coworkers and the company mission. You feel "numb" about your work.

• Reduced performance or productivity: You are less effective at completing tasks on time. Your quality of work noticeably decreases.

Physical symptoms are also common. Developers experiencing burnout may notice that they are more fatigued and exhausted than normal, yet may also suffer from sleeplessness. They may also be experiencing frequent headaches, loss of appetite, gastrointestinal issues, or dizziness.

Can you detect burnout through metrics and data sources?

By looking more closely at their DevOps metrics, teams can spot early signs of burnout, developer frustration, and deployment pain.

Teams should watch for indicators that their work is needlessly challenging or painful to complete. They should watch for signs that their engineering systems—i.e. organizational workflows and processes—are ineffective at providing developers with fast feedback, avoiding delays, and preventing toil.

Long lead time, low delivery frequency, and low code volume can reveal friction during the development process. In such scenarios, engineers are likely experiencing roadblocks and bottlenecks disrupting their development flow.

At the DevOps Enterprise Summit 2014, David Ashman, former Chief Architect at Blackboard, recalls how his engineering organization became less agile and stagnant due to mounting technical debt. Ashman's red flag was a significant change in the number of code commits.

[The codebase] is growing at such a pace that is becoming this enormous product with so much complexity, so much insurmountable debt that we were running into problems both in development and operations of significant failures in releases and problems with developers taking far too long for these products to get built out.

Such challenges can leave developers struggling to achieve their goals, fighting against the system, and potentially working longer hours to overcome it.

Teams should also watch for signs of high workloads and disruptive schedules. High meeting time can pull developers away from meaningful work and fragment their day, leading to dissatisfaction with daily work. Spending less time in flow during the workday and more time coding on nights and weekends puts teams at risk of burnout and poor work-life balance.

Operating above 100% of team capacity for too long—without breaks or downtime—can wear down even the most productive team. Code volume, measured by pull requests and commits, can be one approximation for workload.

Similar to other engineering metrics, context matters. It's important to understand teams and individuals in their day-to-day life to attain a clearer understanding of the situation. There is no single 'burnout' metric. Instead, teams should rely on several indicators of team frustration and pain.

How to prevent developer burnout

Avoiding burnout requires teams to reduce firefighting, hardship, and toil. The goal should be to alleviate deployment pain and enable the fast flow of work from code to production, as well as to create a culture of learning, psychological safety, and fairness.

It starts with improving the organization's DevOps practices. According to Accelerate:

Burnout can be prevented or reversed, and DevOps can help. Organizations can fix the conditions that lead to burnout by fostering a supportive work environment, by ensuring work is meaningful, and ensuring employees understand how their own work ties to strategic objectives.

Investments in DevOps strengthen the organization's developer experience, improving daily work. Over the long-term, better DevOps minimize several key risk factors for developer burnout.

To prevent burnout, teams should first embrace the principle of continuous improvement. Continuous improvement is a core idea in Lean methodology that advocates for incremental improvement in an organization's performance through continuous measuring, learning, and experimentation. It creates a culture that measures and improves daily work, identifying potential development pains and prioritizing their fixes.

Second, teams should create an environment that prioritizes psychological safety. They should provide engineers with the safety needed to experiment and learn from mistakes, instead of resorting to blame or finger pointing. Developers must be a part of the decision making process when it directly affects their work.

Third, teams must invest in the developer experience. Doing so requires teams to enable fast feedback, minimize thrash, and reduce fear.

In particular, organizations can reduce chronic stress by providing guardrails that improve the flow of work and remove fear and pain from deployments. Developers can quickly and confidently make changes to code when they have automated tests and environments, telemetry for performance visibility, loosely coupled architecture to isolate failures, and version control for fast rollbacks. Teams can also tackle technical debt on a recurring basis to avoid development stagnation and fear.

Can hybrid or remote work help prevent burnout?

Workplaces are quickly changing as the world grapples with a shift from office to remote or hybrid work. Such a seismic shift will likely change how teams identify and prevent burnout.

Remote work reduces time spent commuting and provides workers with greater control over their schedules. They benefit from more flexibility, which allows them to spend more time with family and friends or pursue activities outside of work.

Remote work can also lead to fewer distractions and more time spent in flow to work on meaningful tasks. Developers are interrupted less frequently by shoulder taps and open offices.

While remote and hybrid workplaces can remove certain stressors, they can also create new ones. Workers may face unfamiliar challenges, such as a lack of face time with coworkers and less rigid work-life boundaries. Without cultural changes to grapple with their new work environment, newly remote teams increase their risk for burnout.

Engineering teams switching to remote work can also face DevOps issues during their transition. They need to grapple with new requirements, particularly around hardware and team communication.

For a successful transition, teams should monitor for changes in the development process to ensure their tools and practices still work well in their new workplace. If not, they should adopt new ones that cater better to asynchronous communication and remote development.