No, we won’t have a video call for that!⁠↗

Nothing has as dire an impact on productivity as poor communications.

A capable distributed team habitually externalises information. Information is generally far less useful when it is only stored in one person’s head, as opposed to being accessible in a shared system that everyone trusts and can use. If you take important information out of your own head and store it in a medium that allows others to easily find and contextualise it, that’s a win for everyone.

Excessively using chat isn’t being efficient. It’s being lazy. It’s a symptom of the worst kind of laziness (not malice!): in an attempt to communicate quickly and easily, for yourself, you are really making things harder for everyone, including yourself.

A wiki and an issue tracker (provided you don’t lock them down with silly view permissions), in contrast, both make it very easy to share, find, and contextualise information.

So really, make your wiki and your issue tracker your default mode of communications, and use the others sparingly.

Use chat for collaboration that requires immediate, interactive mutual feedback.

Using chat direct messages (DMs) as the default means of communication is utterly braindead. In order for a chat DM to be useful, there is precisely one clearly delineated confluence of events that must occur: • You need immediate feedback from the other person, • you need mutual back-and-forth with the other person, • you don’t want others to follow the conversation. I can’t emphasize enough that this combination is perfectly valid — but it is exceedingly rare. If you want just a private exchange of ideas with someone, encrypted email will do. If you want to work on something together with one person before you share it with others, restricted view permissions on a wiki page or an issue tracker ticket will work just fine. If you don’t need confidentiality but you do need interactive and immediate feedback, chances are that you’re working on something urgent, and it is far more likely you’ll eventually need to poll other opinions, than that you won’t. So just use a shared channel from the get-go, that way it’s easier for others to follow the conversation if needed — and they might be able to point out an incorrect assumption that one of you has, before you end up chasing a red herring.

A chat ping is a shoulder tap. “Pinging” someone in a chat (that is, mentioning their username, which usually triggers a visual or auditory notification), is exactly like walking up to a person, interrupting what they are doing, tapping them on the shoulder, and asking them a question. No matter whether it is your intention or not, they will feel compelled to answer, relatively promptly (the only exception is when you’ve done this so often that you have conditioned your colleagues to ignore you — congratulations). This means that you’ve broken their train of thought, yanked them out of a potentially complex task, forced them to redo what they did pre-interruption, or actually have them commit a mistake. So pinging someone in a chat is something you should only do if you are aware of exactly this risk, and you are convinced that whatever you’re pinging about is more important. Otherwise, to be very blunt, you’ll be seen as the asshole.

Every video call needs an agenda. This is, of course, true for any meeting, not just those conducted by video call. A conversation without an agenda is useless. You want people to know what to expect of the call. You also want to give people the option to prepare for the call, such as doing some research or pulling together some documentation. If you fail to circulate those ahead of time, I can guarantee that the call will be ineffective, and will likely result in a repeat performance. Until machines get intelligent enough to automatically transcribe and summarise words spoken in a meeting, write notes and a summary of every meeting you attend, and circulate them. Just as important as an agenda to set the purpose of the meeting, is a set of notes that describes its outcome. Effective distributed teams understand that the record of a call is what counts, not the call itself. It is not the spoken word that matters, but the written one. From that follows this consequence: To be useful, the write-up of a call takes more time and effort than the call itself. If you think that video calls are any less work than chat meetings or a shared document that’s being edited together or dicussed in comments, think again. The only way a video call is less work, is when everyone’s lazy and the call is, therefore, useless. Every meeting needs notes and a summary, and you need to circulate these notes not only with everyone who attended the meeting, but with everyone who has a need-to-know.

Once you do meetings right, you no longer need most of them. The funny thing is that once you adhere to this standard — and I repeat, having a full and detailed record is the only acceptable standard for video meetings – you’ll note that you can actually skip the meeting altogether, use just a collaboratively edited document instead of your meeting notes, and remove your unnecessary synchronization point.

However, having perhaps one meeting per week (or maybe even one every two weeks) in a video call is useful precisely for the aforementioned reasons of being able to pick up on nonverbal clues like body language, posture, facial expressions, and tone. If people are stressed out or unhappy, it’ll show. If they are relaxed and productive, that will show too. Note that these meetings, which of course do follow the same rules about agenda and notes, are not strictly necessary to get the work done. The team I run has one one-hour meeting a week, but whenever that meeting conflicts with anything we skip it and divide up our work via just the circulated coordination notes, and that works too. The meeting really serves the purpose of syncing emotionally, and picking up on nonverbal communications.

Whenever you need to thoroughly brief a group of people on an important matter, consider using a 5-paragraph format.

Let’s break these down in a little detail:

1. Situation is about what position we’re in, and why we set out to do what we want to do. You can break this down into three sub-points, like the customer’s situation, the situation of your own company, any extra help that is available, and the current market.
2. Objective is what we want to achieve.
3. Plan is how we want to achieve it.
4. Logistics is about what budget and resources are available, and how they are used.
5. Communications is about how you’ll be coordinating among yourselves and with others in order to achieve your goal.

In his book, David Allen suggests to apply one of the following four actions to any incoming bit of information: • Drop means read, understand, and then archive. It’s what you use for anything that doesn’t require any action on your part. • Delegate is for things that do require action, but not from you. Make sure that it gets to the right person and is understood by them, and make a note for follow-up. • Defer means it needs doing, and it’s you who needs to do it, but it doesn’t need doing immediately. Enter it into your task list (to use a very generic term, more on this in a bit), and clear it from your inbox. • Do are the (typically very few) things that remain that need to be done by you, and immediately.

So to summarize, here are my key points from this talk, in a nutshell — please make these your key takeaways. • Distributed teams are better than localized teams — not because they’re distributed, but because they’re asynchronous. • Avoid anything that makes a distributed team run synchronously. • Use less chat. • Have fewer meetings. • Write. Things. Down.