Engineering Team Core Values

Our six core values are:

  1. Results
  2. Collaboration
  3. Learning
  4. Inclusion
  5. Trust
  6. Efficiency

Core Values

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.

​1. Results

​We care about our results and those of our customers.

Customer results come first

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.

Results are more important than hours worked

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.

​2. Collaboration

We believe we can achieve more if we prioritize helping others in the company. You are encouraged to share your ideas, experience and investigations.​

Ask for help

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.

Help others succeed

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.

Flat organization

We encourage collaboration at all levels and between different teams.

Optimize for the company

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.

​3. Learning

We learn individually and collectively, from each other and from our customers.​

Short iterations

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.

Wear many hats

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.

Everything is in draft

​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.

4. Inclusion

We want everyone to feel welcome and encourage diversity. We believe that this can contribute to other values like results and learning.

Values fit over culture fit

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.

Asynchronous communication

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.​

5. Trust

Collaboration, inclusion and learning rely heavily on trust.

Failure is normal

We are more interested in the lessons learned rather than the failures themselves.

Blame processes, not people

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.

Own your 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.

Psychological safety

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.

6. Efficiency

We want to avoid doing more work than needed whenever possible. This allows us to increase our progress and make our work more interesting.

Respect other people's time

Collaboration is meant to help us learn and get help. This doesn't mean everyone needs to be involved in every discussion.


  • If you can do something yourself and don't need approval, just do it, and write about your work so that others can understand it.
  • If you need feedback on a certain question or would like to highlight a problem, try to make a concrete proposal before asking for other people's input.
  • Automate processes to save time, for instance in code review, testing and deployment.

Simple solutions over clever solutions

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.

Write things down

Writing specifications, documentation and commit messages can spare you the need to explain things over and over.

Don't wait

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.

Accept some mistakes

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.

Why have core values?

  • For hiring. Our values help us evaluate candidates based on value fit rather than culture fit, and with less bias.
  • Within the company they help us work together with common expectations. They also enable each of us to make decisions more autonomously.


GitLab Values were a large source of inspiration.

Key Values was also useful to cover more social and personal values.

current vacancies