Skip to content
Gallery
Shishir's Guide to Distributed Teams
Intro
1. Virtual Space
2. Meetings
3. Communication
4. IRL
5. Fun!
Share
Explore

Shishir's Guide to Distributed Teams

Five lessons from a decade+ of running distributed teams
by
Shishir Mehrotra
⁠
Shishir.png
⁠


March 2020 author's side-note: This doc has been developed over the past decade with my perspective on distributed teams but has not been shared publicly. Given the global crisis is causing a number of teams to be pulled unexpectedly into the "distributed" movement, I felt it would be good to publish this more broadly. Please note that the type of "distributed" work we're seeing today with a global pandemic is different than what is described here ー but I hope this is still a helpful guide.

When we started Coda, we discussed a few key questions about the culture we wanted to build. Amongst them was one that ended up being particularly important to how the company would grow ー should Coda be a "distributed" company or not?
Today Coda operates with people spread across eight states and two continents. We also have three physical offices where a critical mass of employees are located, but no single "headquarters".
When we made our choice, we had a few observations that may be helpful in your decision.
⁠

Every team is a distributed team.

Before founding Coda, I was a long time Google exec responsible for the YouTube products. Our team at YouTube was very distributed right from the start. We had thousands of engineers spread across 8 engineering offices worldwide, and dozens of offices for sales, content partnerships, marketing, etc. Even in the Bay Area, we were split ー our primary campus was in San Bruno, about 30 miles north of Google headquarters in Mountain View. So starting in 2008, I learned how to lean heavily into this model and not only "make the best of it" but to turn it into a strategic strength.
As I've watched many teams grow, they all eventually become distributed. For some companies, it happens when they have a field sales or success team that needs to be located near their customer base, and they suddenly have their head of sales calling into meetings. For others, it happens even earlier when their team spreads across buildings, or even across floors in the same complex. Before they know it, they're video conferencing into meetings with people who are technically in the same "office" but are far enough away to be inconvenient to get together.
But for some companies, they wait "as long as possible". The big challenge this creates is that you will develop a "headquarters" dynamic.
An easy hallmark of teams that didn't start "distributed" is that they refer to locations as "remote" offices.

Strategically amplify the pros instead of minimizing the cons.

There are clear cons to being distributed ー humans are social by nature, and develop trust through many sustained interactions ー and much has been said about how to mitigate this con. But there are also three primary "pros":
Access to talent → Diversity: The most obvious pro of a distributed team is access to talent that may not be able or willing to live in your headquarters city. As much as I love the SF Bay Area, it's clear that not everyone feels the same. But perhaps less commonly stated is the fact that this opens the door to a very different type of diversity. You will inevitably bring in people from entirely different geographies and cultures, often with a different perspective on the world. And especially for products that are delivered on a global scale (like YouTube and Coda), this is critical to being able to understand your customers.
Chaos → Structure: The less commonly mentioned advantage is that distributed teams tend to develop better structures for how their teams operate. Since you can't rely on the "water cooler" conversation, you tend to document and invest in communication that scales. Since many of the implied hierarchies aren't present (e.g. there's no "corner office"), you tend to develop structures that equalize hierarchies and can encourage involvement.
Adhoc → Documented: As you tend to develop clearer structures and patterns in distributed teams, you naturally document more. I've found that organizations that learn to communicate through documentation are not only better aligned, they tend to be more thoughtful as well. I'm very aligned with
Jeff Bezos
⁠
on the power of writing.

My observation is that:
Teams that lean into the pros find that being distributed helps them be a better company in general, even when they are in the same location.

⁠

Introducing the 5 Lessons

There are some amazing writeups on distributed teams, and I won't try to replicate them here (some of my favorite's are Matt Mullenweg's
Distributed Work’s Five Levels of Autonomy
⁠
and Wade Foster's
How to Run your Distributed Staff Meetings like Zapier
⁠
).
This doc focused on five specific lessons that I've learned that may not be as obvious. Each has an introduction here, and then a section with a drilldown.

⁠
Lesson 1
⁠
: Set up the right virtual office space.

Companies often spend an enormous amount of energy, money, and time on their physical spaces. But for distributed teams, this needs to be complimented with commensurate effort on the "virtual spaces".
The key principle is to develop an inviting, always-connected space. Read more in:
1. Virtual Space
⁠
⁠

⁠
Lesson 2
⁠
: 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 valuable problems to solve, metrics, and incentives, and set up their products to incentivize the behaviors they want to encourage.
The key principle is to think about the incentives you want in your meetings and design them accordingly. Read more in
2. Meetings
⁠
⁠

⁠
Lesson 3
⁠
: Redesign your communication system: Try public-by-default email.

When people talk about distributed teams, one of the main questions to ask is the time zone question ー it is one step to be distributed across different locations in the same time zone, but it is entirely different to work across time zones. Many of the single time zone norms break down. The most important is that your communication patterns get split and you have to choose what works synchronously and what needs to be done asynchronously.
Setting up a communication structure requires matching the communication channel with its purpose. One tool that made this work for us was Public-by-default email ー inspired by the
Stripe Email Transparency model
⁠
(also adopted by other teams like
Khan Academy
⁠
). Read more in
3. Communication
⁠
.

⁠
Lesson 4
⁠
: Human connection matters, set an IRL frequency.

I've found that the ability for a team to work well distributed is greatly amplified if they have formed a baseline of personal connection and trust. Interestingly, it doesn't have to be constant; and if done well, an infrequent but memorable cadence can be even more impactful.
I would advise teams to set a clear "in real life" (IRL) frequency that gets the whole team together on a fixed annual schedule. It should be at least 1-2 times per year, and for teams that can afford it, I would aim for 4. Moreover, I would guide teams to structure these in a regular format that feels different enough from the everyday work experience that the right bonds and connections can be formed.
At Coda, we assemble the whole team together 4 times per year (once per quarter) for a hackathon. Not only have some of our best ideas come of this tradition, but hackathons by nature also encourage unexpected teams to form. These connections make all the difference as people go back to their home offices. Read more in
4. IRL
⁠
.

⁠
Lesson 5
⁠
: Don't forget fun!

Work isn't just about work, but distributed teams can sometimes feel like they are "all business". So how can you have fun as a team without being in person? On the synchronous side, you can try hosting virtual lunch, Starcraft parties, group crosswords, book clubs, etc. On the asynchronous side, we've developed a few fun exercises like a daily "the more you know" and "icebreaker" tradition. Read more in
5. Fun!
⁠
⁠

⁠

How to use this doc

This doc has a section per lesson, pick the most relevant one to get started!
⁠
1. Virtual Space
⁠
⁠
⁠
2. Meetings
⁠
⁠
⁠
3. Communication
⁠
⁠
⁠
4. IRL
⁠
⁠
⁠
5. Fun!
⁠
⁠
Also, to see other docs from Shishir, check out
https://team.indiedemos.com/@shishir
⁠
...
⁠
👉 Next up:
1. Virtual Space
⁠
⁠
⁠

A few of the 25,000+ teams that 🏃‍♀️ on Coda.

⁠
a77eed08d9f915aabec0346b67a40b7ec93457a9864e51bde1e9239fad175c59624ad1bd252ec5041198bc8e9a52ce31b441ab4767fbb714b9172474278d0b29434f118c46abc5c7a7377f4ad1ea733677ca74d97bc8661e4bbfde8d9cdafabc285f5616.jpeg
⁠
⁠
Coda is an all-in-one doc for your team’s unique processes — the rituals that help you succeed. Teams that use Coda get rid of hundreds of documents, spreadsheets, and even bespoke apps, to work quickly and clearly in one place. This template is a Coda doc. Click around to explore.
Find out how to Coda-fy your rituals.
⁠
Connect with a Rituals Architect
⁠
⁠






















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.