Burnout by profession
Software Engineer Burnout: Signs, Causes, Fixes
On-call, shifting priorities and layoff anxiety wear engineers down fast. What causes software engineer burnout, and what to change first inside the job.
From the Realign Burnout Report 2026
93% of software engineers in our data have experienced burnout (n=114)
Source: The Realign Burnout Report 2026, self-reported by adults exploring a career change.
The pager went off again at 2 a.m., and by the time you fixed it you had forty minutes before your first standup. Somewhere between the last reorg and the new tickets that arrived without deleting the old ones, figuring out priorities yourself became your actual job.
Software engineer burnout does not usually come from writing code. It comes from everything wrapped around the code: requirements that shift mid-sprint, on-call weeks that never fully end, and a low hum of worry about whether your team survives the next round of cuts.
Software engineer burnout comes mainly from unclear or shifting priorities, on-call load that interrupts rest, constant context switching between tickets and meetings, and layoff anxiety. In our data, 70% of engineers who burned out cite unclear or excessive expectations, more than any other cause we measured. Fixes usually start with scope and on-call, not a new framework.
What drives software engineer burnout
- Unclear or shifting priorities. A sprint plan that changes twice before Friday means nothing you finish this week counts as done.
- On-call that never fully ends. Even a light on-call week keeps part of your attention reserved, which blocks rest.
- Constant context switching. Code review, an incident, a design doc, and a standup competing for the same morning fragments focus into nothing.
- Layoff anxiety. Watching headcount shrink around you changes how you work even when your own job is stable, because stable stops feeling like a fact you can rely on. It also makes it harder to say no to extra scope, which feeds the first problem on this list.
In Realign’s own data, 70% of software engineers who have burned out point to unclear or excessive job expectations as a cause, the single highest reason they named, ahead of workload itself. See the full breakdown by job.
Warning signs to check before you assume it’s just a hard sprint
- Dread that starts on Sunday night, unrelated to any specific ticket
- Opening your laptop, then closing it again without starting anything
- Sarcasm or checked-out silence in code review or planning that was not there before
- Shipping work you know is not your best, just to close the ticket
- Checking Slack during on-call weeks you are not even on
- A flat feeling about wins that used to matter: a launch, a fix, positive feedback
If this sits alongside hopelessness most days, or thoughts of harming yourself, that goes beyond what changing jobs or teams can fix. Talk to a doctor or a mental health professional. In the US, you can call or text 988 anytime.
Fixing it inside your current job
Most engineers jump to “I need a new job” before trying changes that take a fraction of the time.
| Fix | What it addresses | Ask for |
|---|---|---|
| Renegotiate scope | Unclear, always-shifting priorities | A written, ranked list of what “done” means this sprint |
| Change on-call rotation | Interrupted rest, always-on worry | A longer rotation, a backup, or fewer off-hours pages |
| Move teams internally | A specific manager, codebase, or team culture | A lateral move before you assume the whole company is the problem |
A scoped ask like “can we agree on the top three things for this sprint, in order” gets a faster yes than “I need less to do.” Most managers can act on a specific request about priority order or on-call load far more easily than on a general complaint about stress.
Layoff anxiety: what’s in your control
Watching headcount shrink around you is unsettling even when your own role looks stable, and no amount of extra hours reliably changes a decision made above your manager’s head. A few things do help, even if they do not remove the worry entirely:
- Ask your manager directly what the team’s priorities are for the next two quarters, rather than guessing from rumors. A clear answer, even an uncertain one stated plainly, is easier to plan around than silence.
- Keep your resume and a short list of your last year’s concrete contributions current, not as a sign you are leaving, but so a bad quarter does not also mean scrambling to remember what you shipped.
- Separate the anxiety itself from the workload. Working later does not insure your job, and it does add to the exhaustion that makes burnout worse regardless of what happens with layoffs.
If the anxiety sits with you most days and starts affecting sleep, appetite, or your ability to function outside work, that is worth raising with a doctor or therapist, not just managing alone.
When a different team or company helps, and when it doesn’t
Moving fixes burnout when the cause was specific to where you were: a chaotic manager, a legacy codebase nobody wants to touch, a broken on-call rotation, or a team that never wrote anything down. It does not fix burnout that comes from unclear expectations everywhere you have worked, or from the always-on culture of software work in general, because that follows you to the next job too, no matter how good the interview process made the team sound.
Before you switch teams or companies, ask whether this feeling has shown up in more than one role that looked different on paper. If it has, a lateral move alone will probably not hold, and it is worth naming that pattern to yourself before you spend months on another job search.
Adjacent roles: what they trade, not just what they fix
Some engineers who are done with the day-to-day pace move toward adjacent roles instead of leaving tech entirely. Each one trades one set of demands for a different one, so name what you are trying to get away from, the pager, the ambiguity, or the pace of shipping, before you pick a direction:
- Product manager. Trades deep technical ownership for cross-team influence and constant stakeholder management, its own kind of always-on.
- Solutions engineer. Trades pure building for client-facing problem-solving; less on-call, more travel and presenting.
- Developer relations. Trades a fixed sprint cadence for writing, speaking, and community work; less on-call, more public visibility and less deep-focus time.
- Engineering management. Trades individual output for other people’s problems; it removes some on-call pressure and adds performance reviews, staffing, and layoff conversations of your own.
None of these are automatically less demanding. Engineering management in particular can make burnout worse if you take it to escape the pager without wanting the work of managing people itself. Talk to someone already doing the role before you move, since the day-to-day is usually different from how it looks from the outside.
Where to start
If you are not sure whether this is one bad sprint or a bigger pattern, the free Burnout Check takes about four minutes and gives you a score and the likely causes behind it. If you already know you want to explore a different team, an adjacent role, or a move out of engineering entirely, a coach can help you test that direction before you act on it. Realign matches you with a coach through a short quiz, and you can see what coaching for software engineers looks like here.
Questions people ask
What percentage of software engineers experience burnout?
In Realign's own data, 93% of software engineers who answered had experienced burnout, with unclear or excessive expectations as the single most cited cause, ahead of workload itself. That sample is people exploring a career change, not a random slice of engineers, so treat it as a signal about who reaches out for help rather than a rate across the whole profession.
Is it burnout, or is my job just badly managed?
Often both, and the distinction matters less than it seems. Unclear priorities and a manager who will not commit to what matters this sprint are a management problem, but living inside that for months is what turns frustration into burnout. Fixing the management problem, through a scoped ask or a team change, is usually also the fix for the burnout.
Will switching to a different tech company fix burnout?
Sometimes, if the cause was specific to your team, your manager, or a chaotic codebase. It usually does not fix burnout caused by unclear expectations or an always-on culture in general, since those follow you to the next company. Check whether the same feeling showed up in a prior role before assuming a move alone will hold.
Should I become a manager to escape the on-call rotation?
Not for that reason alone. Moving into engineering management removes some on-call pressure but adds performance reviews, staffing decisions, and your own exposure to layoff conversations. It can work well if you want to manage people, and poorly if you are mainly trying to escape the pager.
What roles use engineering skills without the same burnout pattern?
Product management, solutions engineering, and developer relations all draw on technical background without the same on-call load, though each trades it for something else: more meetings, more travel, or more public visibility. None of them are automatically easier, so weigh what you are trading, not just what you are escaping.
This article is general career guidance, not medical advice. Burnout is not a medical diagnosis. If you feel persistently low, hopeless or unwell, talk to a doctor or mental health professional. In a crisis in the US, call or text 988.