On Remote Work: Communication

For over two years I served as a consultant for Plausible Labs (usually doing iOS development). They are based in the US, with employees on both the west and the east coast (San Francisco and New York, respectively). I worked with them remotely, from Europe.

I’m going to explain how we did that and why that worked in our particular setting (namely that of a small, geographically distributed software engineering company).

This post looks at how the intra-company communication worked.

Communication

Arguably one of the most important aspects of working with others is communicating properly, even more so if you’re not physically present. There’s a couple of options you can go for, such as emails or fancy video conferencing. We chose a more minimalist approach: a text-based chat system.

The vast majority of our more ephemereal communication took place in IRC. We’d use email for the more important notifications that we didn’t want anyone to miss, but for almost everything else IRC was dominant. We could have used email for everything, but IRC is a bit ‘faster’ and more convenient for smaller messages than email. I have been using IRC for over 12 years now, but this was the first time I used it as the main vehicle of communication with a client (i.e. commercially).

At Plausible, we were so sold on it that, surprisingly, we’d even use IRC while we were all physically in the same room.

One time, after a few months of working with the company, we arranged a multi-day real-world meeting that everybody attended. For the first time I met the other engineers and designers in person. I foolishly assumed that discussions were going to be taking place mostly in real-life during that time, but I was wrong.

Why did we continue preferring IRC? Were we just too lazy to walk over to another desk? No. There are a couple of good reasons.

Silence

We were all sitting within a few feet of each other, so we could have walked over or simply spoken up when we had a question or something to share. In doing so, however, we would have interrupted the recipient(s) in doing their work, causing them to lose focus. (This is something that engineers in particular don’t seem to like.) There were no walls in between us either, so we would’ve drawn everybody else’s attention as well.

Fortunately, with a text-based chat, the only sound you ever hear is the typical keyboard background noise you’d have either way in a software engineering company.

The silent nature of this method also allows you to choose the locations from which you work. For example, I do often work from home, but I also enjoy going to a co-working space or even a café every now and then to get some social interaction. I find that if I work from home for too many days in a row, it feels a bit solitary and I personally like having the option of separating living space from working space.

The quiet nature of text-based communication makes it better suited for these types of situations where you don’t want to disturb other people. And unless you are expected to show up at an office or tell them, the people you’re communicating with don’t even realize it if you went somewhere else to work.

Asynchronicity

As stated above, we’d like to avoid interrupting people from doing their work. Engineering is a process that takes a lot of thought, and interrupting it can be inefficient.

The beauty of a text-based approach is that the recipient(s) can get back to the sender of a message at a time of their choosing, whenever it is convenient for them. In other words, the communication is asynchronous, since there might not be an immediate response. The receiver of a message can finish their chunk of work, then check the chat to see there was a request, and then reply.

Asynchronicity also helps with timezone issues. At Plausible, we had timezone differences of three, six, and up to nine hours every single day (NYC to SF, Europe to NYC, and Europe to SF, respectively). People who are active earlier can dispatch their messages to someone while the other person still sleeps, and then get a reply some hours later. (That said, I still tried to have a decent amount of overlap with US working hours to be able to communicate with people directly. I usually started working around 2 or 3 PM in Europe.)

Logs

Another advantage of IRC is that you can easily maintain textual logs of everything that was said. To me, being able to go back in our conversations to re-read things I didn’t remember the exact details of was incredibly helpful on numerous occasions.

Had our conversations taken place in real-life or via video chat, I would have had to take notes and rely on them being perfect.

Open Participation

Whenever you send a message, it is seen by everybody (unless it’s a private message). That means that even though you may have directed your message at person A, everybody else can still reply. Discussions between multiple people are facilitated.

Also, if you need to work with somebody who’s external, you can simply drop into a separate chat room with them. This is how we usually handled communication with our clients’ in-house engineers.

Time to Think

In a face-to-face discussion, it would seem rather odd if you went silent for a few minutes before responding something. While you could ask for a few moments of time to think, you’d still be looked at and feel that pressure of the other person expecting an answer.

Asynchronicity gives you more time to think. It strips the expectations typically found in face-to-face settings. And since you’re still in front of your computer, you can easily look things up if you need to.

In my experience, it leads to more qualitative discourse.

Conclusion

Working remotely is not trivial, but with the right people, the right tools, and the right methodology it can work like a charm and provide you with some benefits that you couldn’t otherwise achieve (such as choosing the location from which you most happily do work).