For the past five years I’ve worked remote. This post gives some insights in that experience, and some best practices to make it work best. I joined Luminis Technologies five years ago, as one of the first employees. Although Luminis Technologies is part of Luminis, which has been around for 15 years, we were operating quite differently from the rest of the organization. Working remotely was one of those things. Since I left the company to join Netflix it made sense to look back at this.
Remote all the way!
In the early days we still did have a small office, were we would meet once or twice a week. Most of the actual work was being done at home, but sprint deliveries and planning was done face to face. After a few months we had a decission to make, because we had to leave the office we were renting. This brought us to the discussion if we wanted to have an office in the first place. We needed growing, and not being tied to just (the east of) the Netherlands would make it much more likely to find great developers. Having a lot of experience working with people around the world in open source projects, we decided to try going remote completely and give up on offices.
This brings us to the first really important point; go all in with being remote. When everyone in the team is working remotely, all communication needs to happen online. Online communication can work very well, but not when only part of the team is remote. For example in the early days we tried some face to face meetings while some collegues were calling in over Skype. This just doesn’t work well.
Communicate
Being remote doesn’t mean you can’t communicate with your team. Discussions are no less important than with a co-located team. On most days I would have multiple Skype conversations with other team members to discus ideas or design decissions. It’s easy to share screens or send a code snippet, so don’t hestitate to ask “what do you think of this” questions.
Asynchronous communication
One of the benefits of working remote, is that everyone can work on a schedule that works for them personally.
Some of my collegues have kids who they need to pick up from school.
Some like to start early, others like to work late in the evening instead.
I would go to the gym somewhere during the day on most days.
Embrace this flexibility!
Off course this also means not everyone is online all the time.
Also, it can be really helpful to just turn of all communication for a few hours to really focus on something.
All of this means you can’t expect everyone to be online at the same time.
Ask “can you review this later”, or “can you help me think about this problem later” instead of calling someone immediatly.
When you plan your work around asynchronous communication, it is very rare to be blocked by the fact that someone else is not available.
There’s always something else you can work on, and no need to just wait for someone else.
Direct messaging vs broadcasting
Having lot of communication channels is great. At the same time it’s a great distraction. When you are constantly looking at message notifications, it becomes a lot hard to focus on the task that you’re working on. First, asynchronous communication should be accepted. Just ignore messages until you’re ready for it. Second, when sending messages, think about who should read them. Having chat channels with everyone in it is very useful, but it’s also easy to “broadcast” things that really not everyone needs to see. Send messages only to those that have something to do with the topic. Remember that every message takes time, and more importantly attention, of everyone reading it. Also avoid asking technical help to the whole team. It’s super easy to paste a stacktrace in the team chat and ask for help. In most cases you just need a second pair of eyes, so just ask someone else directly. Off course there are exceptions. If you see something really weird, it can help to ask “anyone seen this before?”, but these cases are (hopefully) rare.
Design discussions
Some discussion do need input from as many people as possible, such as discussions about features, API design or architecture. Group discussions with larger groups, either in the same room or online, don’t usually work very well. This is where online collaboration tools like Confluence are very useful. Write down an initial design, and let other comment on it. Having a well written starting point is important. It also gives all collaborators some time to think about the case.
Stop working!
The flexibility of not having fixed office hours is great, but comes with the danger that you never really stop working. It’s easy to feel you should keep working in the evening instead of going to the gym when you ran into some unexpected problems. In our work there’s always more to do, so accept you can’t do everything in a single day. Personally I found this often difficult. My way to deal with this is was to have going to the gym as a non-optional daily activity on my shcedule. By making it non-optional (it’s just part of your day), you at least have a few hours that you’re not busy with work and you don’t have to make the tradeoff every time between work and training.