I’ve been part of running two distributed startups over 9 years, plus 4 years of work across timezones at Spotify before then. The first few years were rough, and me and the orgs I were in fell into a lot of common pitfalls that took a long time to dig out of. I’ve been asked to share some learnings, so I’ll try to distill the most important ones here. If you just want the tl;dr, scroll down to “communication principles”.

My first experience with failed remote work was when Spotify’s New York office popped into existence, and was supposed to work together with Spotify’s Stockholm office. (I wasn’t a manager then, so this is just my perspective as one engineer in a large org.) Within each office, people could talk day in and day out and create amazing plans with high fidelity; but between offices was strung some IRC channels and some product managers thrown into the deep end. The end result was tons of frustration, people thinking the others were ignorant or rude, duplicate work, etc.

So this is how I was introduced to communication bandwidth asymmetry, or just you know, “silos”. People who were supposed to communicate between offices wouldn’t, because it’s easier to talk to the person next to you. And when you do, those not around you miss out on important information. This is true and the effect even worse when even just one person is in another location.

From this experience at Spotify, and then the following first few years at Lookback, we distilled a rule for remote work.

If even only one worker is remote, you have to pretend that everyone is.

Nevyn’s first rule of remote work

This might sound like “if even one worker is remote, you have to decrease the productivity of everyone”. This is not true, because the way you efficiently work remotely is by becoming communication and documentation experts, which helps everyone in any organization.

Communication bandwidth VS permanence

So let’s talk about communication bandwidth, and the different trade-offs you can make to create the perfect communication environment for your org.

The highest communication bandwidth is a face-to-face meeting with another person. The lowest communication bandwidth is an SMS convo where you get a reply a week after deadline. Then there’s of course a huge spectrum in between.

In my mind there are seven relevant communication lines within a tech org, in decreasing order of bandwidth:

1. Face-to-face
2. Video calls (or VR calls if you’re fancy)
3. Audio calls
4. Chat, like Slack or Discord,
5. Project tools, like Trello, Shortcut or Jira
6. Email, which I detest so I’ll pretend it doesn’t exist really
7. And then your company’s documentation tool, such as Notion, a wiki or your drive full of documents.

The upside to high bandwidth is that you can collaborate and reach decisions fast. The downside is that it is impermanent: things you figured out face-to-face is documented nowhere. Things you wrote in the company wiki is stored forever.

So there’s another axis to the selection of tools: there’s both high vs low bandwidth, and ephemeral versus permanent.

This leads to the second major learning, a way of implementing the first rule:

Pick the tool as far towards permanence as you can, while still communicating in a way that makes you comfortable and productive.

Nevyn’s second rule of remote work

If you’re new to this, you might still prefer a call or a chat about most things; and that’s fine.

And if you’re dealing with a time-sensitive, or hard to think or communicate about problem, you definitely need to pick a high bandwidth tool as well. That’s also fine.

But, it’s only fine if you also follow the third rule:

As soon as a conversation or task completes, document it in a more permanent location.

Nevyn’s third rule of remote work

For example, if product manager Holly runs into engineer Jane at the coffee machine and takes that opportunity to tell her that the button really needs to be green and not red, the information has been transferred, but the rest of the org doesn’t know, especially not the designer in Poland.

This is how it should go: Holly and Jane have a heated conversation in the kitchen, and then log the decision they’ve reached in the relevant card in Trello. Perhaps they even pinged the designer in Poland in the Trello comment; then she now knows, too!

This is especially true for things like a group conversation in Slack or a big video call where you think, “oh, everybody who needs to know already knows”. Well, you three months from now certainly doesn’t know anymore, and the new employee next week doesn’t know. So, go log it!

Tool choices

Okay, with the theory out of the way… Let’s get into the tools and talk about my personal preferences, and tool usage that has worked for me and my orgs.

Face-to-face, video call and audio call don’t really have a permanent effect in this system, so I’ll leave them out.

Chat

There are two big contenders in this space: Slack and Discord. Slack is great for organizations. Discord is great for communities. If you are running a tech company, you’re likely already using one of these and aren’t going to switch, so I’lll leave it there.

Project tool

This is a big one. You might not even be using one, in which case I highly recommend you do so. The important role of a project tool is to have somewhere to communicate about tasks, and to surface who is working on what. Is the endpoint for this going to be REST or GraphQL? Is the button red or green? Who’s doing the copy for this feature anyway?

Most tools I’m used to are centered around some sort of agile work flow. I haven’t read the manifesto, and I have no strong preference to exact working method, but working on small concrete tasks and iteratively figuring out what to do is really nice, and I encourage you to work like that.

Again, there are a bunch of different tools with different trade-offs. In this case, the tradeoff is structured versus unstructured.

As your organization grows, your needs for structure work will grow. Therefore, you’ll likely start somewhere on the left, and slowly migrate to the right. Or, you might feel structure is extra important in what you’re doing, and start somewhere in the middle.

• I really can’t recommend using a google doc. It lets you have really any format, but it doesn’t help you at all in keeping sane as things move around and happen in the org.
• Notion is super flexible. You can type up a document in free text talking about what to do, and suddenly slam a to-do list in the middle. Then in the next section, you can add a full kanban board, inline in the middle of the social media planning meeting notes document. You can use it as a support tool to just add a little more structure to what you’re doing, or or let it run your whole company with high fidelity. I love it.
• Trello feels like it started out as the anti-jira, or that one engineer being tired of pointing a web cam at a whiteboard of post-its to their remote colleagues. It’s an old and refined tool that just lets you move cards between columns. This can be incredibly powerful, and is often just what you need to organize even your one-person-shop’s work. This is my recommended starter tool for small organizations, or even one-person shops. However, when you become a larger organization and start feeling the need to group cards under “epics” or “milestones”, it starts falling short.
• Enter Shortcut (formerly Clubhouse). This has been my favorite tool for years. It’s basically Trello, but with all the agile tools slapped on: stories in epics in milestones, projects, estimates, iterations, roadmaps, team assignments, what have you. The downside is that it’s no longer flexible enough to let you sort cat pictures into tiers; on the upside it does the heavy lifting for you in terms of keeping you organized according to agile principles.
• If you’re a 100+ people organization, you are probably already using something like Monday or Jira, where you have a crazy amount of tooling and customization to fit any part of your organization. You probably also has one or even several people whose job is to maintain this tool.
• Bonus mention is GitHub Projects, which recently got a big upgrade and is really competent, snatching a spot somewhere in between Trello and Shortcut. It’s in beta, and is currently getting a lot of attention and upgrades.

At Lookback we use Shortcut; and at Alloverse we use a combination of GitHub Projects and Notion.

Documentation tool

I’m leaving the best for last. This is going to basically just be a huge ad for Notion.

What you have right now is probably a shared Google Drive with all the documentation and supporting documents for your organization. Maybe you have your code of conduct and vacation policy and meeting notes tucked away neatly in folders somewhere there.

The problem is that the important information isn’t likely being surfaced to those who need it. If you need the vacation policy, you’re likely heading over to your email to find the announcement email with the link to drive, instead of going to the drive and finding it quickly.

We found Notion at Lookback, and started using it as the documentation tool for everything: organization, processes, technical documentation, research, you name it. Fast forward a few years, and every new employee has told me: this is the fastest they’ve ever been onboarded, and the fastest they’ve understood a new organization. Everything is amazingly documented, and you can find exactly what you need when you need it.

At Alloverse, we continue to use Notion to great effect. We’re also an open source company, so I can actually share our Notion since it has a lot less secrets than Lookback’s. We’re not quite as well-organized, but it’ll do.

An important innovation over a drive is the sidebar. Every document is available in a hierarchy, which sort of surfaces the structure of the company. It’s easy to add more docs, and they’re all linked together like in a wiki, so it’s easy to cross-reference.

Use this to document all your processes, all your decisions, use it as a CRM, put all your meeting notes in there, write your blog post drafts in there, et etc.

Example usage: Note taking

For example, we use a table to log our weekly check-ins:

Each row is its own full document:

Example usage: Projects

Here’s how a project might be documented.

A main page describing what it is, and mainly linking out to other documents going into the details.

Communication principles

Finally, I want to share Alloverse’s internal “communication guidelines”, which is basically a summary of the above plus some things not directly related to communication bandwidth. Some, I’ve brought with me from shared learnings at Lookback. Some, we’ve formulated together ourselves at Alloverse. If you ignore all the above, and just bring these with you, you’ll be in a great place to run a distributed company.

• Openness. Prefer an open discussion in a public channel over private messages if the subject is our product or business, unless it specifically only concerns the two persons. This way, everybody can learn from the discussion, and others can chip in if they have relevant knowledge.
• Praise in public, feedback in private. Spread the love so we can all celebrate awesomeness together! If you have personal feedback, give it in private to the person or to your boss so that it can be resolved, instead of shaming people in public.
• Avoid communication silos. In a remote organization, it’s important to include everybody, or important information gets stuck in silos. If you have a conversation IRL or in voice/video/VR, take notes and log it in the appropriate tool (Discord, Shortcut, Notion, Drive) so that others can take part in your decisions, findings and ideas.
• Use the right forum. Depending on the nature of your discussion, different tools might be relevant:
  • Transient and async collaboration: Discord. You’re collaborating, or notifying people about something that is relevant in the moment, but doesn’t need to be found or referenced to in a week or two.
  • Tasks (product or management): Shortcut. Use comments and mention in the correct card. If a discussion in Slack turns into insights, save those in clubhouse so they can be referenced later when you’re working on the thing.
  • Documentation: Notion. If things need to be referenced or found, write a document in Notion. If you’re collaborating with external partners, use Google Drive (but use real Drive documents, not docx, since support for it is buggy 😥).
  • Sync collaboration: Slack/Discord video, pop.com (great for pair coding) or goteam.video (great for quick hangouts). E g a meeting or pair programming. Don’t forget to summarize your findings in a text tool afterwards if that’s relevant.
  • Long-form discussion: Email
• Manage your pings. Turn on Do Not Disturb outside of your working hours, and don’t check your work email outside of work. This way, people can ping you from their time zone or work hours without worrying about disturbing your personal life.
• Respect people’s life work balance. Don’t expect people to reply right away, and don’t expect people to reply at all outside of their work hours.
• Set timing expectation. When asking for something, let them know how urgently you need it.
• Decision making. Designate who really owns the task or project, so that after a conversation, it’s clear who makes the decision.

There are many other topics that I could cover, but this post is too long already. These include:

• Remote presence
• Team spirit, having fun together, “water cooler moments”
• Avoiding feeling surveiled
• How to make sure everybody helps out with keeping things organized and documented
• Check-in cadence, text vs video
• etc…

I hope this has been helpful! If you have any questions or comments, ping us on twitter at @nevyn or @alloverse, or join the conversation over at our community Discord!