The engineering team I support is now fully remote—the third remote or hybrid-remote team I've managed over the last 6-ish years. When it's working it really feels like the future and when it's not... well, it's really not great for anyone. I'd like to share some tips and tricks for building a remote team that I've learned along the way.
Getting started
Before you hire anyone remotely, you need to make a plan. Like many tips in this essay, remote teams are much better off when you are explicit and follow through. In this case, that means making a plan for the makeup of your team. In addition to what skills you need to achieve the mission of the team, you must also consider whether you want to have a hybrid remote team (some people work in an office, others remote) or a fully remote team (everyone works remote usually in different locations).
You generally want to avoid having just one engineer who works remotely--they will almost certainly have a bad experience. If everyone is co-located together, the norms and processes will be centered around the group of people sitting together. The lone remote worker will be excluded in many significant ways--impromptu meetings and decisions, mentorship, awareness of what's going on. A simple rule of thumb, the defaults of the team need to start with the needs of remote team members. This tends to happen as soon as half or more of the team is remote.
Which brings us to hybrid-remote teams. It's possible to have a successful hybrid-remote team forever with some tradeoffs. Teams regularly talking about their norms and processes will start to foster practices that are more inclusive of the remote team members. Things like including video conference links in all meetings, documenting important decisions, etc. (more on this later). Since there is no longer just one remote engineer, the norms change rapidly and in a positive way for the whole team (generally, behaviors like writing things down and being thoughtful of meetings are net good for everyone). However, you need to be thoughtful about fostering social interactions between everyone lest you end up with perceived or real cliques.
Fully remote teams are ideal. When everyone is remote, everything is even and balanced. There is a natural tendency for things to center around the 'folks in HQ' even in a hybrid-remote team (an easy way to tell is when someone mentions a time and doesn't include a timezone, what timezone is it assumed to be?). The norms and processes can become significantly more async and coordination happens through written communication. On the management side, it also seems more fair (less tendency to spend more time talking/coaching the person who is easy to talk to in the office).
On timezones: It's really easy to underestimate the impact of managing a team across timezones. If you are overlapping for a very short amount of time there is tremendous pressure on communication and collaboration will take a hit--it's just takes too much effort so people don't. For a highly collaborative endeavor (like say writing software), having friction like this is a non-starter. Even in less extreme examples like three different timezones i.e. across the U.S.--scheduling a meeting has way more constraints than you think (lunch time, too early, too late in someone's day etc.)! I recommend no more than 3 hour time difference--more than that is a bit painful.
Hiring remote engineers
I generally recommend starting with more senior engineers, preferably ones with existing remote experience that are in timezonez within 3 hours of the furthest team member--especially if you are just starting the team. The combination of an early career engineer, being remote for the first time, in a different timezone makes things even harder to set them up for success. It's also good to be cautious of experienced engineers who are working fully remote for the first time. It can be difficult to make the adjustment and requires more attention and help (not to mention just being new to your team/organization/codebase which can be difficult enough!).
Earlier I mentioned that having a plan and following through are important. When it comes to hiring remote engineers, they really don't want to be part of some organizational experiment--they need commitment and you need to be credible. It's highly likely that if they worked remotely for a non-remote friendly organization they are wary of repeating a bad experience. That's where having a plan and being able to point to reasons why a remote engineer will be successful there are important. Of the many remote engineers I've talked to, you can really stand out from the crowd by having a thoughtful plan and pointing to aspects of your company culture that will make remote engineers successful (this is much harder if you work at an established company with no history of remotes). The good news is, that by doing all this you are opening up to a much wider pool of really good engineers.
Open up your horizons to new backgrounds: Chances are, you are not going to find the kinds of engineers you are used to hiring (e.g. FAANG companies if you are in the Bay Area). The real opportunity is in the different backgrounds that come from all the other geographic areas you can now hire from. For example, if you are in the US, there's a ton of great engineers that are going to have a CV filled with consultancies, industries you've never heard of, startups etc. I can say with confidence, some of the best engineers I've ever worked with were from non-traditional backgrounds whose CV would not make it past a resume screen at a FAANG company. You won't fully benefit from the remote hiring pool if you don't embrace diversity.
Resetting norms and processes
If you are about to transition to a hybrid remote team from a fully colocated team, it's important to get the process of resetting team norms as quickly as possible. To do that everyone needs to start building empathy for their future remote collegues.
Remote week
One way to kickstart building empathy is to have the entire team work remotely for one week. The ground rules are simple 1) work from the same place each day (no remote does not mean people are "working" from the beach!) 2) keep notes about your experience. After the week concludes, summarize everyone's notes and hold a retrospective.
A single week is seldom enough to get the full experience (I feel it takes a few months to really get it), however it will build awareness and, from my experience, get people excited. Consider some of the challenges and ideas that came up during the week and consider getting ahead of certain issues (e.g. calendering, working hours, documenting communication norms).
Maybe one of the biggest benefits of doing this is for your future remote workers. They will appreciate the team's effort in making an inclusive and welcoming environment.
Memos are actually awesome!
The 'memo' tends to conjure up visions of an early 90's Dilbertian office culture, but on remote teams (any variant) they are vital. Specifically, the practice of writing down an idea, exploring the problem, articulating solutions, and gathering feedback is uniquely suited to remote teams. Longer-form writing forces the writer to think through their idea which saves time for future readers. It's naturally asynchronous--it can be shared over email and read when you can (empowering the reader to schedule as opposed to a meeting) and it leaves an artifact that can be easily referenced later (try finding an important slack message days later). This lessens the importance of being 'in the room' and promotes a highly valuable skill--good writing!
Tea time
One of the disadvantages of remote teams is not getting enough social time. This often comes across as feelings of loneliness or a team not 'gelling'. There's much more friction to interact and so non-essential communication will default tonear zero. It's vital to foster interactions and although it sounds odd, literally schedule social time.
Tea time is an idea I borrowed from a collegue of mine. You schedule a standing calendar invite where the team hangs out over video conference (actually drinking tea not required). This is 'water cooler' time for folks to talk about whatever they want as long as it's not work. It's your job to 1) show up and 2) get each person talking. If you don't show up, it's hard to get the message that this is important and others won't attend either. If you don't get everyone talking, some teammates might feel excluded which will hurt the closeness of the team and eventually ownership.
Async standup
Standups are interesting in that they highlight so many of the challenges of remote teams in one place. It's very clear that your standup format needs to change e.g. you awkwardly crowd around someones desk to do a VC standup but neither side can hear and you feel bad for disturbing everyone else around you. It also quickly reveals where the center of gravity of the team is e.g. you have most folks sitting in a conference room together, maybe forgetting to include video conference information. It even reveals if you haven't established norms e.g. you've scheduled over a few people's lunch time in another timezone. So do standups still make sense?
I've found that the team and I still value a daily standup, but the format has changed considerably. An async standup is ideal for remote teams that operate across multiple timezones. I think standups are most valuable to do first thing when you come online—it helps focus your day and recognize blockers early. However, since people are coming online a different times there's a challenge to get the same kind of live discussion unless you hold a synchronous meeting.
I should note, that I don't think there is a perfect way to do async standups yet. While there are a few tools these days, I'm not fully convinced it's better.
Calendering
In general, people don't like it when meetings are scheduled outside of working hours and over lunch. For teams distributed across multiple timezones this presents a challenge. It's easy for team members to forget when someone's work hours are and when their lunch usually is. If you are using Google Calendar, you can set working hours which will send a message to anyone who schedules a meeting letting them know it's outside of working hours. It's also useful to have each team member make a recurring calendar invite that represents their lunch time. By pushing working hour knowledge into the tools you use, it's far easier to do the right thing. Next time someone tries to schedule a meeting across the team it will be more obvious what times are actually free. Team norms should also make it ok to decline meetings and set boundaries with co-workers.
By default, every meeting should include a video conferencing link. There are tools that can do this automatically via a browser extensions (such as Zoom). No one likes to be an afterthought and it saves a lot of time fumbling around and keeps meetings on time.
Meetings
When holding meetings, having a mix of people video conferencing and physically together can create imbalances which can inhibit inclusion. We've all been there before—the only person not in the room, the one that can barely hear, the one that's overlooked, and not part of the conversation. If you find your team in these situations, work with those leading meetings to check-in and prompt participants joining remotely. It's much harder to interject in a conversation naturally without someone's presence and body language. Be explicit and consistent about it otherwise people not in the room will tend to be excluded.
Even better, avoid having groups that are colocated entirely by forcing everyone to be on the video conference. This will level the playing field and make it easier considerate of the remote team. It feels silly at first—scattering throughout the office for a meeting—but I've met several teams that happily meet like this by default to great success.
Ad-hoc communication (e.g. Slack)
These days, just about everyone is using Slack. It's immediate, it's fun, and it fills the days with interuption. Messaging tools do a great job at making things more visible (it's easy to share, easy to pipe in other notifications), helping team unity (emoji, chatter), and real-time coordination (e.g. 'site is down omg!'). For remote teams, where communication and coordination are at a premium this can be very useful. However, it's just as important to set boundaries on Slack as it is to do on calendaring.
The baseline cost for anything you do with Slack is notifications. Sometimes it's just not worth the interruption or anxiety of unread messages. I find it useful to look for patterns of usage and figure out what use cases we rely on chat for. For instance, if you see technical design or project discussions only happening in Slack, push to move them to longer term artifacts (like a Google doc) otherwise decisions and context will be lost. Being diligent allows the team to reinforce norms and in the case above, make it easier for people to contribute who might not be immediately present (or the fastest to respond!).
Note taking
I really like the idea that team administration is owned by everyone. That includes things like scheduling meetings, offsites, and note taking. Taking good notes, sharing them, and making them easy to reference later is important for people to follow along and acquire the context they need to do their job. At a certain point, everyone can not attend every meeting. Chances are also good that people will take vacation or you might hire someone new so strong discipline around note taking can make getting people up to speed much more scalable. Building transparency into how you operate makes it much easier for remote teams.
Team meetings
There's a few meetings that I find are important enough to be recurringly scheduled and synchronous. The team needs to regularly talk about 1) the work and results and 2) the team itself. Usually that means some sort of planning/prioritization meeting and some sort of retrospective and time to talk about team challenges on a weekly or fortnightly cadence. An easy mistake growing distributed teams make is trying to force a synchronous daily meeting with everyone (sometimes even the whole company). Signs that it's not working is low engagement during meetings and low output (action items). The good news is, if you build in time to reflect on how things are going as a team, you'll be able to evolve the forums and norms that work for the team.
Email lists
Good email hygiene is also essential as the company grows. Setting up email lists such as Google Groups, provides an async written medium for others to follow along (e.g. read notes), contribute when they have time, and provide some artifacts along the way. New people getting up to speed on a new team or project can read through the archive and, if you are following what I mentioned about note taking, they will have a pretty complete view of what's happened.
A good starting place for a team is 1) a team notes email list 2) an archive (for cc'ing/bcc'ing any team related communication) and 3) a general team list where other folks in the company can reach you (your intra-company interface). When there are notes, send all the participants the notes in the 'to' line and cc your notes list. When there are team updates or announcements send it to the team list. Anything else team related (e.g. external user/partner conversation), bcc the archive. Now you have a system that reinforces transparency and everyone at the company benefits.
Be explicit about what's expected
Remote teams necessitate strong communication—management is no exception. You'll need to be explicit about your expectations of individuals and the team (you probably already are, but stay with me for a second). Several managers I've talked to that have transitioned to remote teams have mentioned how managing a remote team actually made them better managers. Having to think through exactly what you are seeing/expecting and communicating to remotes effectively reveals just how much managers rely on impromptu conversations, non-verbal communication, and presence.
Simple things like: If you need people to be available during a certain set of hours write it down and communicate it. If you expect people to work out of a regular office (home, co-working, etc) with good internet connection write it down and communicate it. It's nearly impossible to be effective by being a passive aggressive remote engineering manager :)
Promote self-care
Help the team support their individual needs and look out for one another. Mental health is a concern for remote team members that tend to isolate themselves which, from experience, is extremely easy to do. It's harder to notice the subtle queues like body language and expressions when you are primarily interacting over video conferencing and chat. Check-in, remind them to take care of themselves, and be generous.
A good example of this happened recently on our team. I got a ping on chat that one of the engineers seemed withdrawn in a recent meeting they had. After following up, they had a few things weighing them down both at work and in their personal life. I offered them to take a day off (not counting against vacation days) to step away. I would not have noticed on my own, but for the ping from one of their teammates.
Small things make a big difference. Having a routine in the morning is hugely useful. If you see someone looking/sounding groggy like they just rolled out of bed for a meeting, raise it as a concern. Not only are they being unfair with your (or the team's) time, but it can also be a sign of an unhealthy pattern which can devolve over time e.g. staying up too late, then sleeping in, performing worse at work, getting stressed, not sleeping, repeat.
What's still missing
There's many unsolved problems for remote teams (or at least things I couldn't figure out!), but here's a few that are top of mind. I would love to hear from you if you have some good ideas.
- There's still too much friction/ceremony for quick questions—something you might feel ok interupting someone who is taking a brief respite that could unblock you quickly. There's a few startups looking at this as a "remote presence" problem, but I'm not sure.
- Good whiteboarding solutions are not a thing for remote teams. In real life, we often center around a whiteboard to problem solve visualy. Video conferencing is not high enough fidelity to whiteboard on camera easily.
- Async standups - My team has iterated on it a few times finally settling on a written, async, slack channel and reminder to discuss at a set time. It's not quite enough signal and we still require some additional coordination points like project sync meetings.
- Hiring in all 50 US states - You will need to adhere to all labor laws in each state (and sometimes city/munincipality) which can be quite daunting and expensive. This adds friction to hiring and makes it easier to default to hiring someone in the traditional office.