How we think about remote work

Messaging

We use Slack as the primary Operation System for our messaging. If some information should be remembered, we transition it to Notion. It's easy to shove all communication into Slack, it's much harder to work efficiently and communicate well.

Here are a few ways we achieve that:

Channel purpose should be in the name

We add prefixes to all channels to indicate its purpose. Every team member should be able to see a channel with unread messages and be able to triage how urgent it is or what type of work is involved with it by just looking at the name. Here are some of the prefixes we use:

• bot- system notifications that usually don't require action
• alert- system alerts that usually require action
• ext-, cust- discussions with customers
• collab- discussions with vendors/partners
• proj- temporary working groups about a project
• all- permanent channels to discuss topics
• inc- incident working groups

When to thread, post, or DM

There are many ways to utilize threads, channel posts, and DM's to get work done. Here is a general matrix for when to use each:

Threading

• Good for staying focused on a topic, having multiple conversations in one channel
• Bad at getting quick responses, giving visibility to members not in the thread

Posting in Channels

• Good for informing all members in that channel, preparing for a thread
• Bad at targeting a message to certain members, asking for individual collaboration

DMing an individual

• Good for asking for collaboration, keeping a discussion private
• Bad at informing all members, being searchable for all members

Tasks

We use Linear to manage all tasks. If you are asking for another team to help with a task, you should create a Linear ticket for their team. It's easy to create a ticket from a Slack message by clicking into the menu and selecting “Create Linear Issue”. This also syncs the Slack thread of that message to the issue, depending on where the discussion happens.

The anatomy of the perfect ticket

• Title is short and succinct
• Description contains every details that the person implementing would need
• Think about questions they would ask, and already answer edge cases
• Break down bigger issues into sub-issues
• Include severity so the other team knows how to incorporate into their existing work

Working Hours

Although we are remote, we believe that centralizing our working hours is helpful to improving collaboration by increasing the amount of back and forth that can happen between members.

We currently hire within the America's to keep the whole team's working hours naturally aligned. Generally 15:00-19:00 GMT is when we are online and more accessible to each other. Specific teams may align expectations of working hours outside of that window.

We don't mandate work on evenings or weekends. Those are your personal times, so you can choose to do whatever you want. If you feel like you have to consistently work during those times just to keep up with goals or demands, please raise this with your manager so we can think about reducing work or hiring help.

Meetings

There are may good reasons to book a meeting. Here are some helpful guidelines for doing that well:

• Try to solve it async, if that fails, then book a meeting
• If you are demoing something, record a video and share on Slack instead
• For pairing, jump into a Slack Huddle rather than a meeting room
• Meetings default to camera on, Slack Huddle default to camera off
• Cancel recurring meetings if they aren't useful and consider setting an expiration

Handoffs

The way plans and requests are passed between team members can make or break a small, remote team. We must get feedback from each other as soon as possible to validate ideas, and we must remove potential blockers from each other before work is started to not break up the flow.

RFCs play a huge role in this. This is where we put ideas onto paper and get feedback. It is also where we identify roadblocks and hurdles to completing the task. The deeper the RFC goes, the less surprises and scope creep we have later during the implementation. This is also an important way we expand our “group brain” and don't lose an idea after thinking of it (Slack is not good for this).

Another way to accomplish this is by creating really good tickets (see tickets section above). Most notably, by anticipating questions and roadblocks that the implementer might have and solving before the work is started, it means that someone can grab the ticket, understand everything, and build everything in one stream. No need to stop because of missing information.