How to avoid burnout in remote engineers

Working remotely may not seem like the sort of environment where burnout thrives, but it is. Learn about ways to avoid common pitfalls and lead a more balanced work life.

Remote work has remained a popular option for many software engineers since the COVID-19 pandemic. As found in a 2022 survey by Terminal, four out of five software engineers want to work remotely. However, one of the largest threats of remote environments is burnout, with half of workers admitting to being affected by this sort of exhaustion in a global survey by Microsoft in 2022.

Left unchecked, burnout can cause sick days, decreased job performance, and increased attrition levels. The World Health Organization describes burnout as a condition characterized by:

• feelings of energy depletion or exhaustion;
• increased mental distance from one’s job and feelings of negativism or cynicism related to one’s job; and
• reduced professional efficacy.

Despite its prevalence in the tech field’s discourse, spotting burnout and building a supportive environment for remote engineers can be tough. To combat this problem effectively, we must prioritize remote worker well-being.

In-office norms don’t work in remote settings 

During the first COVID-19 lockdown, people held more meetings to increase their sense of certainty and productivity. Harvard Business School (HBS) researchers found that this wasn’t the case, however, with meeting attendee numbers decreasing during lockdown only to substantially increase again after the lockdown ended. The research also revealed that workers found remote meetings tiring and hindered software development. To balance this, they turned to writing code during these virtual meetings or, if that wasn’t an option, worked outside of office hours to catch up on their tasks.

In-office work culture typically involves synchronous work, where people talk and work together at the same time. While this is fine when everyone is in the same room, it can be tough when everyone is remote. Collaborating with peers in an open office is nothing like remote work. Having to constantly maintain face in front of a computer camera can, and has, for many, resulted in meeting fatigue. Moreover, discussing a software issue with a colleague in-person is vastly different from receiving endless pings on Slack (or another instant messaging app), which can quickly become overwhelmingly distracting.

All of the aforementioned can negatively impact an engineer’s workload, and this sort of poorly managed workplace stress can lead to burnout.

Choosing between sync or async

In the 1990s, software development became more agile, culminating in the signing of the Agile Manifesto in 2001, which emphasizes the importance of valuing individuals and interactions over processes and tools. Studies have shown that collaborative programming, in particular, can improve software quality, with synchronous collaboration yielding better results in the realm of software development.

However, the question remains: how can we effectively manage software development in a remote setting? In a 2005 study about multitasking and interruptions, Gloria Mark, a Chancellor’s professor in the Department of Informatics at the University of California, Irvine, distinguished between peripheral work (tasks that individuals are not accountable for) and central work (tasks for which they are accountable). When peripheral work is spread throughout the day, it can be difficult to make time for central work, much like trying to fit rocks, pebbles, and sand into a jar; if we start with putting sand into the jar, we will not have room for rocks or pebbles. But if we put rocks and pebbles first, we will have enough space for sand, too. By prioritizing central tasks, it becomes easier to fit in peripheral tasks as well. 

Flexible, asynchronous (async) workflows allow individuals to plan their time as they see fit, reducing the need for back-to-back meetings, juggling multiple tasks, and working overtime. When managed well, it also reduces the number of switches between peripheral and central work, which can take an average of 23 minutes and 15 seconds per switch (according to Mark’s study).

Central and peripheral work 

In order to distinguish central work from peripheral work, we can group software engineering activities by response and immediacy. The following matrix shows an example of the classification, which may differ between organizations.

The first quadrant is for activities that need little to no response and are not urgent (we can tackle them later). The second quadrant is for those that need a response but not immediately (we can respond later). The third quadrant is for tasks that need little to no response but are urgent (we should get to it soon). The fourth quadrant is for tasks that need an immediate response (response is a top priority). Here are examples of suitable media for each of the groups.

Software development demands a high level of collaboration, which is why it shows up in the quadrant with a high need for immediate response. We work synchronously in this quadrant unless the risks outweigh the benefits.

To maintain well-being and prevent burnout, it’s important to recognize the signs of stress when working synchronously. According to Janice Litvin, author of the Banish Burnout Toolkit, being aware of your physical, mental, and emotional limits and recognizing your unique stress indicators can help. On a more general basis, you may notice symptoms of stress manifesting as avoiding work or becoming easily irritated.

To avoid burnout, Litvin suggests taking breaks and thinking before committing to tasks when working synchronously. If this doesn’t work, engineers can consider working asynchronously, but with caution.

Async engineering builds on async workflow, where software developers work together but at different times. This may include analyzing software, designing software architecture, and pair programming. When working asynchronously, shared documents or drawing boards can be used to collaborate and leave comments, while version control software, such as Git, can be used to exchange code and provide feedback.

Async pair programming

Pair programming is a method in which two programmers work together at the same workstation, with one writing code while the other provides feedback. In async pair programming, the two programmers work on the same codebase but at different times instead of in real-time.

One approach to async pair programming involves taking turns. One engineer will work on the code first, committing changes to the codebase, while the other engineer then gives feedback on those changes, making their own alterations at a later time. Here, any modifications should be kept small, requiring feedback at least once a day.

Another approach is to split the codebase into different areas, with each engineer working on their chosen area and reviewing each other’s changes. Again, it’s important to keep revisions small, supported by daily feedback. This approach can help create a modular software design that is easier to maintain.

To benefit from constant questioning when writing code solo, engineers can think out loud, engage in rubber duck debugging, talk to an inanimate object like a rubber duck, or use AI-powered code completion suggestion tools, such as Intellicode or GitHub Copilot.

During the code review process, it’s crucial to write helpful, yet respectful, messages. For example, you may achieve this by using conventions such as Conventional Comments or Arlo’s Commit Notation. It’s important to be mindful that not everyone follows Crocker’s rules and that you should be kind and professional in all communication.

Recognizing your team’s work in a remote setting

Try to leave at least one positive comment for every code review. In Conventional Comments, for instance, there is an interesting label called “praise” that highlights high-quality work. 

Recognizing people’s work is essential for preventing burnout in remote engineering, as per a global study by Gallup. The study found that employees are 90% less likely to report being burned out at work if they are recognized for their efforts.

It’s important to acknowledge great work regularly, both in and outside of the code review process. But the onus to celebrate high performance doesn’t fall solely on the shoulders of managers and leaders, peers should do so as well. 

Always be mindful of what is recognized and ensure that it does not promote unsustainable work practices such as working overtime or over the weekend. If an engineer has to work unsustainably, managers and leaders should apologize instead of publicly praising the sacrifice, which can set unrealistic expectations for others and worsen the prevalence of burnout.