Burnout is real, and there are several reasons why it happens. Sometimes it’s the job itself; sometimes it’s the hours worked. But maybe there’s a different reason altogether, and it really has nothing to do with you. In the most recent Dice Salary Survey, 35 percent of tech pros say they feel “very burnt out.” The same percentage point to their workload as reason they’re burnt out, while 28 percent feel unchallenged at work. 26 percent claim a poor work-life balance is causing stress, while 18 percent say “friction” with their boss is cause for concern. The highest percentage (36 percent) say a lack of recognition is to blame for their burnout – but what does that actually mean? Steve Burton, DevOps Evangelist at Harness, says the problem may lie with the demands your boss makes of your time. “Historically, the need to be available to address problems with deployed code has forced developers to be ‘on call’ day and night,” he says. “With modern software development tools, that’s no longer the case, yet it’s still common to find developer job descriptions that require frequent night and weekend availability.” He points to these demands as the reason many DevOps jobs last about two years (though we’ve seen metrics that suggest more general tech jobs at major companies last about as long). A Paysa study shows that, among the largest tech companies, tech pros tended to stay at Facebook the longest (2.02 years on average). Meanwhile, a Blind study shows tech pros at Credit Karma feel burnout far more than those at other companies, with Netflix having the most content employee base. (A separate Blind study echoes our findings: burnout occurs most often because the workload tech pros have is too heavy.) Tech pros like to keep things calm at work, but ‘boring’ doesn’t always earn you recognition. An app or service that hums along and has nearly constant uptime doesn’t show your value, and that could be an indirect reason for burnout. “Businesses must re-evaluate what they ask of their developers and break the habit of prioritizing them only when trouble arises,” notes Burton. He advocates for a ground-up restructuring of how developers are incentivized. “In addition to creating new metrics that measure the impact – rather than volume – of developer output, companies should redesign their pay structures so compensation aligns with business outcomes. They must also cultivate a culture in which developers are rewarded when things go right.” But let’s be real for a minute: that’s probably not going to happen. It’s true much of your job is keeping problems from happening, and you may only find yourself in the spotlight when addressing a huge crisis; that 99 percent uptime may not earn you kudos. If you’re suddenly saddled with the responsibility of a system outage, your burnout begins. Burton isn’t wrong, and we’d love to see companies prioritize your ability to keep fires from starting rather than how often you put them out. But maybe you should do that for them: Rather than let the chips fall where they may when your review comes around, track your incremental wins. What was the service's uptime? How many lines of code did you trim in that last "bug fixes and performance improvements" app update (which made the code easier to maintain)? Did implementing that new payment provider ahead of schedule lead to more transactions? These are things your boss probably doesn’t track, but your day-to-day performance is a big deal nonetheless. So when review time comes around, don’t settle for the standard-issue rubber stamp treatment if you feel you’re doing a great job being boring. Instead, dig deep with your small wins, and walk out of the meeting room confident your boss knows you're awesome. That's a good way to avoid burnout, as well.