Communicating through meetings in remote teams

author image Slava Abakumov

on

in
An old-style telephone switchboard which would have been used to connect to telephones on a circuit. A thick cord in the photo was used to connect the calls.

Until recently I was a Development Manager, and the vast majority of my day was all about the second part of the title – Manager. I was managing people, ideas, approaches, processes, situations, etc.

This kind of activity involves quite a lot of communication. Frankly, it’s all about communication. And there are multiple ways how the communication in a distributed team can be handled.

Using Chat

First of all, it’s always about chats. Be it Slack, Microsoft Teams, Discord, Zoom Team Chat (yep, it has one), or Campfire, – you always write messages. Some may even be using just emails, but oh my this is a cursed road (so let’s even skip this one).

It’s an async communication (mostly): sometimes short, sometimes quite lengthy. But one of the distinguishing features is that you always have a written version of the discussion. So the solution or the summary is searchable and can be found and even reused in the future, one way or another.

Over time, you can circle back to that discussion, resurrect in chat history who said what and when, and what was decided by whom, and whether everyone agreed on that. Same reason why developers store their code in a version control system (like git, svn, mercurial, or fossil) and use blame or log to track who did what, when, and why.

Overall, chats are awesome for async and persistent communication. But they aren’t free from some drawbacks, mostly cultural and organizational.

Chats have a “direction” problem:

  • Who should I ping in certain cases?
  • Which channel should be used when?
  • What to do if the topic/problem is outside of the current channel setup?

Without clear workflows defined in the company, people may opt to write direct messages (DMs) to specific people instead of writing in public channels where others can help too. This is a complicated topic by itself and some companies even have specific written policies about that, and even training.

Using Voice

Voice calls, on the other hand, are more transient. A lot of teams in general and managers in particular are starting to use them to speed up certain types of activities, like decision-making. Or fill in the void of communication when people are spread worldwide.

Or to save their own time when they want to deliver something. Remember the famous quote by Mark Twain?

I didn’t have time to write a short letter, so I wrote a long one instead.

Mark Twain

So instead of investing time in writing a concise message, they opt for a (yet another) call. And most developers hate that.

Of course, there are situations when teams (or managers) are excessively using calls for various good-looking but harmful reasons (a false feeling of productivity, micromanagement, etc.) – but that’s not the point of this post.

Also, I do believe that calls are needed and very helpful – if done right.

At this point, I can’t imagine a company of several people who are located in various places of the world, and who do not have at least an email system set up to communicate with each other. Most likely, they have emails, chat, and an audio/video system for sync calls. That’s why Slack has calls and screen-sharing functionality on top of the chat, and Zoom has team chat on top of calls and screen-sharing. Everyone wants to be able to do everything.

So, at a certain point, meetings via calls are becoming an essential part of in-company communication. There are some exceptions but overall that’s the trend and the norm (at least as I see it).

The huge disadvantage of using calls in knowledge sharing and problem-solving (apart from removing the async nature of remote work/collaboration) is a lack of traceability of the contents of such calls.

Various successful startups try to address this main problem by automating note creation (free-form or using a template, even Google Meet allows that), or transcribing all the voices into a searchable, assignable, and actionable text (like otter.ai which does this beautifully, check out a screenshot below).

Screenshot of the Otter.ai interface showing the transcribed call where multiple people are participating

But in my opinion, the simplest approach always wins. And even better if it’s the cheapest also.

I personally find it very important to have a call summary. There are several ways how to do that: you (as a team) can prepare it upfront or after the fact.

Pre-meeting agenda

First of all, let’s agree that all calls should be efficient. And the only way to make them efficient is to be prepared for them.

Also, I’m talking here about scheduled calls, and not the ones like “Oh gosh, let’s quickly hop on a call now to address this pressing issue”. Emergencies are completely different beasts and should be discussed separately (let me know in the comments if you would like to read my thoughts about that).

The preparation can be done in various ways but I find the agenda to be the GOAT for this task.

Basically, each person who will participate in a meeting should have access to a document with points of discussion by each participant. That might look as simple as this:

  • Jon Doe:
    • conquering the world: setting up The Master Plan
    • conquering the world: plan execution
  • Jane Doe:
    • addressing Jon’s plan and execution
    • persuading Jon to help the world instead (and why)

I prefer the bullet points to be checkboxes (Google Docs allows you to do that easily with a single click).

Then, during the call, once the point has been addressed – mark it as checked. Later, all unchecked items will indicate what was skipped or postponed.

When using this approach, someone will need to write down what was said and/or decided for each point in a separate section called “Actions”.

So the final agenda may look something like this:

  • Jon Doe:
    • conquering the world: setting up “The Master Plan”
    • conquering the world: plan execution
  • Jane Doe:
    • addressing Jon’s plan and execution
    • persuading Jon to help the world instead (and why)
  • Actions:
    • Jon: anger management course
    • Jane: create “The Master Plan to Help The World”
    • Jane: eat a lot of pizza

And yes, during the next meeting, you just make sure to address those action items and mark them as completed too if they are done.

I like to use this approach for the vast majority of my calls as it clearly indicates who will talk and when (after whom), gives time for others to prepare, and the result of the meeting. This type of meeting preparation is good for regular calls, with more or less regular (day-to-day) topics.

Structured meetings are going much faster, with way less fatigue.

Post-meeting summary

But not all meetings are regular-paced or have a clear structure. Sometimes that may be a brainstorming session. Or a decision-making process that affects the whole business, or a huge team.

And realistically, the agenda for such meetings may consist of only one or two items like “discuss ABC” or “find a solution to move the needle in XYZ”.

Those calls are usually quite intense, require a lot of concentration, and may not even be suitable for a large number of participants (unless there is a moderator present on a call). This results in issues writing down everything that has been discussed and decided by all parties.

That’s when one of the participants – usually the one who initiated the call or who is the most “invested” in this call as it will affect their work the most – writes a summary message in chat or as an email with the outline of what was decided.

It’s important to understand that this is not a log of who said what and when. This is the summary. But it’s also important to note those who mentioned something important (“credit where credit is due”).

Here is an example that I used some time ago after one of the calls with my team:

Recipients: Everyone who participated in the call or “stakeholders”
Subject: [Name of the call] Summary
Body:

Hello there, again,

After an interesting call earlier today, I decided to write a “post mortem” of what was discussed/shared. Thus, it will be easier for you to …

Topic One:
Here is the summary of what was said and agreed upon on this particular topic. It also includes a “call to action”, asking call participants to do something.

Topic Two:
Here we discussed something else, and I also share some resources that are valuable or important, usually as links.
I also mention what I will do to make this topic more relevant or to achieve its goals.

Until next time!

You see, nothing fancy – as it should not be fancy. It should be functional, it should be to the point, and no fluff.

Also, pay attention to the “stakeholders”. Sometimes business owners do not (need to) participate in such calls – but they need to know that they happened and the outcome of such calls. In these cases, such summaries are ideal for them to understand the situation and even interfere quickly in that same email thread if they see something is off the rails.

Over the years, I find myself writing these notes very often – for each meeting that has a valuable decision for me that affects me and/or my work. But I do not always send them, I just keep an actionable list of results of the talking points in my notes and circle back to them from time to time.

What about using both approaches?

Pre-meeting agenda and post-meeting summary are not mutually exclusive. They can (and sometimes should) be used for the same meeting:

  • to give others topics and time to prepare
  • to streamline the conversation
  • to free the mind of some people of memorizing everything and focusing instead on the topic
  • to remind everybody about the outcome

So I would suggest experimenting: start with the agenda, and then during the call – depending on its complexity and intensity – either write down inline action items OR opt into an after-the-call summary email.

The call is only helpful as long as everyone who participated knows what to do next.


Comments

Leave a Reply

Your email address will not be published. Required fields are marked *