For the last few years, I’ve been employed with Truly where I get to work with amazing people on amazing projects. Truly has always been a remote-friendly company, often with greater than 50% of employees as remote workers. But since the Covid-19 pandemic began, everyone in the company has gone remote. Prior to joining the Truly team, I worked for a company based in another state as a remote software developer. All-in-all, I’ve had almost 4 years of remote experience. So does remote software development work? Should you hire a remote employee? Can you be one? These questions have become all-the-more important as we enter 2021. I’d like to share a few principles I’ve learned over the last several years.
A Distributed Team
While not necessary, it helps significantly when most of the team is distributed. When you are the only remote developer, to the rest of the team you can very well be “out of sight, out of mind.” You miss a whole lot of communication, which always leaves you several steps behind.
So, a mostly-in-office team may be a struggle for a remote developer, but what about a distributed team? Like I mentioned before, Truly is a fully distributed team. We don’t require everyone to try to be on the same timezone page (for example, 8-5 in California does not mean 11-8 in Ohio)! This is great for work-life balance. Another bonus of a fully distributed team over a partially distributed team is that everyone will have their own microphone. This might sound minor, but when a room of people have to share a microphone, many things go unheard by the remote team. This isn’t the case with a fully distributed team. Generally speaking, probably the biggest benefit to a fully remote team is that it forces good communication, whether verbal or written.
Agile teams are very familiar with this, but I want to mention it because it’s increasingly important for remote developers. At Truly, we keep our standup short and focused, using it for two main purposes. The first is to synchronously communicate blockers, ask for help, offer help, or get quick feedback from the team. We currently use Status Hero to asynchronously report what we will be working on that day, which allows us to call out anything we will need to discuss synchronously in standup. The second purpose and task for standup is to review releases going out. This allows us to mention any concerns we have about a release and to coordinate them if necessary. This is not a prescriptive format for standups, but it works for us. You’ll need to determine what’s most effective for your team.
Async Communication Channel
If you were in an office, you would have opportunities to walk up to a co-worker and begin talking in real time. This can be both a benefit and a hindrance. While immediate real-time discussion is effective, it can interrupt and break the train of thought of the other person. And since remote developers don’t have this option anyway, we need another solution. An asynchronous, real-time communication tool, such as Slack, provides a helpful medium.
This kind of async-real-time communication allows us to chat without interrupting each other. Our team is courteous towards one another and does not expect an immediate response upon sending a message (remember time zone differences – lunch time, after hours, etc). It’s good to be responsive to others that need you, but it’s also good to be respectful of others’ time when you need them. The Truly team does this well! And when text communication isn’t enough, we can always quickly jump on a video call together.
When I’m given requirements, user stories, or mock-ups, I can pretty much hack away without too much dependence on others. Being explicit is helpful here. As a developer, be sure to ask for specifics where anything is unclear. Doing this upfront is ideal, but there may be things you don’t discover until you start the work. That’s ok. The key here is being able to work independently with the well-defined requirements.
We’re all social beings, but when you work remotely, socializing does not come easy. There are no “by the water cooler” conversations. But this kind of talk is important, because it reminds us that we’re working with real people, not to mention the fact that it improves productivity. So how can you have this kind of conversation with a distributed team?
One way the Truly engineering team has done it (maybe accidentally) is by our chit chat in the minutes before our regular rituals, such as standup. We will often take the first 5 minutes of the meeting for casual talk, which many times has left us laughing as we transition into the real reason we met. I would highly recommend you intentionally leave a gap before your real meeting starts for this kind of “water cooler” talk. Another way this kind of conversation has been facilitated organization-wide at Truly is via Donut. This tool gives us opportunities for non-work-related conversations during work hours, an “extended water cooler” discussion of sorts. One last thing I would suggest is to celebrate wins together. When we ship a feature, this is a great time to celebrate on Zoom over a company-expensed treat (DoorDashed lunch, coffee, ice cream, etc). Our team has enjoyed these kinds of celebrations.
After working at Truly for the last few years, I can still attest to the fact that we do distributed teams well (if Truly sounds like a place you’d like to work, check out the jobs page). While these principles are nowhere near comprehensive, I hope they provide some insight into our well-oiled remote team culture and help you with yours. So, does remote software development work? Yes. And many more companies are already discovering this during the Covid-19 pandemic. May your remote team thrive in 2021.
This is a revision of the original post here.