Signs of burnout in software engineers

This guide is for education. It isn't a diagnostic tool or medical advice. If you're worried about your own health, talk to a clinician. If you or someone you know is in crisis, call or text 988 in the US, or contact local emergency services.

What burnout actually is

The World Health Organization describes burnout as a syndrome "resulting from chronic workplace stress that has not been successfully managed." The WHO classes it as an occupational phenomenon rather than a medical condition, and it applies specifically to work.

It has three dimensions, and they're a useful way to organize what you're seeing:

1. Energy depletion or exhaustion
2. Increased mental distance from your job, or negativity or cynicism about it
3. Reduced professional efficacy

The examples below are our translation into engineering terms. They're observations, not a checklist from the WHO, and no single item means someone is burned out.

1. Exhaustion

This is more than being tired after a hard sprint. The clue is that normal rest stops working.

• Waking up tired, including on the first day of a vacation
• Dreading on-call weeks well before they start
• Rereading the same diff or log line several times
• Feeling flattened by a context switch that used to be routine
• Getting sick more often, or noticing headaches and poor sleep

2. Cynicism and distance

This one is easy to miss on engineering teams, because dark humor is part of the culture. Pay attention to a change from someone's normal.

• Jokes about the roadmap that have stopped sounding like jokes
• "Nothing's going to change anyway" in retros, or silence where there used to be opinions
• Doing exactly what the ticket says and no longer caring whether it's the right thing
• Losing interest in craft, in mentoring or in the product
• Cameras off and a withdrawal from the team channel

3. Reduced efficacy

This is often the most frightening dimension for engineers, because so much of their identity rests on being good at the work.

• Small mistakes in areas where you'd normally be careful
• Tasks taking far longer than you'd have estimated a year ago
• Over-checking work, or struggling to make decisions you'd once have made easily
• A growing belief that you've lost your edge, or never had it

Hard week, or something more?

Everyone has rough patches. Burnout is more likely when several of these have lasted for weeks, when they cover more than one of the three dimensions and when time off no longer restores you. It can also overlap with anxiety or depression, which can look similar and deserve proper attention. Sorting that out is a job for a clinician, not a blog post.

Signs at team level

Managers and People teams often can't see inside someone's head, but they can see patterns over time:

• Your strongest contributors have gone quiet
• More sick days around on-call shifts or release dates
• People no longer volunteer for anything optional
• Defensive code reviews and short tempers in incident channels
• Regretted resignations with a vague explanation

These matter commercially too. In Gallup's research with nearly 7,500 full-time employees, burned-out employees were 63% more likely to take a sick day and 2.6 times as likely to be actively seeking a different job. That study covered workers in general, not developers specifically. For a developer view, press coverage of Stack Overflow's 2026 survey of more than 30,000 developers reports that only about 22% described themselves as happy at work, and that burnout or tech fatigue was the top reason given by those who called themselves complacent.

What causes it, and where to start

Gallup found five factors most strongly tied to burnout: unfair treatment at work, unmanageable workload, lack of role clarity, lack of communication and support from a manager, and unreasonable time pressure. Notice that none of these are about personal resilience.

If it's you: tell someone, whether that's a manager you trust, a friend or a clinician. Protect sleep first. Find out what your company's mental health benefit covers. Try one small recovery practice, such as the two-minute reset, and be realistic about what it can do.

If it's someone on your team: have a private conversation and look at the workload honestly. Here's how to start it.

If it's the whole team: fix what you can in the system first, then give people skills for what remains. That second part is what our workshops are for.