How to spot developer burnout in a remote workplace 

TL;DR

1: Normalize talk about mental health
2: Have regular 121 check ins
3: Be data-driven
4: Take a mental health first aid course

Normalize talk about mental health

According to Stack Overflow’s 2020 developer survey, 15% of developers identified as having a mental health issue. It’s recognised that many people may not feel comfortable admitting to having issues with their mental health, or even be actively aware of them. This is due to a perceived stigma and lack of awareness of mental health in the workplace.

So, if people aren’t comfortable speaking about their mental health at work, how can we spot when developers are likely to burnout? Talk about it.

One of the biggest things we can do to reduce burnout in the developer community is to lead the conversation. Talk about how you’re feeling in sprint retrospectives, voice feelings of burnout or of increased stress. In our experience this serves as a domino effect, the more we talk about these things in the open, the more other developers feel comfortable doing the same. That only benefits us all, ensuring a more transparent workplace means we can do things to make it a happier workplace.


Have regular 121 check ins

Working remotely has a wide array of known benefits, but there is less opportunity for natural one to one communication with colleagues. That can soon be remedied, it just takes a little effort.

Book in regular one to one check ins with all your direct team members. If you have five team members and do so once a month at 30 mins, that’s only two and a half hours in a month.

Speak openly about how you’re both finding work, talking around things you’re enjoying but also things you’re struggling with. It’s unfortunately normal for developers to feel uncomfortable opening up about feeling at risk of burnout in retrospectives in front of a crowd, but it can be far easier to do so in a private one to one setting with fellow developers as peers.

A top tip from a mental health workshop we recently attended; don’t just ask “how are you?” once. Follow the question up with a secondary “are you sure?”. People will nearly always reply with a generic “yes fine” or similar the first time, but asking twice and showing you really care about your colleague can give them the space to open up that little bit more.

Reflect on your approach to work as a team

Ultimately a poor working environment is often the cause of burnout. But how do we know if the working environment is causing burnout, beyond gut instinct?

Adadot has a unique wellbeing dashboard built through consultation with leading wellbeing experts. This provides actual data taken through a range of integrations to understand both team level and individual working patterns that can help identify when developers are liable to suffer from burnout in a data-driven way.

• Long hours
  

This provides daily data on how much a developer is exceeding their working hours. Consistently working long hours is a classic cause of burn out, so track this graph as a team to ensure your working patterns are sustainable

• Fragmentation
  
  Context switching is exhausting, and another leading cause of developer burnout. This diagram provides data that shows how much context switching you’re doing through four dimensions:
  
  • People – how many people are you talking to in a week
  • Channels – how many Slack channels are you splitting attention between
  • Repos – how many repositories are you working across
  • Languages – how many coding languages are you flipping between
    
    
• Out of hours communication
  
  This graphic goes hand in hand with long hours. However, sometimes we might only actively work for say 20 minutes outside of work, but that 20 minutes is spread over the whole evening through quick one minute Slack messages.
  
  This isn’t allowing developers to switch off as they are effectively still ‘plugged in’ to work. Keeping out of hours communication to a minimum is key in reducing burn out.
  
• Focus time
  
  Writing code requires dedicated deep work time without interruptions. A great graphical representation of this is ‘Tendril Theory’:
  
  
  Source: https://eisforerin.com/2015/08/10/tendril-theory/#:~:text=Autism%2C%20Neurodiversity,to%20me%20all%20at%20once.
  
  This comic strip was first written in the context of autistic people, but can be relevant to neurotypical people too, particularly when their work requires dedicated focus time.
  
  The Adadot focus time dashboard graphic allows developers to track when they are getting focus time. Equally, teams of developers or a Scrum Master might want to leverage this data at a team level, checking the Adadot graphic to understand if there are too many interruptions to focus time throughout a given day, and identify when these are in the hope of reducing burnout and increasing general wellbeing.
  
  
• Time to review pickup
  
  This Adadot dashboard metric serves as a great proxy for understanding how much support developers are receiving from peers. The time between asking for a review and actually getting a colleague’s help with that review can prove to be very frustrating if it is a needlessly lengthy period of time.
  
  Studies show that a lack of support from peers is a key contributor to burnout, so making use of this data is a great way to spot potential developer burnout and deal with it by refocusing the team on driving up this metric.
  
  
• Upskilling
  
  The monotony of a repetitive and production line like work day can contribute to developer burnout. If developers come to work and write in the same coding language on the same types of projects all day, every day, it’s burn out waiting to happen.
  
  This Adadot metric helps to start the conversation around the amount developers are upskilling by quantifying how much of an individual or team’s time is spent on using languages beyond their ‘main’ language. Focusing on driving this metric upwards can be really beneficial to reducing burnout, as long as it doesn’t contribute to significant fragmentation.

Using the above metrics together can provide a powerful and tangible way of spotting burnout in the developer community, particularly in a remote setting where poor mental health can go unseen. 

Elect mental health first aiders

Having an office first aider has been a known concept for many years now, but increasingly we’re seeing the electing of work mental health first aiders. This is particularly valuable for development teams that work in a remote environment.

Ask your work about yourself or the wider development team going on a mental health first aider course, and consider electing mental health first aiders who are on the lookout for their colleagues burning out or struggling with mental health.

MHFA offers some accessible online and in-person courses, take a look today.

Over to you
We’ve provided you with a number of ways to spot developer burnout in a remote workplace, but that’s only half the job. Some actions to take now:

1: Sign up for Adadot to start seeing both your own and your team level metrics to understand the data behind your team’s current wellbeing.

2: Go to a mental health first aider course.

3: Start a conversation about burnout in your next team meeting.

4: Book in regular one to one conversations with your development colleagues.

Once you’ve identified that development team members are at risk of burnout, talk as a team about what you can change to improve the situation, then track how things change in the coming month. Change starts here.