Our six core values are:
In this section, we provide examples of how those values are expressed in our work. There are many more details we could have given but we have tried to keep this document as short as possible.
We care about our results and those of our customers.
Bringing value to our customers is our main goal. For example, we won't blindly add every requested feature. Although this would likely bring value in the short term, it wouldn't be sustainable and it would take us away from our mission.
We celebrate a feature we shipped or a coworker we helped, not how much time we worked on a particular day. There are no rigid rules about the organization of your day because you are trusted to do the right thing. If you are working too many hours, talk to your manager to discuss solutions.
The path to success is a tough one and you will face challenges along the way. Learn from your mistakes and keep going.
We believe we can achieve more if we prioritize helping others in the company. You are encouraged to share your ideas, experience and investigations.
It is normal not to know everything and you won't be judged for that. If you encounter problems, share information about them and ask for help.
Reach out to coworkers who seem to be struggling or help them find someone who can help them, even if this is not your primary task.
We encourage collaboration at all levels and between different teams.
Your tasks are important but you shouldn't optimize them at the expense of coworkers or users. For instance, if anyone is blocked by you for a question, approval or code review, you should prioritize getting them unblocked.
Similarly, you should try to minimize the negative impact of your changes on the tasks of other people.
We learn individually and collectively, from each other and from our customers.
Adding features and improving the product is done in iterations. Each iteration is a full development cycle from specification to shipping. This is the best way for us to get feedback about our ideas as soon as possible.
To make those iterations short, we identify the smallest possible change which adds more value than what is there now and do it first, leaving further changes for later. This is sometimes called a Minimum Viable Change (MVC).
You will often have responsibility for a project from start to finish, from idea to deployment. You learn about the whole process, not just about one particular step, and can see the impact of your changes.
In a small team, it is common to be responsible for several projects and not just do one kind of task (e.g. programming/review). As part of your work, you may have the opportunity to work on product specification, demos, infrastructure, technical support, blog articles, mentoring or open-source projects.
All documents, proposals and merge requests are subject to change and we don't need to make that explicit every time. The same is true of this document.
We want everyone to feel welcome and encourage diversity. We believe that this can contribute to other values like results and learning.
To hire people from all backgrounds, we want to avoid focusing on culture fit. While cultural bias is inevitable, we aim to minimize it by prioritizing values fit. It is not important that our hires have the same culture or background, only that they share these values.
When possible, asynchronous communication is preferred because it enables participation from people in a different timezone or who structure their day in a different way.
For example, discussions in GitLab issues are less demanding than meetings or even discussions in Slack where messages quickly get lost between other unrelated messages.
Make as much information as possible available to everyone in the company. This makes it easier for other people to contribute and make decisions.
Our main focus is on transparency within the company. While we can try to make more information public, this is not the priority. In practice, this mostly translates into open communication on Slack and GitLab.
Projects, issues and merge requests are always shared internally.
There are cases where transparency is not appropriate, for example: contract negotiations, sensitive customer information, and some of the hiring process.
Collaboration, inclusion and learning rely heavily on trust.
We are more interested in the lessons learned rather than the failures themselves.
Learning from mistakes is crucial and we think it's best done when the goal is not to blame other people. By focusing on the process or situation which led to the error, not the people, we can expect more cooperation from everyone involved and better learn from our mistakes.
When you realize you have made a mistake, apologize as soon as possible. The more work you do, the more likely you are to make a mistake, so you shouldn't feel bad when sharing it. Sharing mistakes is a great way to enable others to learn from your experience.
If you have an idea or insight, you might fear that you could be harshly judged if you speak up, even when what you have to say could be very beneficial to the company. By promoting psychological safety, we want to create an environment where you'll feel safe to contribute.
We want to avoid doing more work than needed whenever possible. This allows us to increase our progress and make our work more interesting.
Collaboration is meant to help us learn and get help. This doesn't mean everyone needs to be involved in every discussion.
Examples:
Solve your task in the simplest way possible. Simple means easy to maintain and understand, not easy to do.
For example, a 3-line simple piece of code is usually better than a cryptic one-liner. In terms of engineering, ninja code is what we want to avoid.
Writing specifications, documentation and commit messages can spare you the need to explain things over and over.
Sometimes you will have a valuable idea or small fix in mind which is unrelated to your primary task but that you can solve easily in the moment. In such cases, try to take the short detour right away because it will likely be much harder to come back to it later.
Not all mistakes need to be fixed with a process because adding or changing a process can potentially slow down many other tasks. We have to learn to accept that having some mistakes is normal.
GitLab Values were a large source of inspiration.
Key Values was also useful to cover more social and personal values.