How we communicate at RevenueCat

An adaptation of our internal guide with principles and best practices for effective remote and async communication.

We’re a remote-first company that allows people to work from (almost) anywhere in the world. It’s important for us to practice clear communication that helps us stay connected and get things done.

For this, we default to asynchronous communication and are as open as we can be by communicating through our internal tools, such as Notion and Slack, placing an emphasis on ensuring that conclusions of conversations are recorded.

This blog post is an adaptation of our internal communications guide. We’re sharing it publicly because we hope that it’ll serve as inspiration — whether for your own company or because you’re interested in joining us. I was also heavily inspired by GitLab’s Communication Guide in the initial version, and I believe sharing this internal material can be helpful to others building remote companies. We’ve chosen to not edit much out, so the result here is quite a long blog post, but we hope it’s all the more useful for it.

Before we get too far into the nitty-gritty details, let’s begin by examining our principles for effective communication.

Our communication principles

These principles do not exist separately from our company values — rather, they are derived from them and are examples of us “living” our values.

Everyone has a right to focus

“Asynchronous communication” means we’re all getting information from each other at a time when we can handle it — usually not “live.” This is important for the very simple reason that most of us need head space to focus on what we do.

Asynchronous also refers to the fact that we’re not expected to immediately respond if, for example, someone emails on the weekend. Just reply on Monday. Likewise, if something is urgent, we’re encouraged to go ahead and ping someone on chat when we need to.

Be judicious with designating something urgent — more things feel urgent than are actually urgent. Escalating urgency unnecessarily is an easy way to disregard someone’s right to focus.

Be transparent

Transparency is part of our Balance and Own It values. Secrets breed mistrust, and mistrust breeds contempt. Transparency can be difficult to maintain, because it can mean leaving yourself open to unwanted criticism or create unnecessary concern. These can be downsides of transparency, but on balance a transparent culture will be a healthy and mature one.

People are surprisingly good at receiving bad news. Surprises, often created by a lack of transparency, however are more difficult to handle.

External facing transparency is just as important. Sharing and interacting with the developer community is part of what makes people love our brand. Sometimes though, there are some things that shouldn’t be shared publicly: undisclosed investors or investments, customers, some of our secret sauce, etc.

Go public, not private

Don’t be afraid to ask a lot of questions and open those questions to everyone. This means using Linear, Github, Google Docs, Notion comments, email distribution lists, or public Slack channels versus person-to-person emails or private messages.

If you urgently need an answer from one person (and you know that person is the one with the answer you need) mention them by name. This still gives others the opportunity to learn and chime in.

As much as possible, communication should happen in public channels rather than private group chats. This creates a public record that is searchable, as well as defaulting to transparency. However, if any conversation becomes sufficiently complex, with more than a handful of back-and-forth’s, you should move it to a different medium.

You should document the outcome of private conversations and share them in a public medium.

Provide context

If you mention something (a pull request, issue, commit, web page, comment, etc.) please include a link to it. This allows folks who are low on context to be able to help.

When bringing people in, be specific

It is OK to bring an issue to someone’s attention with a CC (“cc @user”), or adding them to a channel, but CCs alone are not enough if specific action is needed from someone. The mentioned user may read the issue and take no further action. When you need something, @ mention them and be explicit with your request or communication.

Be a human

All these rules can seem a little… robotic at first. It’s also important to actually be a human being, not just disembodied text. If you’re on video chat — which you can and should do, especially if you find you’re going back and forth over chat — it’s okay if your kid or partner etc. pops their head in and says hello, because this is one of the great perks of remote working! Plus, this way everyone knows you’re not AI generated.

Channel bandwidth and synchrony

Like most startups, we have a bunch of different channels for communicating, for better or worse, with different levels of synchrony and bandwidth. Depending on what you are trying to communicate, when you need a response, and the parties involved, there may be a better medium than another.

For anyone unfamiliar with the term, “bandwidth” in this context refers to the interactivity and richness of the communication channel. High bandwidth channels are rich, and allow for a greater two-way flow of information. Hopping on a Zoom call with someone is a high bandwidth form of communication, sending a Slack message is low.

On a similar spectrum is synchrony: recording a Loom video is very async. A Zoom call is not.

At RevenueCat, we default to async and high bandwidth and work backwards from there as needed. Limit the use of high bandwidth and synchronous channels, like Zoom calls, for things like 1-1s and for tackling complex and immediate problems.

The channels we use and how to use them

Slack

Slack is for informal communication. Approvals and decisions should still be documented in Google Docs/Notion/Github/Linear/Email etc.
In most circumstances you should avoid private messages. Using a public channel and mentioning the person you want to reach is always preferred. This ensures it is easy for other people to chime in, involve other people if needed, and learn from whatever is discussed.
Avoid private group DMs. Avoid creating private group DMs for internal discussions. It’s disturbing (all users in the group get notified for each message). It’s not searchable. It’s not shareable: there is no way to add people to the group (and this often leads to multiple groups creation). They don’t have a subject, so everyone has to remember the topic of each private group based on the participants or open the group again to read the content. History is lost when leaving the group. Instead, create temporary public or private slack channels then archive them when you are done
Don’t expect presence. Slack messages should be considered asynchronous communication and you should not expect an instantaneous response — you have no idea what the other person is doing. If you need that, it’s an emergency and you can escalate to a phone call.
Be direct. If you are sending a private message, don’t start a conversation with “Hi” or “Hey” as that interrupts someone’s work without communicating anything. If you have a quick question, just ask the question directly and the person will respond asynchronously. If you truly need to have a synchronous communication, then start by asking for that explicitly. e.g. “I’m having trouble understanding issue #x, can we talk about it quickly?”.
Use threads. Especially in channels where multiple topics may be under discussion in parallel. Threads aren’t perfect, but they allow a channel to not be blocked by one topic.
Use Do not disturb. Please consider enabling Slack’s Do not disturb functionality so you don’t get interrupted, for example, when you’re focusing.
Disable notifications on mobile. Slack is a work chat tool, not an always everywhere chat tool. Do not feel obligated to respond to Slack messages when you are not working. Disabling slack notifications on mobile is a healthy way to keep the lines between work and life clear. Ensure you have some other contact method for emergencies (phone, WhatsApp, etc).
Don’t use @here or @channel. Almost never appropriate.
Use email. Seriously. Email is probably better.
Be mindful of people’s OOO status. If you are aware that your teammate is on vacation, avoid mentioning them in a high volume channel. It will be difficult to find the information or question when they return. If you need to ensure they refer back to the thread, ensure to send them a link to the relevant Slack message through a direct message or email.
Leave channels, archive channels. It’s not rude to leave a channel. When you’ve had your questions answered or are no longer interested, feel free to leave the channel so it won’t distract you anymore. Also, archive channels aggressively. It can get out of control.
Fill out your profile. It’s helpful.
Use Channel Naming Conventions – It’s very useful to use naming conventions for Slack channels. It helps with grouping but also forces the room creator to really think about the purpose of the channel. The prefixes we use are:
1. #topic- This is long term channel for discussing a specific topic.
2. #feed- These channels contain mostly programmatically generated messages, but also accompanying conversations.
3. #team- These are loosely mapped to our org structure but they are team water coolers
4. #guild- These are channels dedicated to cross-team groups of people with similar skillsets
5. #fun- For random, fun, or silly channels.
6. #interview- Private channels created for coordinating interviewing an individual. These are archived after the interview is over.
7. #feature- Channel for the cross functional work of a feature. Should be limited time.
Pull the emergency brake on long threads. Sometimes, questions posted on Slack become a long back and forth between various people where no one shows real ownership for making a decision. This is none of the participants’ fault – often, people just want to help. However, it can make catching up with the conversation really hard, especially if you start working and see a thread with 10+ comments on it. Moreover, very likely a long Slack thread isn’t the best means to solve any question. Either, someone should collect all of the various options, pros and cons in a document and get people to comment on it (which is more structured and easier to digest than a Slack thread, and also allows ongoing updates), or if the topic does indeed require a lot of synchronous debate, someone might have to set up a live discussion. For these cases, we have an emergency brake. Anyone who sees and feels overwhelmed by such a thread (even if they weren’t a participant) can “pull the brake” by posting the :noslack: emoji to the thread.
Geekbot. Geekbot is our slack driven standup system. This is the company heartbeat and can be a good place to start your day with syncing up with people. Try not to get worried about looking busy or productive, it’s easy to get self conscious about it. Try to just be honest and brief about what you are working on. It helps to create a quick feed of what’s going on. Geekbot’s are configured on a team-by-team basis.

Google Docs

Google Docs are a great way for documenting and working through tough decisions in a high-bandwidth but asynchronous way.

Workflow

Typically, the workflow for a document-based decision is as follows:

The owner of the document drafts the decision document, linking out to further sources of information.
The owner requests comments and/or amendments from a small circle of core contributors. The document is still in a “draft” stage at this point.
Once comments have been resolved, the owner marks the document as “for review / comments” and requests comments from a broader set of stakeholders. Depending on the topic, this could be the cross-functional team, all of engineering, the whole company, etc.
The document stays in review for at least three days to give everyone a chance to comment.
After review, the owner chooses whether or not to address the comments and resolves them (even the ones the owner decided not to address).
In the case where the decision maker is not the owner, the decision maker makes the decision and it is recorded in the document.
The document is then marked as final.

Notion

Notion is the place for curated information that lasts a long time. If it’s a temporary thing, or something that needs lots of collaborative editing, use Google Docs.
If some communication needs to be persisted forever and made visible to others, use Notion.
Leave comments, ask questions and tag others directly in Notion docs.

Linear, GitHub, Figma

Linear and GitHub PRs allow commenting on individual work items. Figma allows commenting on designs. Communicating via comments on these is preferred if the scope of the comment is limited to the respective work item. If a discussion in the comments results in a bigger scope question, it should be escalated up to the next level. For example:

Comments on what is the “right implementation” for a given ticket can be PR comments. However, if the question becomes about what is the right functionality to build, then a question should be asked on the ticket (especially since not everyone reads PR comments).
A Linear ticket may have comments on what the right approach is to a given problem. However, if the problem itself is being put into question, then it may be better to escalate that question to the level of the product spec.
Figma comments may be about if the fields in a form are correct. However, if we are missing an entire flow, we might need to create a new ticket / add something to the product spec, etc.

Email

Use distribution lists. A big problem with email is the lack of transparency — whoever wasn’t on the original email does not see the conversation, and future RevenueCats will not be able to retrieve the context of decisions if the discussion was only conducted via email between individuals. The same is not true of distribution lists, which store all conversations in Google Groups. Consider creating a distribution list for any team or initiative where you expect important decisions to be taken via email, and use broader distribution lists for broadcasting information or for proposals you want to solicit broad feedback on.
Send one email per subject, as multiple items in one email will cause delays (have to respond to everything) or misses (forgot one of the items). If mid-thread you discover something completely separate that needs to be addressed, start a new email thread and make sure all the appropriate people for this new thread are included (which may be more or fewer than the original email).
Use a good subject. Subjects can save a lot of time for folks who have a high volume of email. There are few subject line tricks that are useful as well:
1. RFC – Request for consideration. Generally means a long email that may or may not need to be read and that you are requesting feedback from a group.
2. FYI – Informational email that may not need to be read.
3. [Something needed] By EOD Wednesday – Putting a deadline in the subject can be handy.
Always reply to emails by replying to all.
Emails are asynchronous, for example, if someone emails you on a weekend it is fine to reply during the workweek.
If an email is or has become urgent feel free to ping people via chat, phone, etc referencing the email. However, limit your number of “did you get my email?” DMs.

Google Calendar

We recommend you set your Google calendar access permissions to ‘Make available for RevenueCat – See all event details’. Consider marking the following appointments as ‘Private’:

Personal appointments.
1-1 performance or evaluation meetings.
Meetings covering sensitive information.

There are several benefits and reasons to sharing your calendar with everyone at RevenueCat:

Transparency is one of our values and sharing what you work on is in line with our message of “be open about as many things as possible”.
Due to our timezone differences, there are small windows of time where our availabilities overlap. If other members need to schedule a new meeting, seeing the details of recurring meetings (such as 1-1s) will allow for more flexibility in scheduling without needing to wait for a confirmation from the team member.

If you add blocks of time spent on recurring tasks to your Google Calendar to remind yourself to do things (e.g. “Check Google Analytics”), consider marking yourself “Free” for those events so that coworkers know they may schedule a meeting during that time if they can’t find another convenient time.

You can also set visibility settings on an event by event basis if higher level of privacy is preferred. i.e. adding personal events to your work calendar which can be useful at times.

Setting your own availability

Google Calendar has some nice features for signaling to your colleagues the times that you typically work. If you have an interesting schedule, it’s extra important to use these features to smooth the scheduling process.

Put your planned away time including holidays, vacation, travel time, and other leave in the RevenueCat Team Calendar.
Add the OOO to your personal calendar as well, this will auto-decline meetings.
Set your working hours in your Google Calendar settings. This allows you to block your out-of-office time for all to see, which is helpful for scheduling across multiple timezones.
Use Slack do-not-disturb mode and set Slack statuses to indicate availability.

Zoom and video calls

Overall, we should always aim to minimize the number of synchronous calls we have. Anyone setting up a call should first consider if there is an asynchronous way to achieve the same outcome (the only exception is regular 1:1 meetings). Calls have several big drawbacks: they reduce people’s flexibility to control their own schedule, they lead to context switching and disrupt flow, and they don’t work well with different time zones in a globally distributed company. Moreover, calls with many participants are expensive and not utilizing our capacity effectively, since it’s very likely that not all participants are actively engaged at all times.

When and how to use a video call

Use video calls if you find yourself going back and forth via email or over chat. Rough rule: if you have gone back and forth three times, it’s time for a video call.
In general, calls are better the fewer people are on them, because only one person can speak at a time, so large meetings limit each individual’s bandwidth. For calls that would require a long list of attendees, consider using a document or a Loom instead.
A video call can help clear things up quickly when you are blocked, but don’t default to it. Try async and written forms of communication first.
For meetings that are scheduled via calendar make sure you include some video call link or dial in information. If there are any documents or shared notes that you’ll be discussing, make sure they’re linked to in the meeting invite as well and everyone has access.

Running effective calls

Make sure the call (unless it is purely social) has an agenda. A good agenda doesn’t just list the topics you want to discuss, but the outcomes you want to achieve. Merely discussing a topic isn’t a valid objective, making a decision is.
Maximize asynchronous preparation. Documents can be shared before a call. If a proposal should be presented and discussed, the proposal itself can be shared as a Loom beforehand. For a retro, team members can collect their proposed discussion topics asynchronously beforehand, so that the call itself can be reserved for actually discussing.
Document the outcomes and share them to a public medium. If it’s not clear who owns the meeting and should be documenting the outcomes, agree on it at the beginning of the call. For recurring meetings, e.g., weekly initiative or team check-ins, it can be good practice to keep a running agenda document in which then also outcomes are recorded for each of the agenda items.
Consider recording the call. Especially for calls that may be relevant to people that could not attend, record the call (using Grain or Zoom’s built-in functionality) and share the recording. Please note that for Zoom cloud recording, it is best to download the recording and post it somewhere where it will persist (e.g., on Slack or Google Drive), since Zoom deletes recordings after 14 days. A recording should not replace documenting the outcomes (not everyone will have time to watch a full 30 minute discussion if all that’s relevant to them is the one decision that was made).

Communication expectations for video calls

Meetings start on time and you shouldn’t wait for people.
Use headphones. Ambient noise, echo, and bad audio can make the experience less than enjoyable. If you need a good headset, you can order one and expense it. If only one person is missing headphones, that’s ok, but the more folks using speakers the worse it gets.
Camera on. Use your webcam, point it square at your face, and make sure you don’t have any major lighting problems. Reading faces really improves the quality of the conversation. There are exceptions to this, and don’t feel you can’t attend a call because you can’t be on video for some reason, just that it’s preferred.
Default to unmuted. Background noise happens so we get it if you have to mute yourself every once in a while but try to find a quiet workspace for calls when possible. Turning on the mute creates a tiny barrier to serendipitous interruptions that can lead to creative collaboration.
It feels rude in video calls to interrupt people. This is because the latency causes you to talk over the speaker for longer than during an in-person meeting. We should not be discouraged by this, the questions and context provided by interruptions are valuable. This is a situation where we have to do something counter-intuitive to make all-remote meetings work. We want everyone to contribute instead of a monologue. Just like in-person meetings, be cognizant of when, who, and how you interrupt.
Have good bandwidth — It’s your responsibility to make sure you have a stable internet connection. If you need help ensuring this in your primary work place, the company can help. If you know you are likely to encounter issues, plan to call in over voice, or move the meeting until you can participate effectively.

Loom

Loom (or other asynchronous video tools) are great if you want to broadcast information to a broader group of people in a way that feels more natural and less “polished” than a document. They can also be great for making video calls more asynchronous, if the broadcast part of the discussion is shared upfront as a Loom. They are also great for product demos or to showcase bugs and problems.

Which channel to use when

When deciding where information should live, it can sometimes be overwhelming. Here is a simple set of rules:

Communications — Email, Slack, Zoom, etc.
Documentation — Notion. These are things you write infrequently, but read often.
Collaborative Documents — Google docs. Anything you are collaborating on with others and is a living document should live in Google docs. Possibly, on completion, it should go back to Notion.
Work Items — Linear. Anything that represents a unit of work, a feature request, a scheduled thing to do or fix, needs to live in Linear. Discussion around that particular discrete issue can happen there.

That concludes this edited summary of our communication guidelines at RevenueCat. We hope that it gives you a flavor for our culture and values, and perhaps it’ll come in useful for building similar guidelines where you work.

What do you think? Do you do things differently? How do you ensure effective communication when working remotely? Join in the discussion on LinkedIn or Twitter.