Burnout Might Happen Because Your Boss Doesn’t Know Your True Value

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.

One Response to “Burnout Might Happen Because Your Boss Doesn’t Know Your True Value”

  1. James Igoe

    Although the culture might be hard to change, to recognize when processes are running well, nowadays one should recognize the need to promote one’s own good work. This might be hard for some, but if you don’t, and it’s hurting you, you must learn how, get someone to do it for you, or leave. Although I can’t say I’m great at self-promotion, there still might be functional ways to self-promote, without feeling like it is false or bragging.

    One way would be to develop metrics on your systems. If you regularly publish performance and usage data for your systems, that could be an opportunity, say if all of your clients are high-level managers, users make heavy demands on your system, or the system response time is admirable. Another might be to sound off on one’s code quality, say if the review system found your code was scored higher than other team member’s code, and it would not have to take the form of a brag. Asking to take time to turn your A- code to A, or to reduce its already low code smells numbers. There are likely others, but it seems the world has changed, for good or for bad, such that it requires we market ourselves.