Working from anywhere, not just from home.

I’ve been doing remote work on and off for at least 5 years. Various clients, various cities, various countries. I’ve had mostly great times, and I’m not the first person to write about it.

This isn’t a story so much as a sell. It doesn’t matter if you’re a manager, or a CEO, or a developer, or a tester, or anyone, these skills and practices are important. Even if you don’t do full-time remote work, fixing your work practices to allow the possibility of remote work helps heaps.

Meeting up with DiUS buddies in Tokyo – photo credit: Sonny Mai

The good with the bad

Many articles only focus on half of the picture. Remote working isn’t perfect for all situations, but is often a good option for most of the time.

Benefits

Remote workers get a lot of freedom. We can optimise our work hours and timings better, especially around non-work events, such as medical appointments or peak traffic times. We can choose workspaces that are more conducive to effective work, or more convenient for our movements.

Even when I’m working in the DiUS office, I still sometimes take my work to a café, so I can continue, but still get a coffee. When people don’t have an implicit (and traditionalist) expectation that they can always walk up and interrupt us, we get more control over our own time, and more respect for it.

As usual, however, freedom is a double-edged sword. Self-control and organisation need more focus. Disorganised and easily-distracted people will have to work harder to stay productive. There are many techniques to stem these issues (discussed more below).

Drawbacks

Many aspects of co-located work rely on emergent behaviour and problem solving to feel like they require minimal effort. The physical divide of remote work almost requires teams to actively discuss options for all these areas, instead of just seeing what happens.

This perspective isn’t even an argument against remote work. It’s an argument for getting buy-in and being more explicit about our tools and processes, even when we are co-located. We should always (often?) question our conventions and traditions – maybe they’re right, right now, for good reasons, but that doesn’t preclude future changes.

Communication and team support can be tricky. Different media give us a different communication experience: email is more official, slower turnaround; chat rooms (e.g. Slack) are good for immediate to short-term comms, but context is transient, and it’s not great for history; SMS is good for guaranteed delivery, but I don’t get them on my computer; call me by phone if you need an answer right now.

Beyond verbal/written, there are many options for video calls and screen sharing (including on-screen collaboration). Pairing is harder, but we have tools for that.

Lunch is an important social ceremony for me (as it says in my consultant profile, and Fred’s blog post). It can give you more people context, history, bonding, and empathy than the memes in your Slack channels. I don’t really have a solution for this, although some people organise lunchtime video calls!

In some (slightly more archaic) organisations, it’s very hard to get remote access to systems and environments. VPNs are often used in these (and other) cases, but organisational bureaucratic overhead can still cripple this experience. Old-world security practices can neglect to see perspective on real risks, such as entire repositories (on personal dev machines that get taken home) vs Stash or Github enterprise behind a VPN. Nevertheless, if you can’t get access, you can’t work remote.

The last potential drawback I want to talk about is often overlooked: perception. Perception of remote workers can be degraded through no fault of their own. Poor communication, misconceptions, or bigotry/prejudice can undo all benefits. One of the best ways to prevent this is to build empathy for remote work. Get everyone to work remote, at least occasionally. If it sucks, do it more, until you build better ways.

Without feeling the disconnect, it can be easy to think that people you can’t see aren’t doing enough. This is a perception bias, and usually indicates a micromanagement mindset. This is just as toxic in a remote-less workplace, but harder to detect and rectify.

Hostel breakfast in Kyoto

A potential recipe

There’s no perfect ruleset for everyone, but these guiding principles and considerations are pretty universal.

Trust and rapport

I try to spend 1-3 months on-site before working remote. It’s hard to build trust and rapport without spending time communicating, and sharing work experiences. That doesn’t mean it’s impossible, but it’s trickier, especially with a usually-on-site, co-located team.

Discipline

Be explicit and consistent about your ceremonies, schedules, and practices. Some people find working from home difficult if they don’t put themselves in work mode.

Sometimes this involves setting up a room as an office, and changing into less casual clothes. A good rule of thumb might be to always be client-presentable, in case you need to be on a video call, or duck into the office. Acknowledge your bad habits, and actively combat them.

When you’re in different timezones, make sure everyone understands what the arrangements are for expected work hours. Sometimes you need to be up at crazy hours for meetings. You shouldn’t be expected to work through the night, though. These are all important considerations for non-remote work, too, but are often left unsaid.

Tools

As mentioned before, sort out a small set of agreed-upon communication tools, and what situations to use them in. Discipline in using them is a good habit to get into, e.g. always post questions in Slack, even if no one’s remote.

These kinds of habits can prevent you from accidentally excluding people from important information. Sometimes people are in meetings, or wearing headphones, or whatever. Don’t damage their context by omission.

Speaking of context, card walls (or whatever you use to organise work) need to have one digital source of truth, to have any chance of autonomy. You can replicate it onto a physical wall, but if the digital isn’t primary, everything falls apart.

There are lots of dev tools, too. Screenhero is pretty good for voice, screen sharing, and pair programming (but not video calls). Google Hangouts is ok for video and screen sharing (but not pairing), and integrates well with Calendar. For terminal sharing, there’s tmate (forked from tmux). I haven’t used any seamless GUI editor sharing plugins, but some people are trying.

The point is: work out your pain points, and find tools and practices to help facilitate.

How others are making it work

I’m, admittedly, not the first person to write about remote work. Some of this wisdom is distilled from reading others’ works, and my own personal experience.

Related reading

37Signals – Remote: Office Not Required is a very thorough set of topics on the subject.

These next few are more anecdotal: My Life as a Robot, Life telepresent: working vicariously through the Beam robot, I used a robot to go to work from 3,500 miles away.

And some others from DiUS: Andy Spinks – a working remotely kind of life, a career in Tech: Q&A with Albert Jou (second half).

So, get on it

Facilitating remote work is good for all work. Even if you don’t have any remote workers, these habits signify greater capability maturity. Building in antifragile practices may save your business, or maybe just attract more diverse talent. People are already doing it, so that can’t be an excuse.

Cafe fairy lights in Nagoya

Appendix: what I’ve really done

In the past 5+ years with DiUS, I’ve had the opportunity to do a bunch of remote work, and I take advantage of that as much as I can. Take this as examples of variation and flexibility, ideas for compromise and accommodation.

The mobile team for PayDirect at MYOB (doing Android, iOS, and Rails) got me onto the Remote book. The tech lead of that team pushed to get everyone working remotely up to 2 days a week. This forced a lot of issues, but (with good facilitation) we got to conclusions and fixes quickly.

The added freedom meant that when inclement weather stopped the train line to that office, I had no problem staying home to work. The main takeaway I want to impress into everyone is that restrictive and fragile practices can mean failure is always catastrophic. Make it easy for people to work and fix things, and it helps all the time, not just in emergencies.

I moved to Sydney (and lived in an apartment hotel in the CBD – not recommended) for 3 months, to work on Qantas’ mobile app, Airways. I visited my balcony plants in Melbourne twice during that time, then finally came home, moved house, and spent another 6 months doing 50% of my time in each location.

Without the first solid 3 months, it would’ve been impossible to lead that team on a full rebuild of the app. It was released a few months after I finished up, and the client is now very happy with it, and how it was run.

CarAdvice has an office in both Melbourne and Sydney, and the CTO went to a lot of effort to make conference calls and remote work seamless. All of the dev environments were cloudy, but runnable on local machines. We would get people to attend meetings in cars, to test out hands-free, and make sure remote attendees had minimal friction. Having free desks with screens available in both offices meant people could travel up and down with barely any notice.

I should mention that it’s not just devs, since they make up only a small portion of the company. Editorial staff often traveled interstate or internationally, and needed to have calls, meetings, and submit work remotely. During this time, I went to Japan for 3 weeks, working 80%, and traveled from Osaka to Tokyo, stopping for fewer than 5 days in each location. Cafés were great, and even rural internet is way better than anything in Australia.

I worked with REA Group on their first VR product, and when we joined, one of the team had just moved to Sydney. Pretty much all the REA devs are in the Melbourne office, but this wasn’t a problem. I went up to visit him, and he also came down several times. The innovation team runs particularly lightweight, so a Trello board, and Skype or Hangouts did just enough. People also worked from home occasionally.

At Unlockd, our team started with a couple of other consultants from Sydney, and they were only on-site in Melbourne for a few days. I went to visit them for a week, too, and it helped keep our working and coding styles consistent. I also spent a couple of weeks in Japan (just Tokyo this time), and caught up with some DiUS devs there. Andy (linked above) was also working for Unlockd, so it was nice to bring bits of the team together again.

Work breakfast at Christchurch cafe