Time to Call Developer Burnout What It Is: A Failure of Leadership

Developers seem to have it all. Working at the vanguard of transformation, they’re valued and venerated – but they’re also a uniquely vulnerable bunch.

Developers fill a demanding role in the IT industry, and burnout is common. They are simultaneously masters of technology and perennial apprentices; never far from being overworked, and always subject to unreasonable demands and often-unachievable targets. Their specialist nature makes it difficult to delegate and, being closer to hand than, say, the teams building hardware, they’re treated as a highly available and flexible resource. As a result, a developer’s time and effort can seem expendable by comparison.

As a leader of developers and a developer myself, I’ve seen the burnout we can experience first-hand. And as a leader of developers, I want to make it clear – developer burnout is a leadership problem.

Without leadership’s support and protection, these issues can quickly pile up to leave developers dead-ended on dreary projects that drive them to the edge. And as your hard-to-find talent gets up and walks out the door (and perhaps even the industry), the costs are high for the companies concerned.

Managers are the gatekeepers of the elements that can lead to developer burnout. They assign the work people do and establish the incentives they have to do it; managers influence and shape the culture in which developers work. So when a developer burns out, their leader has failed them. It’s leadership’s job to recognize the signs of burnout early on, and to intervene and stave it off at all costs.

If you’re a leader in technology, these blunt statements may concern you, or even make you feel defensive. But instead of focusing on yourself, think about your team. Here’s how you can recognize developer burnout and stop it from spreading through your team.

If you’re a leader in technology, these blunt statements may concern you, or even make you feel defensive. But instead of focusing on yourself, think about your team.

What causes developer burnout?

It’s not always long hours that are to blame for developer burnout. They don’t help, sure, but it’s the slow build-up of multiple dissatisfactions – big and small – that creates the resentment associated with classic burnout.

These dissatisfactions tend to have their roots in a lack of ownership, a lack of control or empowerment, or a lack of recognition for an individual’s contribution.

High-risk scenarios for burnout might include extended periods of high intensity work where the wins – i.e., shipping code – are few and far between. Maintaining legacy code is another typical example. The developer working on legacy code is hardly ever the person that built it in the first place – so they don’t ownit. Now they’re stuck endlessly fixing bugs while knowing that what it really needs is rewriting – a decision they’re not empowered to make or influence. And the work is fairly low value, making recognition unlikely on the ground.

Developer burnout can also arise from a lack of confidence in the product team’s understanding of customer requirements,  the lack of control a developer may have over his or her schedule, or a lack of input into decisions that impact the developer. These are all fertile grounds for the growth of resentment.

I mentioned above that shipping code is a win that keeps developers happy. However, it’s important to remember there are exceptions to this idea. If developers are spending time writing and shipping code for the wrong feature, or a feature that no one uses, they’re likely to be just as uninspired as if they hadn’t shipped code at all.

Another scenario to watch out for: It’s stressful if sales, marketing and executive leadership are free to jump all over a developer’s time. Similarly, if they can’t make architectural recommendations or aren’t involved in high-level decision making, your developers are likely ripe for symptoms of burnout.

The three types of burnt-out developers – and the personality types to watch out for

It’s important to stress that burnout can and does happen to anyone. However, I’ve found that the workaholic, deep-diving personality types are more prone to burnout than others. These people are super curious and always want to over deliver. When they’re fit and firing, they’re an asset to any team.

But that curiosity can easily divert the workaholic developer’s focus from what’s important right now. When that happens, you’ll see them juggling four of five things at a time, until they’re regularly putting in 60-hour weeks to stay caught up. These developers don’t need micromanaging, but they do need a manager who’s alert to this scenario and can help them prioritize and remain focused.

When burnout does strike, I’ve generally seen one of three types of burnt-out developers emerge: the angry developer, the withdrawn developer or the rudderless developer.

The angry developer is standoffish, doesn’t take feedback well and becomes argumentative or non-collaborative. The withdrawn developer stops showing up to meetings, or doesn’t contribute to the ones they do attend. The withdrawn developer suddenly isn’t easy to reach on email or Slack anymore, and their code commits become less frequent, super small or lacking in detail. Then there’s the rudderless developer, who is prone to rabbit-holing on small tasks and taking far longer than necessary to get things done while refusing offers of help even as unfinished tasks pile up around them.

Preventing burnout is better, easier and cheaper than curing it

Burnout might seem sudden but it never just comes out of nowhere. There are always behavior changes that signal that someone is at risk of becoming angry, withdrawn or rudderless. Leadership’s challenge is to create both opportunities for themselves to spot these signs, and the space for developers to air concerns or voice opinions long before they become grievances.

Regular and purposeful one-on-one meetings are a vital anti-burnout tool. More than mere facetime with the boss, these sessions must be focused on understanding what developers want from their career so that you can proactively architect that for them. Leaders need to build trust by actioning the outcomes from these meetings, steering developers to the work they want, and encouraging them to undertake training that interests them.

In the background, leaders need to be closely monitoring workloads. They also need to bring variety to the developer team by moving people around. And leaders need to remember to  support the personal and professional interests of individuals as much as possible. Whatever short-term challenges these may cause, they pale in comparison to the morale- and productivity-sapping consequences of having a burned-out team.

When burnout does happen and you’re forced to intervene, then it’s important to come prepared with options. If you’re noticing a behavior change then it’s likely too late to say, “It looks like you’re having a hard time. Tell me about it.” Think instead  about actions you can take instead: Can you move them off a troublesome project? Can you dial back their workload, have them take some time off and limit their hours when they return?

The burnout buck stops with leadership

The benefits of maintaining developer motivation are so painfully obvious that I hesitate to mention them. If you have a seasoned team that knows your stack and knows your systems — a team that’s happy, competent and willing to do the work — then you're going to ship product faster. You’re going to be more successful.

On the other hand, the risks of burnout are serious for organizations and their leaders. Customer and user dissatisfaction will follow fairly quickly as quality drops and missed releases begin to mount. If important development resources aren’t addressing problems in a methodical way, performance will suffer and it will impact wider morale. Bad vibes from one individual can quickly spread through an organization or a team, poisoning the culture and impacting recruitment and retention.

Developers might not help themselves sometimes, taking on too much based on a strong confidence in their abilities and a natural drive to problem solve. But the job of management is to harness the good aspects of this instinct while filtering out the bad. They can do that by baking into the culture measures that prioritize variety, provide meaningful feedback and empower people to contribute every day.

And they should, because the burnout buck always stops with leadership.

Join the Conversation: Find Solve on Twitter and LinkedIn, or follow along via RSS.

Stay on top of what's next in technology

Learn about tech trends, innovations and how technologists are working today.