Laying the
groundworK for
a mentally healthy
remote team
The topic of mental health has been bubbling up in the tech sector for years now. Psychological safety is one of the big buzz words, and leaders have been eager for tips on preventing burnout and reducing work anxiety. These things matter both at the individual developer level and for the continuity and health of organizations as a whole. According to a survey by TELUS International, 80% of employees would consider quitting their current position for one that prioritized employees’ mental health.
Remote teams make the same considerations about individual well-being even more challenging. Work-from-home is inherently low-touch, which means leaders have fewer cues from which to assess their teams’ health. Remote employees are literally living in their office. Leaders need to be mindful of each engineer’s needs and be flexible in ways alien to a co-located environment.Here are some strategies for leaders who want to improve or create a digital environment that benefits their team members’—and thus the team’s—health and well-being.
SECTION ONE
The co-located environment runs on impromptu, in-person conversations. There’s a reason grabbing coffee is a euphemism for a casual meeting. It also exists within tangible boundaries: When someone walks out the front door at the end of the day, they cross a literal threshold into the world outside of work. That visual cue gives everyone tacit permission to call it a day.
Working from home is different in the obvious way, and that lack of physical, visible boundaries means leaders must be vigilant that work does not creep into their team members’ personal and family lives.
It’s up to leadership to write the rule book for how their team works, in a way that actually works for the people on it.
SECTION 1.1
Set remote boundaries and flexible schedules
Plenty of resources exist on how remote workers can set their own work-from-home boundaries with themselves, their families and their environments. Boundaries are critical. But it’s up to leadership to establish inter-team and inter-organizational boundaries that make work from home possible from the get-go. Such expectations set the standards for what team members and leaders can expect, and what falls out of bounds—both of which protect teams from at-home job creep.
Tech leader and author Patrick Kua thinks of leadership as gardening. “The exciting thing about being a leader is asking yourself what sort of garden, or what sort of culture, are you trying to cultivate?” he says. “It's really coming down to the things that you encourage or discourage, or you allow.”
Establish remote boundaries to keep developers charged up
AREAS THAT BENEFIT FROM CLEAR BOUNDARIES INCLUDE:
When can team members expect to be able to reach their teammates? And when should they expect their teammates to be away from work? Developers should feel comfortable to let an after-hours email (even—or especially—from leadership) wait until the following day without risking blowback.
Availability
Are team members expected to put in a certain amount of time each week? Or are they expected to reach certain benchmarks? Particularly in creative fields like software development, leaders who focus on outcomes and results rather than inputs and processes tend to see team members flourish. “We operate on trust,” writes Douglas Hanna, COO of Grafana Labs, about his almost fully remote workforce. “We track output, not hours. We set clear objectives and priorities and hold our team members accountable for delivery—but beyond that, everyone manages their own time.”
Input and output
Will developers be checking in daily or weekly? How often will leaders schedule 1:1s? How often do teams need stand-ups? Establishing routine expectations for standard touch-ins lets everyone work them into their schedule.
Communication cadence
Of course, boundaries are context-dependent. A developer whose job it is to respond to an after-hours crisis like a data breach has different expectations than other engineers, who don’t need (and shouldn’t be expected) to respond to odd-hours communication.The easy pitfall is to assume that because developers are working from home and likely accessible digitally, everyone should be available all the time. Leaders need to make clear that personal time and boundaries are both expected and healthy—a personal life distinct from work obligations helps employees recharge and do their best work.
On-call status
Remote teams generally empower individual engineers to create their own working schedule—to an extent. Lunch breaks don’t have to happen at noon, the work day can start at 8 or 11 just as easily as at 9, and if some engineers do their best work after midnight, they can.
The key is to make sure that individual preferences strengthen the team, rather than detract from it.
For instance, if a team works best with a weekly stand-up—and a given time works reasonably well in every team member’s time zone—then everyone needs to attend, even if it’s not their preferred time. Some teams create communication windows where everyone is logged in to Slack for the same two-hour window. Flexibility goes both ways, after all.
Working from home creates other realities that leaders need to consider when building flexibility into their teams. Childcare is often a big one, and increasingly, so is elder care. Empathetic leaders would try not to schedule stand-ups when developers are taking their kids to school.
By enabling reasonable flexibility and reducing unnecessary rigidity, leaders enable a culture of accountability and responsibility rather than obligation. This allows developers to contribute their best work—because they’re working when they can focus at their peak, rather than on someone else’s prescription.
Working with flexible schedules enables the team’s best production
The events that can precipitate a shift to remote work—such as, but not limited to, a global pandemic—already put employees on edge. Our brains did not evolve to equate change with security. And even when distributed work is the status quo, remote developers lack many of the interpersonal cues that co-located engineers get to ensure them that their jobs are safe and that they themselves are accepted members of the team.
For reasons such as these, psychological safety is critical for work-from-home to really work. Psychological safety is, in short, the freedom for creative workers to take creative risks without fear of repercussions from failure. Understanding pillars of psychological safety behooves any tech leader in any environment.
Here are some ways leaders can manifest psychological safety with particular relevance to remote work.
Actions speak louder than words—so leaders who want their developers to feel secure need to demonstrate exactly how they’re protecting the team. And the clearest ways to do that on an ongoing basis are advocating for the team’s needs and recognition within the greater organization, and defending the team from distractions and pressures that fall beyond their responsibilities.
When using the sword-and-shield approach to ensuring team well-being, though in a healthy organization with strong boundaries, leaders don’t need to be quite so militant as that label suggests.
Wielding both a sword and a shield secures the team
SECTION 1.2
Strengthen psychological safety
Ways that leaders can advocate for their teams include:
When can team members expect to be able to reach their teammates? And when should they expect their teammates to be away from work? Developers should feel comfortable to let an after-hours email (even—or especially—from leadership) wait until the following day without risking blowback.
Budget, manpower and other resources
When can team members expect to be able to reach their teammates? And when should they expect their teammates to be away from work? Developers should feel comfortable to let an after-hours email (even—or especially—from leadership) wait until the following day without risking blowback.
Flexibility
When can team members expect to be able to reach their teammates? And when should they expect their teammates to be away from work? Developers should feel comfortable to let an after-hours email (even—or especially—from leadership) wait until the following day without risking blowback.
Recognition
And leaders can defend the team in such ways as:
When teams in other disciplines need to make requests of an engineering team, you can establish yourself as the transmitter and receiver of all those communications. If teams are working in tandem, that’s one thing—but power dynamics come into play if, say, a product team lead makes a direct request from a developer. The engineering team lead has a broader perspective of team trajectories and bandwidth, and thus is best able to assess and assign any incoming requests.
Acting as the conduit for communications
This doesn’t mean shielding the team from negative feedback. Rather, you can assemble any incoming feedback and criticism, compile it in a way that’s actionable and educational for the team, and present it in a constructive environment at the right time. Insulating the team in this way helps prevent infighting and criticism-ambush.
Filtering feedback and criticism
If your boss’s boss tells you to jump, power dynamics are again at play. To ensure your own security, you’ll jump without first consulting your boss. Effective leaders can act as an intermediary between both specific higher-up figures, general company strategy and the development team. In a sense, leaders are translating the requests and pressures from outside the team into terms that make productive sense within the team.
Managing expectations from above
Although remote workers are isolated in space, they succeed when they are not left out of conversations or important knowledge. A thorough understanding of the company strategy and the way their work impacts the rest of the delivery chain offers developers a greater context and a sense of purpose.
Connecting development and strategy may become more challenging with distributed teams, particularly if certain pieces of development work are outsourced. “A team operating as only one link in the overall product delivery chain can have reduced visibility in the strategic or product direction,” Agile coach Dragana Hadzic says. “They need to be aware of how their tasks fit in the big picture.”
The responsibility for communicating this sense of purpose falls to you as a leader,both at the upper levels and on a managerial scale. Communicating this sense of purpose to teams requires more than articulating the company strategy. It’s also important to convey a strong understanding of how any particular team fits into the entire chain of a product’s development, from concept through to client use.
Context is really about communication and collaboration; two skills highlighted above. “Everyone in that setup needs to be aware that the connection between delivery and strategy is dynamic,” Dragana says. “There are usually a lot of underlying assumptions that need to be validated. The landscape needs to be frequently revisited, and everyone needs to be aware of what’s going on.”
Offering context bolsters the leaps the team can take
You can talk about empowering and protecting their teams until those proverbial cows come home—but their interactions need to bolster that sentiment. Otherwise, it has no meaning and no power.
Telling a team that they don’t have to reply to after-hours emails loses its force if you’re sending a bunch of after-hours emails (or worse, asking for them to reply—even as an exception). Telling a team that their away-from-work time is sacred gets undercut when your own Slack shows you online all weekend.
These signals contradict the team’s instructions. And that matters.
You, as a leader, need to implement these strategies for yourself too. Leading by example is perhaps the single most powerful way to ensure strong psychological safety for a remote team, where boundaries are already hazier than in a co-located setting.
SECTION 1.3
Practice what you preach
Leaders make mistakes. But not every leader owns them. Mirroring the accountability, curiosity and willingness to learn that a healthy team demonstrates both how to conduct that behavior, and that it’s acceptable within the team.
Own your mistakes
In addition, here are some practices you can to use to model the same vulnerability, trust, and balance you wish for your team.
Systems architect Nikola Milanovic has learned that the best way to own his mistakes is to address them candidly, with both his team and his clients alike. “I’m the first one who will openly say, ‘Hey, I made a mistake. I was wrong because of this, this or this,’” he says. “As a leader it’s really important that you are willing to work on yourself, and that you are willing to push yourself to always be better.”
Leaders spending their time combing through PR tickets or sitting in on mob coding sessions likely caused tension in the team even before factoring in the remote aspect. If this sounds like you, your intentions may have been sound, but this practice can lead to team members to feel distrusted or micromanaged. “There is really no need for engineering managers to be looking into the code base and keeping an eye on code reviews in order to understand the complexity of a project,” senior software engineering manager at Atlassian, Isabel Nyo writes on Medium. “Instead, if they believe that something is taking too long, they should look at other contributing factors such as technical debt, lack of skill and knowledge, a suboptimal process, and so on.”
Avoid the deep dive
This is not to be confused with taking an impromptu vacation during a high-pressure sprint. Rather, taking time off—in the form of well-scheduled vacations, a long weekend or even a couple hours for family or personal time—demonstrates to the rest of the team that mental health and a personal life are critical for tackling the challenges of software engineering. Taking time off offers another benefit, too—it provides you an opportunity to switch off and let go, giving the team full operative trust for that duration.
Take time off, even when you feel busy
It’s important to note that every piece of a team’s well-being is interconnected, and no piece can truly be isolated. This first section is foundational not only for a remote team’s transition to working from home, but to allow your team a streamlined remote work experience for the long haul.
Give your team what they need
Section Two »
Introduction
section One
section two
section Three