It’s 2019, and remote development is a reality of our industry. More and more developers are opting to work off-site. It has many advantages, but also its own unique set of difficulties. We’ve got a lot of experience working with remote developers and distributed teams, and we’d like to share our insight into the issues to help you make the right hiring decision for your company.
Why remote development?
Despite a lot of early concerns that remote developers would be lazy and unproductive, the data supports the opposite conclusion—that remote developers are not just happier, they actually work harder. There are a lot of competing theories as to why, but regardless of the reason, the numbers don’t lie: you get more work out of remote developers.
They’re also cheaper, even though you pay them the same! Consider relocation costs, office space, beans for the coffee machine—having somebody in your office isn’t free. It’s also cheaper for the developer! They save on transport, they save on food (home cooking!), and they often work from somewhere with a lower cost of living.
Remote developers have higher retention and job satisfaction rates, saving you the slow, expensive and difficult process of bringing new staff on. Happier people also work harder, so you know you’re getting more out of them.
There are a lot of talented developers for whom coming into an office just isn’t an option. Some of the best developers in the world are single mothers with young children, or have serious mobility issues, or simply live thousands of miles away from the places where the jobs are. By being willing to hire remotely, you have a lot more choice and you have the ability to engage with developers who you couldn’t hire otherwise.
Okay, why not?
Remote work fundamentally shifts the balance of power between management and development. That’s not necessarily a bad thing, but it requires managers to develop a new skillset and it requires developers to be organised, self-motivated, and good communicators. They need to be what’s been called a “manager of one”—somebody capable of taking on the additional job of managing their own work while being a productive part of a team.
A remote developer also needs to be a skilled remote collaborator: they need to be a Git ninja with great communication skills. They need to be able to make a meeting in a timezone 8000 miles away and be as involved and productive as though they were there in person.
Really, a remote developer needs to be good. All developers need to be good, but a remote developer needs to be especially good. The bars for trust and skill are both set higher. If somebody is the right candidate to work remotely, they’re wonderful; if they’re the wrong candidate, it can be a disaster.
Remote developers are harder to integrate into your team. With no office water cooler or equivalent, they’re often isolated and don’t form the same kind of close friendships with their colleagues as they might otherwise. It’s not impossible, it’s just more difficult.
So what do I do?
We’ll go over the hiring process in detail below, but it needs to be significantly modified to account for how remote work functions.
- Proper onboard is absolutely critical for remote developers. Because it’s harder to supervise them, you need to properly integrate them with your team, and establish your company culture in their mind.
- As a manager, you need to be very clear about roles, duties and expectations. You create the framework that they operate inside. There’s a degree of flexibility within that, but deadlines are deadlines and quality standards are quality standards.
- Get as much real time with them as possible. Sometimes “as much as possible” will be once a year or even no time at all, but if you can get them to come along to a company picnic at least once, you’ll have a better idea of who they are and you’ll also give them an opportunity to socialise and build bonds with the rest of the team. A remote developer who comes in once a week is significantly better than one who comes in once a year.
- Make sure to keep them as fully in the loop as you can—remote work has more room for communications breakdown and errors in general, and you need to ensure every day that you’re on the same page as them.
Hiring: Old or New?
A lot of remote development guides assume you’re hiring a remote developer from outside the company, but that’s not actually how it tends to play out—often companies will hire a developer on-site and have them work at the company for a while, before offering them the opportunity for remote work. This tends to cut out a lot of the issues: you’ve got a better impression of how organised and self-driven they are, and they’ve established social bonds with the other staff. Here in New Zealand, you often see developers starting here, then moving to Melbourne or Denpassar to stay in a similar timezone but have better weather and cheaper rent.
While it’s a good way to get around a lot of issues, it does limit your recruitment options: if you’re in Riga and the best candidate lives with their family in Toronto, then they may not want to move for a year just to go back. This is going to depend a lot on the candidate: are they close enough that it’s reasonable to ask them to move? How deep are their roots in their current location? Are they good enough to justify the plane tickets?
Something to consider if you’re hiring a remote developer outside the house is how much prior experience they have doing remote work—it requires a radical shift in approach, and if you’re going for somebody you don’t know, you want to be sure they know their stuff.
Hiring: To CV or not to CV
There has been a lot of debate about the merits of the CV, particularly when hiring remote developers. Some companies prefer to use skills testing and there’s an increasing choir of voices saying that qualifications have been overvalued. It’s easy to lie on a CV, but it’s hard to lie on a test. Particularly in an industry like development, what matters less than where they’ve been before is whether or not they can do the job in front of them. We still prefer to see a CV anyway—it’s a nice complement to testing, and can help to round out our impression of a candidate. It’s worth talking about differing approaches, so you can get a fuller picture of your options.
The main advantage of skipping the CV is speed: the candidate can take 20 minutes of their own time when it’s convenient for them, freeing your HR team up to do other important work.
Hiring: Close or Far?
At last, we come to the big question on everybody’s minds: timezones. How can I hire somebody who’s asleep while we’re at work? That seems like a recipe for disaster! It’s not, if you’re smart. It takes a lot of planning, but it can actually end up working in your favour—we work extensively with distributed teams here at CodeClouds, and it takes a lot of organisation but it’s actually a huge boon. It means somebody is always up to talk to a client, it means somebody is always up to respond to a breakage, it means there’s a team able to respond to anything at a moment’s notice. It also means having a team with a broader range of cultural perspectives and understandings, that make us stronger internally while also letting us understand the issues of a more diverse range of clients.
Bringing It All Together
When considering a remote developer, you need to balance a lot of considerations, but they all come down to one simple question: are they good enough? Are they good enough at organising? At motivating themselves? Are they good enough to justify the timezone issues? Are they good enough to justify never coming in? Remote work will make your staff happier and more productive, but it also puts a responsibility on them that they need to live up to.
By being discerning about our hiring practices, CodeClouds have managed to build up an incredible team, both onsite and remote. If you want to know more about CodeClouds and our teams of excellent Shopify developers and Magento developers, don’t be afraid to get in touch. We have offices in Kolkata, Fort Wayne, Sydney and Wellington, and we’re experts in web design.