<aside> đź’ˇ At remote we lean heavily into asynchronous communication daily. This guideline is to support all aspects of communication at Remote and to ensure we lean heavily into our values, as well as our DEI principles. We encourage everyone at Remote, regardless of who and how you are communicating to utilise these guidelines and to create effective and inclusive daily communication.
</aside>
Do not make jokes or unfriendly remarks about race, ethnic origin, skin color, gender, sexual orientation, body or physical appearance, accents, and or religion/spirituality. We want everyone at Remote to feel safe and create an environment where everyone feel like they belong.
Use inclusive language, review our examples of inclusive language or contribute to them.
We appreciate all feedback, over-communicate when you are experiencing a problem, or when you require help. We encourage you to do so in a public slack channel, to ensure others can contribute the conversation as well.
It's important that you don’t display surprise when people say they don’t know something, as it is important that everyone feels comfortable saying “I don’t know” and “I don’t understand.”
If you feel you have been treated poorly by a co-worker, discuss with your supervisor or someone from the People Team.
Always be kind.
<aside> đź’ˇ Everyone can remind anyone in the company about these guidelines. If there is a disagreement about the interpretations, the discussion can be escalated to more people within the company without repercussions. If you are unhappy with anything (your duties, your colleague, your boss, your salary, your location, your computer) please let your manager or the People Team know as soon as you realize it. We want to solve problems while they are small.
</aside>
Make a conscious effort to recognize the constraints of others within the team. For example, sales is hard because you are dependent on another organization, and development is hard because you have to preserve the ability to quickly improve the product in the future.
<aside> đźš« Remote has a zero-tolerance policy regarding our standards as described above.
</aside>
At Remote we have standardised language to English. It's widely spoken and as close to an "international language" as it's possible to get, being the official language for both sea and air. External communications should be done in US English (en-us), but internally you can speak in which ever variant you're native in or most identify with.
When using Slack or similar, try to communicate as much as possible in channels that everyone can access rather than private channels, whenever that can be avoided. We prime visibility and open dialog.
Internal discussions should not happen over email or in private Slack DM’s if the conversation doesn’t need to be private. Emails and DMs promote closeted, opaque discussion and remove the ability for other team members to collaborate. The same is true with private Asana boards. Hence, boards where we do not disclose protected information, should always be open. Always communicate openly whenever possible. As we scale, this is a vital best practice.
It's also important for team leaders to be involved in the most critical discussions, things that define what the team is doing or actions that will impact others. For this reason the team leader is expected to over-communicate and often be the spokesperson for what goes in and out of the group. Team leaders should not be bottlenecks. If someone isn't available and the subject you need to be addressed isn't sensitive, then consider radiating information through the available people transparently and openly in order to move forward faster. Delegation and transparency are critical to avoid waiting times or idle tasks.
The best way to do this is to have your conversations in their relevant context (Asana task, GitLab issue, Figma document) or in public Slack channels. For more, please watch:
Always favor asynchronous(async) communication over synchronous(sync) communication. Sync communication is costly, interrupts peoples’ thought processes, and hinders productive execution. When there is a need to use sync methods, please make sure it is for the right reasons. For more: