Shishir's Guide to Distributed Teams

Explore

2. Meetings
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

Gamestorming: A Toolkit for Meetings⁠

Here's a quick excerpt from the book:

⁠

Imagine a boy playing with a ball. He kicks the ball against a wall, and the ball bounces back to him. He stops the ball with his foot and kicks it again. By engaging in this kind of play, the boy learns to associate certain movements of his body with the movements of the ball in space. We could call this associative play.

Now imagine that the boy is waiting for a friend. The friend appears, and the two boys begin to walk down a sidewalk together, kicking the ball back and forth as they go. Now the play has gained a social dimension; one boy's actions suggest a response, and vice versa. You could think of this form of play as a kind of improvised conversation, where the two boys engage each other using the ball as a medium. This kind of play has no clear beginning or end; rather, it flows seamlessly from one state into another. We could call this streaming play.

Now imagine that the boys come to a small park, and that they become bored simply kicking the ball back and forth. One boy says to the other, "Let's take turns trying to hit that tree. You have to kick the ball from behind this line." The boy draws a line by dragging his heel through the dirt. "We'll take turns kicking the ball. Each time you hit the tree you get a point. First one to five wins." The other boy agrees and they begin to play. Now the play has become a game; a fundamentally different kind of play.

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

remote meetings⁠

. 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 to Run your Distributed Staff Meetings like Zapier⁠

: how Zapier (a fully distributed company) runs their executive staff meeting

⁠

Gokul's SPADE Toolkit⁠

: how Square runs decision making meetings

⁠

Claire's Offsite Toolkit⁠

: how the COO of Stripe runs offsites

⁠

Gamestorming: A Toolkit for Meetings⁠

: A catalog of tools for common meeting patterns and games

⁠

Shishir's Guide to Effective Board Meetings⁠

: 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

Upvote

Downvote

When do we think we can ship?

Did we consider doing X instead of Y?

Can we have a party?

Will there be any scale issues?

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.

⁠

Show everyone's pulse check (

3

⁠

submitted. Average pulse check of

2.67

⁠

)

Pulse Check

Reflection

I am happy

I am sad

I feel meh

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:

3. Communication⁠

⁠

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.