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
• cust- discussions with customers
• int- internal discussions about a specific customer
• collab- discussions with vendors/partners
• proj- temporary working groups about a project
• all- permanent channels to discuss topics
• team- discussions for teams within Resend
• review- channels for work or change reviews
• club- channels for social and recreational activities
• inc- incident working groups

Knowing what channel to post to can be overhwelming. If you are unsure, ask a teammate or simply post to #all-discussions.

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. Don't delegate tasks in Slack that can't be done immediately. It's easy to create a ticket from a Slack message by clicking into the menu and selecting Create Linear Issue. This creates a bidirectional sync for any updates, regardless of whether they happen in Linear or Slack.

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 finding consistent moments for synchronous work is helpful for collaboration.

Generally, 14:00-18:00 UTC is when the entire team has overlap so we ask all team members to aim to be available for synchronous work during this period. Specific teams or members may align expectations of non-standard working hours with their team.

We don't expect work in the evenings or on weekends in addition to your standard day, except for edge cases like incidents or launches. Some team members may work off hours to gain synchronous time with the team or based on pre-discussed requirements with their team. If you feel like you have to consistently work extra just to keep up with goals or demands, please raise this with your manager so we can consider reducing work or hiring help.

Meetings

There are many 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).