Remote work and efficient communication
The topic of efficient communication has never been more actual than today. As more jobs are being done remotely, communicating efficiently is paramount to the success of companies who have embraced this way of doing business. In the 9 years or so that I have been doing most of my work remotely, I have learned a few things that have helped me and my clients deliver successful projects in a timely manner, and with little to no headaches. I’d like to share some of these ideas with you. The scope of this article is for communication that takes place between people of the same team, or working on a common project, primarily in tech.
First of all, here’s a list of communication media that are available to you when working remotely:
- Phone
- SMS
- Instant messaging (Slack, Discord, Facebook Messenger <really??>, etc)
- Video conferences (Google Meet, Zoom, etc)
- Issue tracking on your repository (Github Issues, Gitlab Issues, etc)
- Card based task/project management platforms (Trello, Asana, etc)
I have had the chance to make use of all these media throughout my career, and here are a few observations I’ve learned for each one of them.
Phone
Calling someone should be used as a last resort, and only for the most urgent of cases. The server is down? An integration suite stopped working and so the business is not getting any new leads? The email service suddenly started sending hundreds of copies of the same email to the same people? These are all good contenders to call someone responsible on the phone to raise awareness of the issue as soon as possible. This is an example of real-time communication, when every second counts (and costs the business money). Obviously, this should not be abused, as calling someone on the phone for no good reason may feel importunate.
SMS
Throughout my career, I have only been contacted by SMS one or two times. I’ve initially shared my phone number with my clients to be used for calling me in case of urgency, but I was surprised to receive a few SMS-es on several instances. I admit that it was a bit weird to get those messages on my phone, when an email could have worked as well. I have only found one good way of using SMS-es (or so I think 🙂 ), and that is to share sensitive information, when you don’t have any other means to do it, but don’t want to send everything via the same medium (imagine sharing an API secret key – you can split it in several parts, and send the different parts by various media: emails, instant messaging, SMS). My stance on other uses of SMS is it doesn’t feel professional, so I wouldn’t recommend it.
Instant messaging
And here we enter controversial territory. I’ve heard in the past how instant messaging has been key to a team’s success, yet others say it’s completely unproductive and an attention thief. As most people in tech, I use Slack to stay “connected”, or to merely say that I am available on Slack. However, Slack is far from being something that I use often, in fact I tend to only use it considerately when I really need someone’s attention quite urgently (but not as urgently that would justify a phone call). I also like to use Slack for “meta” communication – sometimes some back and forth is inevitable to understand or clarify something, and yet doing this on a more permanent medium such as email, or an issue tracker, would create too much noise over there. In this case, Slack works great at taking the discussion off the main channel for a bit, assemble the needed information, and once that is done, that information can be summarised and added back to the main channel. Offtopic: many communities like to use Slack instead of a forum. If that’s a closed community, it’s fine. But if that’s a public community, personally I believe this is not a good fit for an instant messaging platform. Why? Because discussions get mixed (in an ideal world, a discussion would be isolated in a thread), and the most important reason is that information gets lost (history limits) or is un-crawlable by search engines.
Video conferences
For the past year, people have been crazy about video conferences, and we’ve even had a few laughs about some of them (the cat lawyer? the kids who crashed their father’s business meeting? what else am I missing?). Personally I am not a big fan of video conferences, because they often feel long and wasteful (unless there is a person who will make sure that the discussion does not diverge from the main point), and volatile. In my opinion, a good use of a video conference is when you need to get a bunch of people together to discuss a specific issue and everyone on the call is needed to reach an agreement, or be aware of some important decision. A successful conference needs to converge to a solution/decision. Also, a conference relies on verbal communication, which is volatile. Therefore, there needs to be someone who will take minutes and provide them on a more permanent medium that can later be referred to. Also, I believe that conferences are suitable when an important person needs to communicate a message to multiple people at once, and this person’s time is extremely valuable, which makes other communication media like a written email unfeasible.
And now we enter asynchronous territory. Personally, I am not a big fan of emails, because they are quite a primitive (as in, unsophisticated) communication medium. Also, emails are not flexible: you can’t make edits (this can be a feature); unless your email client allows it – you can’t mention other people; searching and filtering can be complicated; they mimic letters, so informal emails may seem rude; because email communication is asynchronous, you may want to fit in as much information as possible, which can result in a long email that’s hard to process by others; it’s easy to open an email just to have a peek, and then forgetting to reply; it doesn’t offer the flexibility for recipients to unsubscribe, therefore sometimes creating unnecessary noise; and the biggest of them all in my opinion is – unless you aggregate and make them available, emails are not available for posterity, therefore information can be lost. However, it also has many advantages: asynchronicity, means that the recipient is not pressured into replying right away, often producing better replies; reach – since it is so popular and largely adopted, you can reach out to a lot of people, both from your team or outside departments; accountability – since once sent, an email is immutable, and can be used to back your actions.
Issue trackers
This is my favorite communication medium. Since currently most of my work output is software development, it makes sense to keep communication close to the code. If your product is software, then you should do it too, and here’s why:
- Collaboration and issue tracking is super efficient. You can mention other people, you can reference other issues, you can reference other commits (basically you can reference a lot of things), and all this makes it very easy to follow a train of thought. Compare that to the hell of searching or browsing through various emails, and you’ll know what I mean.
- You can extract information both ways: either you find a code change (from a commit), and from it you follow up to the issue / pull request; or, you can find the issue, then see what code changes are related to it.
- Information is not lost and is always easily accessible. When a new team member joins, they automatically get access to all the history related to that product, and they can understand why certain changes were made, or how the product has evolved over time.
- Wikis are also a great way to make certain information more accessible through documentation. I create wiki pages to document how certain services work, or how to use a certain feature. While this information would exist in an issue, a wiki is usually written as a tutorial, meaning it’s rewritten to be easily understandable and may contain examples.
- You get a clear view of what’s going on with your project, and what’s pending your attention. Unlike an email, or a slack message that can be overlooked, or accidentally archived or deleted, an issue is very unlikely to be accidentally deleted or closed. In fact, I just checked, and with Github Issues it is not even possible to remove an issue – once you created it, it’s there forever, and that is a good thing.
- You have a plethora of ways to organize your project: labels, repositories, milestones, make someone responsible by assigning the issue to them etc. What this means is you can scope your communication. In the future, if you ever need to find information belonging to a certain product / service, you know which repository to search in.
Card based task/project management platforms
Another way to communicate is through a platform like Trello, Asana, Basecamp, or other similar services. I think this is a superior medium compared to emails, instant messengers, or the like, because how easy it is to follow and transform information. Usually card based project management follow the Kanban methodology. This allows everyone working on a product or project to clearly see the state of things, or more importantly to see the progress. The Kanban board essentially allows to transform an idea from inception, to completion, through a series of steps, where at each step certain decisions would be made and certain’s people’s attention would be needed. I think card based project management platforms are great for all situations, except when code is involved. If code is involved, then an issue tracker on the repository is way more superior, for the reasons I outlined above. I have worked on a web service where communication was done via a Trello board, and I absolutely hated it for not being able to refer to commits, find the issues related to certain code changes, or refer issues from other dependent repositories.
As you can see, various communication mediums have their strengths and weaknesses, and some are better suited than others based on the situation. What I would like to emphasise through this article, is how important written communication is. Our civilization, all accomplishments, and all the progress we have made is due in major part due to being able to write down ideas, and make them available for others to pick up and continue the work. Verbal communication is easy and convenient, but it is not permanent, and it is expensive in the long-term. At one of my previous jobs, during my first week I noticed that there was a total lack of documentation, tests, and communication was sometimes done via a Trello board (with many issues having non-descriptive titles, and no description or background information). During the onboarding process, in a meeting with the CTO I asked why the company does not invest more in written documentation, to which the answer was “We would like to encourage people to interact between them and between departments. If you have a question, just ask someone.”. But who do I ask? And isn’t it wasteful? Point is, written documentation is an investment, but also a requirement for a company to be efficient, especially in a time when work is done remotely.