How to build support for remote work
30 April 2019
Remote work is great – you can hire faster and find more qualified developers around the globe. For product managers, human resource specialists and hiring managers, it can be difficult to convince top management that it is worth it. In this blog post, we’ve compiled the most typical objections you are most likely to hear.
1. For a high growing company, can you hire 40 product people a year in your local job market without compromising on your standards?
It’s a very difficult task, so it’s good to keep in mind the cost of no action.
2. With remote work you can start small without a big one-time commitment
The smallest possible commitment is to allow one team to work outside of the office on Thursdays and Fridays, for instance. Make sure to have results measurement in place, so you can compare the results during the on-site period vs. the remote period. A more extreme version of this experiment is to completely convert one team to remote (or hybrid).
At RemoteMore, we do not recommend adding 1 remote person to a non-remote team as an experiment. Typically, the rest of the team has other and higher priorities than adjusting to integrate a new co-worker who is not on-site with them. That results in the new employee being isolated in terms of communication and information. In both cases, they will need support to do it successfully. There is a learning curve as well, so don’t expect it to work perfectly from the first day. Aim to try it with people who already have the skills needed for working remotely (look for proactivity, good at overcommunicating etc.).
3. Aim to present the full picture; the positives and the drawbacks
The list of benefits is the easier part, it’s all laid out in the previous section.
It will take work to implement the new practices. Probably in terms of software tools, you are already there. But the most challenging part is about the culture and work practices.
The team leads will need to be good at organizing the work process in an environment of higher communication friction. It is very possible to be exceptional at this, but it is a skill that needs acquiring.
Preferably, those points should be specific, to make it more of a cost-benefit comparison instead of arguments and opinions.
3. Are there any companies that are already working remotely successfully?
There are many companies who very successfully work remotely. You can find a list of remote companies in our slides from the meetup "Managing Remote Full-Time Developers".
4. "But with a distributed team, pair programming is impossible ..."
Address the myths about working remotely. Be specific on what remote work means. For instance, pair programming can be done remotely. In addition to screen sharing, Zoom has a mouse sharing feature as well. There are various web-based development environments (like Cloud9 by Amazon) that function like Google Docs for programmers. In the Visual Studio Code text editor by Microsoft, there is a "live share" feature that allows for real-time collaborative development.
5. Share resources internally
You can find a list of remote work resources at the end of our work-in-progress book Managing Remote Full-Time Developers.
6. Recognize that you already work remotely
A lot of communication happens between people who do not sit in the same room. Emails. Phone calls. Video conferencing in Skype or Zoom. Instant messaging in Slack. It is the same communication techniques and tools that are necessary in remote teams.
Most employees in the modern office are actually working partly remotely, as a result of globalization and the amazing advances in technology in the last decades.
Especially the top management is likely to work from outside of the office often.
Technology and tools will only get better and this will allow everyone to work more remotely with less friction.