Skip to content
Shishir's Guide to Distributed Teams
Share
Explore

2. Meetings



Principle: Design your meetings like you design your apps

One of the classic challenges that distributed teams face is how to structure their meetings. If done poorly, distributed meetings can unveil the worst of meetings ー meandering discussions, unclear agendas, "loudest" voice dominates, etc.

I've often wondered why we don't spend as much energy designing meetings as we do designing products. Try designing your meetings like a growth team approaches a product. The concept of a "growth team" used to be reserved for gaming companies, and gradually spread through all tech companies, and is working its way through other industries as well. Growth teams start by thinking about their metrics and incentives, and set up their products to incent the behaviors they want to encourage.

The key principle is to think about the incentives you want in your meetings and design them accordingly.

One of my favorite books on this topic is
.

Here's a quick excerpt from the book:


A Meeting Toolkit

Coda can be a meeting owners dream. You can assemble Coda building blocks to create just about any type of meeting structure that you want.

For inspiration, this guide has a great set of templates for
. And if you want to work with something quick, you can access them by typing
/remote
in your Coda doc like this:
Screen Recording 2020-03-20 at 09.58 AM.gif


A few other resources to check out:
: how Zapier (a fully distributed company) runs their executive staff meeting
: how Square runs decision making meetings
: how the COO of Stripe runs offsites
: A catalog of tools for common meeting patterns and games
: How we run our board meetings at Coda

But I'll focus in on 2 specific examples of how we construct distributed meetings to be even more effective than in-person ones.


Example 1: "Dory" as a ranked model for Q&A to equalize your audience

If there's one meeting tool used more than any other at Coda, it's what we call the "Dory". It's a simple ranked Q&A tool where everyone can add questions and upvote/downvote them. The name Dory was invented at Google and comes from Finding Nemo, i.e. the fish who "asks all the questions".

Here's a quick example of how it works (try
/upvote
to add it in your own docs)
Idea
By
Upvote
Downvote
1
When do we think we can ship?
LT
1
2
Did we consider doing X instead of Y?
ED
1
3
Can we have a party?
SM
4
Will there be any scale issues?
JH
1
There are no rows in this table
Add a question

At Google, this format was used for a large all-hands meeting called TGIF where Larry and Sergey would answer questions from all of Google every Friday. But at Coda, we add this to docs for meetings even if there are only 3-4 people.

So which incentives are we trying to encourage? A quick list:
Equalize the audience:
Most meetings suffer from HIPPO syndrome where the biggest signal on who leads the discussion is whoever has the loudest voice. In Coda meetings, we run through topics in order of votes, regardless of the seniority or volume of the person. Not only does this equalize for distributed teams, it also equalizes for many other forms of diversity that can be overlooked.
Discuss what matters:
We go through questions in order, with high confidence that we're discussing the topics of most interest to the room. Then when we leave, we can usually say "we didn't get through every question, but we handled everything with at least 3 upvotes". Very satisfying.
Well-formed questions:
By asking people to write their questions down, they tend to be better formed. We have a best practice to still ask the person who suggested it to read it out loud and offer any commentary ー this maintains the "human" element of the interaction. But I've found that questions come out more factual and more respectful if they are written first.

We use this tool quite often ー not only for Q&A, but also for selecting agenda topics, or even brainstorming a set of ideas.


Example 2: "Pulse Check" as a way to remove group think

A second tool used frequently at Coda is a "pulse check" (try
/pulse
to add to your own docs). Here's a quick example of how it works ー feel free to uncheck the box and/or add your own row to see how it works.

Check to show everyone's pulse check (
3
submitted. Average pulse check of
2.67
)
Pulse Check
Reflection
By
1
I am happy
LT
2
I am sad
ED
3
I feel meh
JH
There are no rows in this table
Add your pulse check

This tool gets used in many different ways. In decision making meetings, it can be used as a way to quickly poll to see where everyone stands. In status meetings, I'll often use it to get a pulse on how everyone is feeling and draw out any latent concerns. In most cases, the table starts filtered so people can only see their own entry, and once everyone is done, the table is unfiltered for everyone.

So which incentives are we trying to encourage?
Avoid group think:
A common pattern for a meeting is "let's go around the room and hear what everyone thinks". In that process, each person who speaks is implicitly biasing everyone who speaks after them. This way, reflection is done privately first and I tend to find that it leads to more honest and independent thinking.
Equalize hierarchy:
When you go around the room, you inevitable expose your power structure. Once the boss weighs in, all opinions after that are contrasted with that one. A private pulse check allows for everyone to express their opinion at once.
Contextualize feedback:
Sometimes a participant will ask very tough questions in a meeting. But it can be hard to tell the difference between "I really love this idea, and I'm asking tough questions to make it better" or "I really dislike this idea, and I'm asking tough questions to expose why". The pulse check makes this clear.
Draw out the latent concerns:
When you jump straight to a planned agenda in a meeting, you'll often miss the topic or sentiment that was lying underneath. The pulse check tends to give people space to describe what's on their mind, and I often find that it affects the agenda.


Make it your own!

These are just two examples of common tools we use at Coda, but the real lesson here isn't to use these tools specifically, but rather to design your own structure.

Being a distributed team will force some structure on your meetings. Think through the incentives you want, and design your meeting accordingly.



👉 Next up:

Want to print your doc?
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
CtrlP
) instead.