Thanks for checking this out! This doc gives an overview of how we communicate internally at Warp.
Two things to consider with every communication at Warp are
The golden rule of communication at Warp is to ask yourself if you’d like to receive a communication you’re about to send. This is primarily a question of tone rather than content.
In terms of content, we encourage direct, to-the-point, pragmatic conversations.
In terms of tone, try to err on the side of being positive, encouraging, extra-respectful because it’s very easy for tone to be misinterpreted in slacks, emails, and other written communication. This happens, not infrequently, even when the sender of the communication has no ill-intent.
We aren’t trying to create an environment where every communication ends with an emoji or anything like that - it’s just worth remembering that text is easy to misinterpret and being a little extra careful can build up good will.
A corollary to the golden rule is that whomever receives communication should, by default, assume that the sender has positive intentions. If you didn’t like how you were communicated with, you should definitely give feedback to that effect, but do not assume off-the-bat that there was bad intent on the part of your co-worker.
If there’s a pattern of bad communication, or a lack of responsiveness to feedback, that’s a different issue, but we are trying to create a culture where we trust each other and assume the best of our co-workers rather than the worst. Misunderstandings are much more likely than malice or even bad manners.
It's important to pick the right communication medium. The right question to ask here is how can I get my message to the right people in a way that allows for the right amount and form of discussion.
Slack is the default medium for for internal communication. See guidelines on slack usage below.
Email is the default for external communication (where at least one participant in the conversation is outside of Warp).
Loom or CloudApp are great for broadcasting screencasts and are often the best way of showing progress to the team as we build features or debug issues.
Meetings are for deeper discussion and decision-making where written communication would be inefficient.
Documents and Wikis are for creating written artifacts. DO NOT use slack channels or threads in place of creating documents when we need a structured, living container for knowledge OR for when the commenting mechanism in a doc is a better way of getting feedback.
Visuals and Designs are often the best way to communicate (as opposed to communicating with words). If something is better said with a picture, mock, prototype or presentation - say it with one.