Burnout in a software company rarely starts with a big blow-up. It starts when your most reliable developer stops talking at stand-up. Their pull requests come in slower and with more bugs. At the retrospective they say "whatever". Two months later their resignation is on your desk, right in the middle of a fixed-deadline project. Let's look at what burnout is, how common it is among developers, and what the person running the company or the team can do about it.
What burnout is (and what it is not)
The World Health Organization included burn-out in the 11th revision of the International Classification of Diseases (ICD-11), not as a medical condition but as an occupational phenomenon. It defines it as a syndrome resulting from chronic workplace stress that has not been successfully managed, with three dimensions:
- exhaustion: a feeling of energy depletion,
- mental distance from the job: cynicism and a negative attitude towards one's work,
- reduced professional efficacy: the feeling of not getting anything done properly.
For a manager, the key word in that definition is workplace. WHO says explicitly that burn-out refers to the occupational context and should not be applied to other areas of life. So it is not a personal weakness; it is a consequence of how the work is set up. That is good news, because you can change how the work is set up.
How common burnout is among developers
In June 2021, Haystack Analytics commissioned a survey of software developers (fieldwork by the research company Survation). 83% of developers said they suffer from burnout at work, and 81% said their burnout had increased during the pandemic.
Gallup looked at employees in general. Of nearly 7,500 full-time employees, 23% feel burned out very often or always, and another 44% sometimes. What matters most for a business are the consequences: employees who often feel burned out are 63% more likely to take a sick day and 2.6 times as likely to be actively looking for another job.
In a software company, where losing a senior developer means months of hiring and onboarding a replacement, this is one of the most expensive problems you can have. It just never shows up as a single line in the books.
Where burnout comes from
When Haystack asked developers about the causes, they named high workload (47%), inefficient processes (31%) and unclear goals and targets (29%). None of these is a "personal problem". All three are management decisions.
Gallup arrived at a very similar list of five main causes:
- unfair treatment at work: people who strongly agree they are treated unfairly are 2.3 times more likely to have high burnout,
- unmanageable workload,
- lack of role clarity: only 60% of workers strongly agree they know what is expected of them,
- lack of communication and support from their manager,
- unreasonable time pressure.
Google's DORA research (the Accelerate State of DevOps Report 2024) adds a cause that is typical for software companies: unstable priorities. When what the team should work on keeps changing, DORA finds meaningful drops in productivity and substantial increases in burnout. The report notes that this effect is highly resistant to mitigation: neither strong leadership nor good documentation offsets it.
Why overtime does not help
The usual reaction to a late project is "we'll push hard this month". But Stanford economist John Pencavel, in a paper for IZA based on historical data from British munition workers in 1916, showed that output rises with hours only up to a threshold (around 48–49 hours a week) and the gains shrink quickly beyond it. Output at 70 hours a week differed little from output at 56 hours. And weeks without a Sunday off had about 10% lower output for the same number of hours.
These are factory data, not data from a development team, so don't carry the numbers over literally. The principle holds for knowledge work too, though: sustained overtime buys little extra output and is paid for with exhaustion, which is exactly what burnout grows from.
Signals to catch early
Burnout rarely announces itself. Using WHO's three dimensions, watch your team for:
- Exhaustion: someone works more hours and gets less done, stops taking holidays, replies to messages late at night.
- Distance and cynicism: they used to join architecture discussions and now stay silent. At the retrospective you hear "nothing is going to change anyway".
- Reduced efficacy: tasks drag on, more bugs and more rework come back from code review, estimates stop being accurate.
None of these signals proves anything on its own. That is why talking to people matters: regular 1:1s are where you learn about overload before you learn about it from a resignation letter.
What the head of a software company can do
Gallup's numbers on protective factors are worth remembering. Employees who feel supported by their manager are about 70% less likely to experience burnout on a regular basis. And those who have enough time to do their work are 70% less likely to experience high burnout.
That gives you a practical checklist:
- Plan by capacity, not by wishes. Fill a sprint only with what the team can really deliver, and take work out when new work comes in.
- Keep priorities stable. New requests go to the backlog, and their order is decided at planning, not on Tuesday afternoon after a call with the client.
- Write clear assignments. Every task with a goal and acceptance criteria; unclear goals are the third most common cause of burnout in the Haystack survey.
- Track hours worked for the sake of people, not control. When someone logs 55 hours a week for weeks on end, that is a reason for a conversation, not for praise.
- Remove pointless work. Inefficient processes, manual reports and repetitive routine wear people out and bore them.
- Talk to people regularly and ask about workload, not just about task status.
- Be fair about who gets the interesting work and who keeps putting out fires.
How mcptask.online helps
mcptask.online won't solve burnout for you; only good leadership can do that. But it gives you the data to lead with. You break a project down into Epic → Story → Task and rate tasks with scrum points, from which an hour estimate is calculated automatically, so you can see whether the sprint plan matches the team's capacity. Time is logged against specific tasks, manually or from commits that reference the task, and you can export timesheets to JSON, CSV or PDF. Overload becomes visible before it shows up in the team's mood.
Dependencies between tasks are recorded as real blocker links, so nobody wastes time on work that is waiting for someone else anyway, and task priorities are readable for everyone in one place.
And the routine work that wears people out and bores them can be picked up by an autonomous AI developer (the runner) on your own infrastructure. It takes a small, well-described task from the same queue, writes the code and tests, and opens a pull request; a human decides on merge and release. Your developers get to spend their time on the harder, more interesting problems.
Want to keep your team's workload under control? Sign up for mcptask.online – the first 30 days are free, no credit card required.
Sources
- Burn-out an "occupational phenomenon": International Classification of Diseases, World Health Organization, 2019
- 83% of Developers Suffer From Burnout, Haystack Analytics Study Finds, Haystack Analytics, 2021
- Employee Burnout, Part 1: The 5 Main Causes, Ben Wigert, Sangeeta Agrawal, Gallup, 2018
- Accelerate State of DevOps Report 2024, DORA (Google Cloud)
- The Productivity of Working Hours, John Pencavel, IZA Discussion Paper No. 8129, 2014