According to the latest statistics, about 40% of developers work partially remotely, and a further 12% are full-time remote developers. The remote revolution is here, and if you want to get code written, you should be prepared to build yourself a remote team. At CodeClouds, we work extensively with distributed teams and remote developers, and we’ve learned a thing or three about how to put the perfect team together. The three pillars of building a remote team are communication, organisation, and motivation. Let’s break that down:
The Critical Split
It’s important to divide communication into two columns: synchronous and asynchronous. Synchronous communication is Zoom, Skype, phone calls, face-to-face meetings; asynchronous communication is Slack, e-mail, Trello. One is more direct, the other is more convenient. It’s not a distinction you generally need to make in an office. But with remote work (particularly if your developers are in other time zones) it’s critical to understand because synchronous communication is so much harder to organise. In an office you can just tap someone on the shoulder for an impromptu talk, but the same thing for a remote developer involves a string of e-mails, waiting for them to see them, then waiting for them to reply. You’re going to need to rely a lot more on asynchronous communication with your remote team. You should schedule regular video calls (standard is twice-weekly, though it’ll vary depending on you), and have a protocol for quickly scheduling emergency calls.
Use Your Tools
The only reason remote work has taken off is because of the communications revolution of the last two decades, and yet so many teams fail to take advantage of it—you have hundreds of options at your disposal to help coordinate your team, so use them! Slack, Zoom, Trello, Github, Google Drive—each one of these is another arrow in your quiver.
One trap a lot of managers fall into is assuming it’s only software you need, but here’s something that often gets forgotten: microphones. If I started to count the amount of remote meeting time lost to bad microphones, I’d be here until the sun went supernova. Time is money, and bad mics are cutting into your bottom line. Provide good headsets to remote developers as a perk—it’ll save you money in the long run, and everybody loves free stuff. Good cameras are also important, but consider this: would you rather work with a voice with no face, or a face with no voice?
Another hardware factor is the developer’s internet connection. Most devs will have something fairly solid and stable but you want to make sure they know how important it is or—like with a bad microphone—you’re going to spend half the meeting repeating yourself.
Use Your Tools (pt II)
In a way, clear communication is organisation. Every person on staff (including you!) needs to write in a way that is accurate, direct, and easy to understand. From a more traditional organisational standpoint, if you’ve missed kanban and Agile development, that’s your first look-in. Digital kanban boards are a godsend, and Agile scrums provide a structured synchronous meeting schedule.
Every Time Zone has a great set of pro tools that’ll help you sort out scheduling. If you’re using Slack, Spacetime is a great little bot that’ll do the same job. Slack is great because it knows the timezone everybody is working in and has a number of functions built around that. For example, it’ll do a warning popup on @channel pings, telling the user how many people are sleeping.
We’ll go into time zone issues in more detail later, but try to find a single static reference point for coordination. I recommend UTC, because, well:
Welcome … to the Time Zone!
One of the greatest organisational challenges in building your remote team is coordinating across time zones. We’ve talked about time zone challenges before but the short version is this: it’s only a problem if you make it one. Or, it’s only a problem if you act like you’re in a regular office and refuse to plan around it.
Think about how much time you spend waiting in an average workday. Now imagine this: you need to pass a piece of copywriting onto a manager. If you were in the same timezone you’d send it, then sit there twiddling your thumbs until they respond. But what if they’re halfway around the world? Well, you send it out at the end of the day, then it’s done when you arrive back at work in the morning. It’s taking the same amount of time to get done, but it’s taking up less of your work hours. If you plan around timezones, your team can be remarkably efficient, because all that dead time spent waiting around disappears.
It also means you’re able to have somebody at work 24/7—if a customer needs urgent help, you’ve always got somebody on the team able to talk to them. You’re able to respond to challenges more quickly, and that’s a powerful tool.
It does take work: you need to reorganise your entire workflow around everybody’s timezones and it can often be difficult to create a schedule that works for everybody. If you can sort it out, though, you’ll find it becomes a huge asset.
Getting that Feedback
One issue with remote development is that it’s often hard for staff to tell how well they’re doing—with less frequent face time with management and their colleagues, they can become rudderless. They might feel their work doesn’t matter, or they might be doing something critically wrong and have no idea. Either way, it’s a recipe for disaster. It’s important to not just talk to them, but to let them know whether their work is doing what it’s meant to.
Having a formal evaluation system is important. Though it will be obvious from their output whether or not a staff member is pulling their weight, they can often miss it themselves: there’s a whole slate of cognitive biases that mean people aren’t great at judging their own capability.
Which isn’t to say people are stupid, it’s to say that people are people. We’re a social species, and we rely on each other for understanding and validation. We work more effectively when our work feels like it’s doing something, and we understand the nature and value of our work better if there’s a comprehensible and direct response to it.
Overtesting can be a problem, but having annual or biannual employee peer assessments is very important, as is some way for an employee to request an assessment. Think back to your first day on basically any new job—even with an excellent onboarding, you can often find yourself asking am I doing this right? Is this what they want? It’s a part of the process, and building in systems that respond to it are important in helping your staff know when they’re doing work (or otherwise!)
A lot of talk about feedback focusses excessively on negative feedback. While it’s important to let staff know when they’re doing something wrong, it’s good to also let them know when they’re doing something right—discouraging negative behaviour will reduce negative behaviour, but—on its own—it won’t make good things happen.
The Human Factor
Remote development is lonely. That’s part of the reason co-working spaces have sprung up everywhere, and why remote developers congregate on digital nomad forums or other social groups—working from home means never leaving the house, and it can drive people crazy. When remote work was first discussed, managers thought the problem would be stopping staff from slacking off and misusing company time—it turns out remote staff are more productive, and the real danger of not coming into the office is that, well … they don’t talk to people.
There are a couple of ways to deal with this, and for the sake of consistency we’re going to divide them into synchronous and asynchronous methods. The three pillars work together, and the way to help your staff feel less isolated and more like they’re part of the team is to communicate with them. You communicate asynchronously with them by giving them digital spaces to blow off steam with their colleagues—Slack channels, Discord servers and group chats. Places where they can drop it and out without worrying about time-pressure. I know group chat isn’t strictly asynchronous, but stick with me here. They need somewhere informal to share funny gifs with their colleagues, or talk about their day, or just generally interact with other human beings. It’s simple, daily, low-effort communication.
Synchronous communication—in this context—is staff picnics, movie nights, friendly office meetups and online games. Anything where they are there directly, in the moment, either in-person or via a screen. I’ve heard of offices that run Wednesday evening games of Dungeons & Dragons using the Roll20 application, or played Jackbox Games via Google Hangouts, or played something a bit more old school like Mafia/Werewolf. Talk to them about what they want to do: if you work in tech, I guarantee you’ve got somebody on staff who has run games like this before. These events shouldn’t be mandatory (mandatory fun isn’t fun), but do your best to facilitate them and make sure staff are aware of them. They help keep your staff sane, and also build social bonds within your teams.
20 years ago, we thought we understood remote development: it was something that would make employees happier but less productive. When management were away, the mice would play. There’s a 1995 episode of The Simpsons where Homer gets a remote job at the power plant and—in the absence of supervision—outsources it to a toy bird.
The reality is the opposite of that: remote workers are extremely productive, but tend to be lonelier, and have a harder time separating their work lives and home lives. Remote work isn’t without joy or freedom, but it’s hardly developers slacking off to watch TV. Managing remote teams is less about making them work than maintaining solid communications, while keeping them sane and making them feel like part of a team. If you’re up to that challenge, then you have a unique and powerful opportunity—you can hire better staff while cutting costs and increasing wages. You have access to the largest employee pool in the world, and you can hire incredible people who you never would’ve even heard of otherwise.
Somewhere—in a remote Canadian log cabin or a bustling Thai city, maybe at home with their kids or unable to easily move around because of disability, maybe living on a boat anchored off the Australian coast or moving from city-to-city while sleeping on couches—the best developer in the world is looking for work. If you’re willing to reach out to them, then you’re going to go far.
At CodeClouds, we have over 300 developers in-house. If you’re looking to hire a remote developer but don’t want a freelancer, we’re the right choice.