How we work

Remote

Resend is a remote company. There are no plans for this, but even if there are some local offices in the future, the core operations of the company will always facilitate remote work because we believe in it as a way of working.

Being remote means we will default to async forms of communication like writing RFC's instead of booking a meeting, using Slack channels instead of waiting for synchronous stand-ups, and logging tickets in Linear instead of an office white board.

Being remote does not mean we only work independently. Especially at our stage, it's important to be deeply in sync and iterating constantly. To do this, we're careful to keep working hours inside of the America's timezone, plan 2 offsites every year for in-person time together, and often switch to synchronous work when its appropriate (incidents, beginning complex problems, etc.).

Curiosity over ego

"Egotism is the anesthetic which nature gives us to deaden the pain of being a fool."

― Dr. Herbert Shofield

We see many benefits to confidence, conviction, and bravery, but no value in ego. It hinders collaboration, squashes innovation, and destroys morale. It has no place at Resend.

Instead, we encourage a confident curiosity approach to work. With confident curiosity, we're brave enough to share our values, views, and convictions, but open enough to have empathy for other perspectives and to learn from other ways.

Two very simple ways to put this in practice is to:

• Ask before you tell
• Be the last to speak

Challenge the status quo

Resend is a challenger brand. We aren't inventing email, we aren't inventing developer experience, we aren't inventing dark mode. In many ways, we're simply taking known patterns and applying them to a space that has not traditionally received that treatment.

This requires us to be constantly challenging the “normal” approach in the little things. We must see every detail as a way to delight and wow, which won't happen if we're sheep blindly following a leader.

This requires asking hard questions like “why,” sometimes over and over and over again, until we get down to the most primitive conclusion and then build from that primitive.

Show when possible

"Don't tell me the moon is shining; show me the glint of light on broken glass."

― Anton Chekhov

Life is more than pixels, and communication is more than text. Both for users and team members, we aim to engage multiple senses when delivering an idea.

We do this with customers by including screenshots, screen recordings, and code examples in the docs. Just a wall of text is not adequate to helping users solve their issues. Let me see, hear, and feel it.

We do this with other team members by reinforcing feedback, ideas, and suggestions with references or examples. Instead of just saying “This dropdown is hard to use”, try describing your experience using the dropdown and share references of dropdowns you like or a screen recording of you using the dropdown to show why it may be hard to use.

Use the resources available

We need each other for many things, but one of those is not answering questions with answers already available. One example of that would be asking a team member a question that is already documented. Another is asking for them to find something for you that is publicly available. Another is for a team member to train you on a technology or system just because they know it.

In almost all of these cases, there should be a best effort given to helping yourself with the available resources before going to a coworker.

Some helpful tips of ways to solve your own problem before asking:

• Search Slack and Notion to see if someone has already answered it
• Search the code and try to read it before asking how a feature works
• Use AI for writing help, generic technical questions, or translations

Everything requires iteration

We would be foolish to think that we can get things right the first time. If we all accept that our first attempt may be completely wrong, then there is grace and understanding for shipping or sharing half-baked work, especially internally, and receiving feedback so the iteration can begin.

If we wait too long to share with others, we can often get stuck in our heads and waste time. Many times, the questions we labor over would be answered in 10 seconds if a few more eyes were on it.

This is also why performance is measured more by how well feedback is requested and incorporated, than by how good our work is on the first attempt.

Get feedback quickly and be ready to make your work better with it.