Warning signals from your team to detect developer burnout

Sometimes a cry for help isn’t a cry at all. For some developers in need, it’s more of a whisper, easily drowned out by the noise of production. For others, it’s complete silence.

In the early stages of burnout, your devs may still be managing their workloads, despite feeling depleted. In fact, they may show no obvious signs that they’re feeling stressed. By the time you notice there’s a problem, it may already be too late to reverse. 

The point is, it’s difficult to recognize when your developers need support, especially for remote teams. And it can be even harder for them to ask for it. But the warning signals are there —  if you know what to look for.

1. Pull requests take a long time

Your team opened a new pull request weeks ago, and the changes still haven’t been merged. You want to speed things up, so you take time during your 1:1s to stress the need for faster PRs — missing a possible warning signal from your team.

Asking your devs to work faster assumes that they weren’t already working at full capacity. In reality, sluggish PRs could be a sign that your devs have too much on their plates. Or maybe the bottlenecks lie within your process and not with your people.

Instead of zeroing in on the devs responsible for the PRs, try zooming out and looking at it from a big-picture perspective. Look for not only the pull requests that took a long time but also the reasons for the delays. Is your team juggling too many PRs at once? Did they get stuck in review?

By increasing visibility into your PR timelines, you can identify the real blockages behind the delays. More importantly, you can better manage PR velocity for your team, helping minimize their risk for burnout.

Start with a 10,000-foot view of your PR workflows. It’ll make it easier to spot bottlenecks and potential velocity risks. From there, you can zoom into the details armed with greater context around your delays. It helps to have a tool that can pull in all your PRs and visualize the data. 

Teams using Uplevel’s PR Workflow can access a high-level timeline view of their pull request activity. This interactive chart makes it easy to identify PRs in review, waiting on review, released, merged, and other status updates. Want to zoom into the details? Dev teams can use the PR Workflow to drill into each status update for a more complete picture, with filters to quickly find what they’re looking for.

2. Items carry over into the next sprint

Maybe your dev team is knocking out pull requests faster than ever. But what about the rest of your Jira issues? Is your team getting everything done? Does the progress match your projections?

If not, don’t blame your devs. Look into why they’re struggling to deliver the scoped work. If you’ve hired good people and you trust them to do their work, there’s likely another reason your projections are off. Much like the first warning signal above, sprint carryover could be a sign that your devs are overloaded. But it could also be a sign of too many changes to the project plan. If you’re adding lots of mid-sprint tasks and not adjusting scope, there could be an impact on delivery — and your devs’ happiness. 

Some sprint carryover is expected, and it might even be a good thing — it can mean your team shifted priorities to cover more important tasks. But if the problem gets worse, and your completion percentage keeps getting lower and lower, it could be a sign of a larger issue. 

Instead of waiting for retros to diagnose problems, consider taking a more proactive approach. With Uplevel, dev teams can manage both their sprint health and progress in one place to quickly see what’s happening mid sprint. Sprint Health Scores and “Projected Done” insights help you identify at-risk projects and the potential for carryover while there is still time to make adjustments.

Work with your team to better understand what’s happening mid sprint. Compare progress to previous sprints to determine how much work you can expect to complete. Just remember to loop your devs into planning conversations early to make sure expectations are aligned.

3. They’re proud of how busy they are

We hear it all the time from devs. They spend the workday wrapped up in meetings and responding to messages, so they use their personal time at night to focus on actual work. Many wear it as a badge of honor, but that badge gets heavy after a while. Your job as a manager is to help them better balance the weight. 

Dev team success depends on two factors: your project health and people health. It’s hard to find continued success without both. You could be putting out feature after feature, but if your devs are completely miserable, you’re building on borrowed time.

Project health is relatively easy to measure, looking at delivery, velocity, PRs, and other metrics. Your People Health, on the other hand, is harder to quantify. How do you measure burnout risk? 

Start by looking at the true blockers of people’s time:

• Interruptions – Are your devs constantly responding to Slack or Teams messages?
• Context Switching – Do they jump back and forth between projects?
• “Always On” behavior – Are your devs working too much overtime?
• Meeting overload – Are meetings taking your devs away from other priorities?

These factors take away from your team’s Deep Work time and have a proven connection to burnout. If Deep Work continues to decrease for several weeks in a row, your devs may start feeling the early symptoms. If left unchecked, the problem could get worse, resulting in delivery challenges. 

Meeting overload is an especially impactful blocker. As such, it’s important to analyze your meeting health for improvement opportunities. Are you having too many meetings? Are they being poorly scheduled? Maybe you have breaks between meetings that are either too long or too short. Aim for at least two-hour blocks for Deep Work, scheduling meetings consecutively (when possible) to avoid dead time in between.

Schedule a demo to see how Uplevel makes it easy for dev teams to identify and act on burnout risk. (Spoiler: it’s through a combination of project and people health metrics, together in one tool.)