Last week I discussed remote working with Lisette Sutherland, who interviewed me for her forthcoming book. We talked about my experiences as a software developer at Lunatech and started by considering the benefits of remote working.
In a way, the benefits of remote working are obvious, but perhaps not for everyone, and there are benefits that you might not expect.
More collaborations are possible
The clearest benefit of enabling remote working is that you create the possibility for collaborations that are not otherwise possible. In my case, I wasn’t usually the one working remotely: I was based in the Lunatech office in Rotterdam, but worked with colleagues and customers in other countries.
If you’re the person working remotely then this really is obvious: if you work remotely then you can be Stéphane in the South of France. Stéphane Épardaud, who had previously worked at Lunatech, joined us again after doing a PhD but worked from home. Home was a steep valley somewhere North of Nice that certainly counts as `remote' by Dutch standards (photo). We were able to work together on a software development project, because our tools worked the same way wherever we were, and because we were happy to do most of our interaction via an IRC channel.
On another project, Lunatech’s `remote team' in Rotterdam developed software for a US government project. We only flew to Washington DC for project kick-off and completion meetings, six months apart. Once you’re off-site it doesn’t necessarily matter where you are.
Making remote working possible enables collaborations that aren’t otherwise possible, with both customers and employees.
Less impact when staff stay at home
A company that enables remote working makes its IT infrastructure accessible from outside the building, securely, so staff can log in to the tools they use on the job. The remote-aware company has web-based work tracking, group chat and other online collaboration in place, so that staff don’t have to troop down the corridor to a meeting room to be able to collaborate on their work.
In practice, the chat room is a lifesaver for someone who has to stay at home occasionally, for a delivery, just as much as for the colleague who works remotely from another city. Online collaboration tools may be intended for staff who always work remotely, but they turn out to also be useful for staff who unexpectedly work from home from time to time. This is important because the latter group is everyone.
Enabling remote working reduces the impact when an employee has to stay at home for a day. This benefits everyone, not just people who work off-site.
Better collaboration in the office
The even-less-obvious benefit to remote working is that it makes things easier for people who don’t work remotely at all. Web-based tracking tools like JIRA and Trello, accessible both inside and outside the building, make teams’ activities visible. The value of keeping everyone on the same page is something that various software tools that take literally.
When a team uses web-based tools, URL-sharing becomes common. This is one of many reasons why a chat room becomes useful - providing the real-time commentary of a team at work. Telling someone that `it’s on the wiki' is a much less annoying answer to a question if it comes with a clickable link.
Embracing tooling for remote working is like the usability that comes from Good Grips kitchen tools. The additional communication channels benefit everyone, even people in the office. Tog explains this best:
Designs for the disabled don’t have to hurt usability for the normally-abled. In fact, if you are doing your job properly, your designs will help everyone.
When some people work remotely, office-bound staff benefit too. Sometimes the chat room is more convenient than the meeting room.
Enable team rotation
A potential benefit of remote working is the impact it has on transferring knowledge to new team members. A co-located team may maintain project knowledge in a purely oral culture, which is not feasible when some team members work remotely. Working remotely on a software development project requires certain project and system documentation to make it possible to get started easily.
This is most clearly visible on successful open source projects: their web sites explain clearly what the project is for, what its goals are and how to get started on development. The better the tooling, the fewer steps there are to getting the software to build, test and run it locally.
This is an open question - whether the project and system documentation it requires is actually essential for all successful software teams: do the co-located teams who try to do without suffer as a consequence?