Blogs

Using Git Signals to Identify Burnout

Julian Colina
June 25, 2020

"1 in every 4 engineers say they’re 'often or very often' burned out by work."

Nearly every engineer runs into burnout. We do our best to minimize it but - the reality is we can't predict everything.

In this article we'll be discussing how to quickly identify when your team may be burnt out so you can mitigate it before it's too late.

Common Ways to Identify Burnout

Most teams today use a few strategies to identify burnout. Some common ones are:

  1. 1-on-1s - Announce Blockers
  2. Shoulder Tapping - Frequent Progress Updates

Common Pitfalls

While these strategies can be effective, they often allow burnout to go undetected because they rely on engineers self-reporting issues.

But as engineers, we often:

  1. Don't Realize We Need Help
  2. Don't Ask for Help
  3. Feel Proud of taking on more work

You end up with unresolved issues, burnout, and overworked team.

"Burnout goes unnoticed until it's already too late."

The 'New' Approach - GitHub Signals

It's not all bad news. Luckily, there are signals that can help you identify when your team may be burning out. So we've put together quick list of signals you can use to identify burnout before it's too late.

3 Signals to Identify Burnout Using GitHub

  1. High Workload
  2. Unsustainable Working Patterns
  3. Idle Development or Review

1. High Workload

How to identify: Keep a pulse on Open Pull Requests throughout the Sprint. If you notice your team creating more Pull Requests than they can typically handle, it can signal a larger issue. Generally you should stay within your average throughput. Consistently outside your average can lead to overwork burnout.

2. Unsustainable Working Patterns

How to identify: Keep a pulse on when developer activity is high*.* If you notice your team making consistent changes in off-hours or weekends, it may signal they are overworking. The most common causes are 'hero syndrome', too much assigned work or unhealthy working habits.

3. Idle Development or Review

How to identify: Keep a pulse on each Pull Request Status. If you notice a Pull Request consistently getting stuck in Development or Review, it can signal a larger issue. Compare this to your team's average to see if an engineer is consistently stuck.

Note: Use historical data found in Github to identify your team's Average Time Spent in Development and Review.

Great, where do I get this data?

The good news is you already have it and it's sitting in your Github account. If you want to start using this data, the obvious starting place is the Github API. They have a robust REST API that allows you to query everything from pull requests to commits.

If you don't have time to build your own home grown solution, then you can try Haystack and get Github Signals like these in your inbox every morning.

Haystack helps engineering leaders identify burnout and trends. Instead of guessing if you're improving, or constantly bothering your team for progress updates, simply use Haystack to get alerts in your inbox every morning. Plus a dashboard to track improvements over time.

Try it for free

Julian Colina
CEO & Cofounder of Haystack.

Our latest news

Discover our latest articles, feature releases, and more!

Ready to get started?

Start Free Trial