While there have been a few all-remote tech companies for years, places like GitLab and Buffer that have been all-remote from the start are, in my experience, the exception, not the rule. In spite of the reputation engineering has for being a job that can be done from anywhere, nearly all my personal experience as an engineer — and that of my friends and colleagues — has been at butt-in-seat office jobs.
Moving suddenly to an all-remote work environment is just as challenging for engineering teams as it is for other teams. Happily, we generally have robust collaboration tools already in place, from Slack to code repositories, that make remote collaboration possible. We can still get our jobs done remotely — and most people probably have some experience collaborating remotely in some context. Because even while most jobs were still office-based, many engineers did have the flexibility to work remotely occasionally.
However, we’ve found that the biggest pitfalls to working remotely aren’t necessarily just about managing technology, but rather about how to build teams, mentor junior engineers and communicate ideas correctly when we can’t talk face-to-face.
Asking and answering
When we were in the office, it was easy for members of my team to ask questions. In fact, I spent about half of an average day working with junior team members to make sure they had the resources they needed to be productive, listening to them bounce around ideas and in general helping ensure we were all on the same page. Yes, this took time — but it is a core part of my role as an engineering leader. Now that we’re working remotely, the number of these conversations I’m having with junior team members has plummeted.
It’s just easier to ask someone a quick question when you’re both in an office, and the person can clearly see that you are not in a meeting, for example. There’s more of a barrier to asking a question when it requires typing out a Slack message. The barrier to sending an email is even higher. The result is people reach out far less.
One way to address this is to ensure the entire team knows that you welcome ‘interruptions’ at any time — but also to keep a regular schedule and be clear about when you’ll be able to respond immediately and when you won’t. Actively encourage team members to ask questions and let them know that doing so is not really an interruption, it is part of your job.
When we’re all in the office together, most people have an easier time figuring out things like:
- What is the best time and method to ask this question or share this idea?
- Is my co-worker / boss having a bad day? What emotional state are my team members in?
- How urgent is this request from a colleague?
When we move all our communications to Zoom and Slack, all of these things become harder to understand. Was your boss short with you because she’s about to dial in to a meeting, because she just got off the phone with an unhappy customer, because she was up all night working on an incident or because she thinks your idea is bad? It’s entirely possible to miss that context even when everyone shares an office, but it’s much more likely to happen when everyone is remote. In an all-remote environment, you also miss out on the ability to easily ask a colleague to explain an interaction that you’re not sure how to interpret.
Even figuring out the best way to communicate with team members is more challenging, especially when it’s a question or idea that you would usually have posed in person. Effective remote communication requires teams to make everything explicit, from their emotional state to when they’re available to how anxious a particular project makes them.
Writing the docs
Documentation has long been neglected among engineering teams, but in an all-remote environment appropriate, comprehensive and up-to-date documentation is very important. Since asking casual questions is more difficult and clarifying ambiguities is more cumbersome on Slack than in person, having a clear document that’s stored in an easily-accessible spot is more important in an all-remote working environment than in an office.
This means ensuring the service catalogue and run books are up to date as well as taking the time to fully document project specs and proposals in writing. Using a format like Google Docs makes it much easier to collaborate and track changes than trying to sort through five Slack threads from a week ago.
When people stop asking as many questions, that means they’re trying to figure it out on their own. In principle, that’s not a bad thing, but the organization needs to provide robust documentation to make it as easy as possible for team members to get accurate information on their own instead of just flying blind.
Over the long-term…
It seems likely that for at least some companies, the shift to an all-remote — or at least mostly remote — workforce could be long-term or permanent. That presents an entirely new set of challenges related to mentorship and career advancement. Research suggests that remote workers are less likely to advance in their careers than those who work in the office. Companies that want to encourage remote work long-term have to be extremely conscious about how they create an organizational culture that fosters true collaboration and team building while also allowing remote workers to move their career forward.
There are some parts of the remote transition that effx can make easier. The effx dashboard makes it easy to see how teams and individuals prefer to be contacted, so you don’t waste time sending someone an email when they prefer Slack. At the same time, effx also helps keep documentation accessible and up to date by reminding teams to link documents and making those links available in one place.