These are the best practices for how we currently implement our culture principals. Use these in day to day work as a framework for decision making. We prefer best practices over strict protocols. We believe in building a work culture, not work processes. We set a process only when we feel the lack of it hurts us, and we change or eliminate a process the second we feel it does not benefit us.

​
We set goals

We do this to align on what we define as impactful. We also do it to understand if we are on the right track. We don’t obsess about goals, but it’s an important tool for learning. Sometimes you learn that your goal is wrong, or that you haven’t measured it correctly. Other times, you understand that you didn’t make the right decisions, and must adapt. And sometimes, you win, and should celebrate!

​
We experiment and iterate

We are humble enough to admit that it’s really hard to know what will make an impact. We see every initiative as an experiment, an assumption we need to test. A good experiment is fast, and has clear results. This means that we try to reduce the scope to the minimum that could help us determine if our assumption is correct. If it is, you can do another iteration (which is a new experiment with new assumptions). A good example is the mental framework we use when scoping a new feature. We assume we will end up deleting it, so we better spend as little effort as possible on the first version. If it is successful and we don’t delete - it’s time to iterate and improve.

​
We leverage data

This is pretty straight forward - we set goals, we experiment and try to make an impact, we leverage data to understand what worked and what didn’t. We actively think about what data we now need to answer our questions, and which new learnings we can produce from it.

​
Default to action

As a small startup, we won’t win with resources. We will win with speed and flexibility. When you need to make a decision on how or whether to do something, ask yourself if:
  1. The cost of error is low, or this action is reversible
  2. It makes a positive impact on our goals or our ability to achieve them
If the answer is yes - just do it. Don’t wait for permission or second opinion, don’t delay, don’t overthink. If the answer is no - and this is a blocker - it is your responsibility to communicate that it’s a blocker, ask for context, push towards action.

​
Default to writing

Writing enables us to work async, not rely on our memory, include new team members in past discussions, and avoid unnecessary meetings. If you want to consult on a feature implementation, sync on open issues in the community, or share creative ideas on how we can conquer the world - do it in writing.

​
Default to share

If there isn’t a very good reason to restrict, default to discussions in public channels, writing in shared platforms, and actively sharing your work and thoughts. If you had a conversation in DM that might be remotely relevant to the team, share it. Sharing provides context to the team. It enables you to receive feedback, and enables others to be independent and find answers without asking anyone. We also don’t believe in “unveiling”. Share what you are working on, get feedback as early as possible. It’s always better to consult on work in progress, before wasting time and energy on implementation. However, the fact you shared something does not mean others are expected to respond. Be explicit, ask for feedback from specific people you think are relevant. Respect their priorities and give them reasonable time to respond.

​
Respect async

We are not always in the same time zone and place. Even when we are, we should be able to deeply focus on tasks without interruptions. This means that by default we don’t expect each other to answer messages immediately, just in a timely fashion during the work day. You are not expected to be available all the time, definitely not outside of working hours. Feel free to close Slack and catch up later. If you are blocked or have an urgent matter - be explicit about it, call the person you need.