Skip to main content
Smartonic

Burnout in tech workers: three structural mismatches that make software work uniquely prone

Burnout in tech workers: three structural mismatches that make software work uniquely prone
Sam OkonkwoWriter at Smartonic
4 sources7 min read
Tech workers burn out at high rates because software work has three structural mismatches with human recovery: backlogs that never complete, on-call rotations that erode autonomy, and framework churn that partially depreciates hard-won expertise every two years. Rest addresses only one of the three. The other two need shape changes at the job or organization level.

The claim in most tech-worker burnout articles runs something like this: developers work too hard, hours are too long, the pay is high but the demands are higher. That framing gets one thing right (the number is high) and one thing wrong (the reason). Nursing, teaching, ER medicine, and public defenders all clear the exhaustion threshold too, in most surveys, at rates that meet or beat software.

Tech workers burn out because software work is shaped, in three specific structural ways, to break the recovery mechanisms humans use to stay functional at work. Nursing and teaching exhaust people through workload. Software work does it through structure. The three shapes map onto Christina Maslach's three-axis model (exhaustion, cynicism, reduced accomplishment), which most burnout research since the 1980s runs on. For the full three-axis diagnostic, see our main piece on burnout recovery.

Understanding the shape is what makes the recovery interventions land. Rest and time off matter, but they don't address the shape. The shape is what most wellness content misses.

Tech work is shaped to burn people out in three specific ways

Start with the tech industry burnout statistics that get quoted. Developer surveys, from anonymous workplace apps to vendor reports, often find half or more of respondents saying they feel burned out. Those numbers overlap the exhaustion rates you'll find in nursing, K-12 teaching, and public defenders' offices. On exhaustion, tech is not the outlier.

The outlier is on something else. Three mismatches between how software work is structured and what a nervous system needs to recover between sprints. The mismatches are the backlog shape, the on-call shape, and the churn shape. Any one is manageable. Stack all three on a single job, at a company with a growth mandate, and burnout in software engineers stops being surprising.

Why does tech burnout get more attention than burnout in other high-exhaustion jobs? Partly because the pay is high enough that complaining reads as ungrateful, so people explain themselves at length. Partly because the industry documents itself. But mostly because the three mismatches are unusually good at hitting the second and third Maslach axes (cynicism, reduced accomplishment), not just the first.

Mismatch 1: the backlog never empties, so the nervous system never lands

In most jobs, a workday ends with something completable. A nurse finishes a shift and hands off. A teacher finishes a class period. Even a lawyer usually finishes a filing.

Software work almost never ends the same way. The backlog is designed not to. Every shipped feature generates two more tickets in its wake. Every "done" is provisional until the retro. The Jira board has more work on it Friday than it did Monday, every week, forever.

The never-completed structure matters more than the workload. People recover best when work has an end point. Something finishes, and the body downshifts. Occupational psychology calls this "psychological detachment," and it's one of the most consistent predictors of next-day recovery. Detachment is hard to pull off when the work has no boundary.

Developer burnout signs that trace to this mismatch: Sunday-evening dread, difficulty starting on Monday, a persistent sense that "I got nothing done" after a week of shipping code. Output can be normal. The subjective sense of accomplishment collapses. That's Maslach axis 3 (reduced personal accomplishment), driven by missing completion cues even when output is fine.

Mismatch 2: on-call takes away control over rest

Tech companies tend to treat on-call as a work-life-balance issue. It's more precisely an autonomy issue. On many teams, a week of on-call doesn't add many actual paged hours. Plenty of on-call weeks pass with few pages or none.

The mechanism that breaks people is different. It's the loss of control over rest. A person who could be paged at three in the morning doesn't sleep the same way as a person who can't. Sleep tends to get lighter, even on nights the pager stays quiet. They cancel plans that were three hours away from a laptop. They decline social invitations they would have accepted, because what if I get paged.

Self-determination theory work by Deci and Ryan has been showing this for decades: autonomy is one of three basic psychological needs, and when it's thwarted, burnout gets more likely. On-call erodes autonomy without necessarily adding workload. That's why paying extra for on-call, fair as it is, doesn't touch the actual problem. Pay addresses the wrong axis.

Founders get paged too, but they chose that trade-off and control their own rest. Salaried on-call engineers, by design, don't.

Mismatch 3: the framework churn means your last two years partially depreciated

Every couple of years, some meaningful portion of what a developer knew how to do gets partially devalued. The frontend framework of the year rotates. The infra stack the team standardized on is now legacy. The AI-assisted-coding shift since 2023 has moved faster than any language transition in the previous decade.

This is different from "you have to keep learning." Every profession keeps learning. What's different in tech is that the learning replaces rather than accumulates. A nurse who learned to place IVs in 2005 still places IVs the same way in 2026. A developer who went deep on AngularJS in 2014 watched the market value of that investment fade once the framework was rewritten from scratch.

The Maslach axis this hits is number 3 again (reduced personal accomplishment), but through a different mechanism than the backlog. Here the accomplishment is real, and then the ground shifts underneath it. In the 2024 Stack Overflow Developer Survey, technical debt was the top frustration at work for 63% of professional developers, and about a third named the complexity of their tech stack. Both are what constant churn leaves behind.

If the churn mismatch is real, mid-career engineers should feel it most. Juniors haven't had time to build the stack of expertise that gets partially depreciated. Seniors are watching a decade of accumulated pattern-matching lose some of its value every couple of years. The WHO's 2019 ICD-11 framing of burnout as occupational (not clinical) is worth remembering here: the mismatch is between a person and a job structure, not a person and their own resilience.

What actually moves the number, and what the wellness industry sells instead

Corporate wellness programs (meditation apps, mental-health days, resilience workshops) target the exhaustion axis and mostly leave the other two alone. Some large evaluations of workplace wellness programs have found little or no measurable wellbeing benefit from taking part. Rest is fine. It doesn't change the shape.

Interventions that actually move the number address the three mismatches specifically:

  • For the backlog mismatch: completed-work rituals. Weekly demos where finished work is marked as finished, not just closed in Jira. Definitions of done that treat "shipped" as terminal rather than provisional.
  • For the on-call mismatch: genuine follow-the-sun rotations, or off-call weeks that are actually off. No Slack, no monitoring dashboards, no "just in case" DMs from the manager. Half-measures don't work; the nervous system reads them as still-on-call.
  • For the churn mismatch: treating the depreciation as a compensation question rather than a personal-learning-obligation question. Some companies build paid learning time into role expectations. Others accept that mid-career engineers will do less new-framework work and more architecture-continuity work. Both address the axis.

None of these requires quitting tech. Two of them require the employer to change the shape of the job, which is why reviews of the research tend to find organization-level changes doing more than individual ones. The recovery is structural, closer to occupational than psychological. That's the part most tech-worker burnout content still gets backwards.

Then again, if a person has stayed in the shape long enough and the employer isn't going to change it, the recovery is going to happen somewhere else.

References
  • Maslach, C., & Jackson, S. E. (1981). The measurement of experienced burnout. Journal of Occupational Behavior, 2(2), 99-113.
  • World Health Organization. (2019, May 28). Burn-out an "occupational phenomenon": International Classification of Diseases. who.int.
  • Deci, E. L., & Ryan, R. M. (2000). The "what" and "why" of goal pursuits: Human needs and the self-determination of behavior. Psychological Inquiry, 11(4), 227-268.
  • Stack Overflow. (2024). 2024 Developer Survey: Professional Developers.

FAQ

Why are tech workers burning out at higher rates than other industries?
On exhaustion alone, tech sits in the same range as nursing, teaching, and ER medicine. The difference is the structure of the job. Perpetual backlogs, on-call rotations, and framework churn hit the second and third axes of Maslach's model (cynicism and reduced accomplishment), not just exhaustion. That's why software engineer burnout tends to be more persistent than pure-workload professions where a shift can end and the work stays completed.
What are the signs of developer burnout to watch for?
The most reliable developer burnout signs show up before productivity drops. Output often stays high while the internal signals crash. Watch for Sunday-evening dread, difficulty naming what was accomplished after a productive week, a slow shift in tone when talking about the job, and canceling plans in case of on-call pages. Sleep quality often degrades before hours worked change.
Does taking a sabbatical fix tech burnout?
Time off addresses the exhaustion axis and leaves the other two mostly untouched. For structural burnout in software engineers, a sabbatical without a change in the job shape usually returns the same numbers within weeks of coming back. Recovery that lasts tends to require a role change, a shift in on-call terms, or a company-level shape change. See our main piece on [burnout recovery](/blog/burnout-recovery) for the full framework.
Is burnout worse for senior engineers or junior engineers?
There's no clean data on this, but the framework-churn mismatch predicts that mid-career engineers should feel it more. Juniors haven't yet built a stack of expertise whose value gets partially depreciated every couple of years, while seniors watch a decade of pattern-matching lose ground each time the industry rotates.
What's the difference between tech burnout and normal work stress?
Ordinary stress rises and falls with workload and clears when the workload clears. Burnout doesn't clear with rest alone. It involves a slow drift in cynicism and a collapse in the sense of accomplishment, and those two axes stay elevated even when hours go down. If a two-week vacation didn't move the number, the picture is closer to burnout than to stress.
Explore more on Burnout