Company
Values
Credit: https://about.gitlab.com/handbook/values/
GitLab Values
GitLab's six values are , 📈 Results , ⏱️ Efficiency, 🌐 Diversity, Inclusion & Belonging, 👣 Iteration, and 👁️ Transparency, and together they spell the CREDIT we give each other by assuming good intent. We react to them and they are made actionable below.
🤝 Collaboration
About our values
We take inspiration from other companies, and we always go for the boring solutions. Just like the rest of our work, we continually adjust our values and strive to make them better. GitLab values are a living document. In many instances, they have been documented, refined, and revised based on lessons learned (and scars earned) in the course of doing business.
We used to have more values, but it was difficult to remember them all, so we condensed them and gave sub-values and created an acronym.
Everyone is welcome to suggest improvements.
Sub-values as substantiators
The "sub" in sub-value is not in reference to "subordinate," but rather, "substantiate." Sub-values define top-level values, and are most easily lived out. You may see other companies with some of our top-level values, though our unique collection of sub-values are critical to add context and remove ambiguity.
Sub-values clarify what a given value means and looks like at GitLab. Understanding this distinction is critical to thriving at GitLab, particularly for newer team members who may be familiar with a prior organization's interpretation of iteration or collaboration (as examples).
Credit
🤝 Collaboration
Helping others is a priority, even when it is not immediately related to the goals that you are trying to achieve. Similarly, you can rely on others for help and advice—in fact, you're expected to do so. Anyone can chime in on any subject, including people who don't work at GitLab. The person who's responsible for the work decides how to do it, but they should always take each suggestion seriously and try to respond and explain why it may or may not have been implemented.
Kindness
We value caring for others. Demonstrating we care for people provides an effective framework for challenging directly and delivering feedback. We disagree with companies that say . We're all for accurate assessment, but we think it must be done in a kind way. Give as much positive feedback as you can, and do it in a public way.
Share
There are aspects of GitLab culture, such as extreme transparency, that are unintuitive to outsiders and new team members. Be willing to invest in people and engage in open dialogue. For example, consider making private issues public wherever possible so that we can all learn from the experience.
Everyone can remind anyone in the company about our values. If there is a disagreement about the interpretations, the discussion can be escalated to more people within the company without repercussions.
Share problems you run into, ask for help, be forthcoming with information and speak up.
Negative feedback is 1-1
Give negative feedback in the smallest setting possible. One-on-one video calls are preferred. If you are unhappy with anything (your duties, your colleague, your boss, your salary, your location, your computer), please let your boss, or the CEO, know as soon as you realize it. We want to solve problems while they are small.
Negative feedback is distinct from negativity and disagreement. If there is no direct feedback involved, strive to discuss disagreement in a public channel, respectfully and transparently.
In a , GitLab co-founder and CEO Sid Sijbrandij offers the following context.
We deal with negative all the time at GitLab. If it's not a problem, then why are we discussing it? We deal with negativity a lot, and that's also part of our ambition.
If you want to get better, you talk about what you can improve. We're allowed to publicly discuss negative things; we're not allowed to give negative feedback in a large setting if it could be feasibly administered in a smaller setting.
Say thanks
Recognize the people that helped you publicly, for example in our #thanks chat channel.
Give feedback effectively
Giving feedback is challenging, but it's important to deliver it effectively. When providing feedback, always make it about the work itself; focus on the business impact and not the person. Make sure to provide at least one clear and recent example. If a person is going through a hard time in their personal life, then take that into account. An example of giving positive feedback is our thanks chat channel. For managers, it's important to realize that employees react to a negative incident with their managers than they do to a positive one. Keeping that in mind, if an error is so inconsequential that the value gained from providing criticism is low, it might make sense to keep that feedback to yourself. In the situations where negative feedback must be given, focus on the purpose for that feedback: to improve the employee’s performance going forward. Give recognition generously, in the open, and often to from your team.
Get to know each other
We use a lot of text-based communication, and if you know the person behind the text, it will be easier to prevent conflicts. So we encourage people to get to know each other on a personal level through our Take A Break Call, virtual coffee chats, and during GitLab Contribute.
Don't pull rank
If you have to remind someone of the position you have in the company, you're doing something wrong. People already know our decision-making process. Explain why you're making the decision, and respect everyone irrespective of their function. This includes using the rank of another person - - to sell an idea or decision.
Assume positive intent
We naturally have a double standard when it comes to the actions of others. We blame circumstances for our own mistakes, but individuals for theirs. This double standard is called the . In order to mitigate this bias, you should always in your interactions with others, respecting their expertise and giving them grace in the face of what you might perceive as mistakes. When disagreeing, folks sometimes argue against the weakest points of argument, or sometimes argue against a "straw man". Assume the points are presented in good faith, and instead try to :
That’s when you articulate the absolute strongest version of your opponent’s position—potentially even stronger than the one they presented. A good steel-man argument is one where the other person feels you've represented their argument well, even if they still disagree with your assumptions or conclusion.
Address behavior, but don't label people
There is a lot of good in about not wanting jerks on our team, but we believe that jerk is a label for behavior rather than an inherent classification of a person. We avoid classifications.
Say sorry
If you made a mistake, apologize as soon as possible. Saying sorry is not a sign of weakness but one of strength. The people that do the most work will likely make the most mistakes. Additionally, when we share our mistakes and bring attention to them, others can learn from us, and the same mistake is less likely to be repeated by someone else. Mistakes can include when you have not been kind to someone. In order to reinforce our values, it is important, and takes more courage, to apologize publicly when you have been unkind publicly (e.g., when you have said something unkind or unprofessional to an individual or group in a Slack channel).
No ego
Don't defend a point to win an argument or double-down on a mistake. You are not your work; you don't have to defend your point. You do have to search for the right answer with help from others.
In many organizations, there's a subtle, low-level, persistent pressure to continually prove your worth. And I believe that this fuels imposter syndrome and wreaks havoc on mental health.
What's so troubling to me is how often perception is reality. In other words, those who have mastered the art of being perceived as elite reap benefits, though this has nothing to do with actual results.
At GitLab, "no ego" means that we foster and support an environment where results matter, and you're given agency to approach your work in the way that makes sense to you. Instead of judging people for not approaching work in an agreed-upon way, "no ego" encourages people to glean inspiration from watching others approach work in new and different ways.
Being no ego is a standard we hold ourselves as people to but is not one that applies to GitLab as a company or product. We want to celebrate and highlight GitLab's accomplishments, including being the largest all-remote company. This doesn't mean we don't recognize our mistakes, including how we handled telemetry.
See others succeed
A candidate who has talked to a lot of people inside GitLab said that, compared to other companies, one thing stood out the most: everyone here mentioned wanting to see each other succeed.
Don't let each other fail
Keep an eye out for others who may be struggling or stuck. If you see someone who needs help, reach out and assist, or connect them with someone else who can provide expertise or assistance. We succeed and shine together!
People are not their work
Always make suggestions about examples of work, not the person. Say "You didn't respond to my feedback about the design" instead of "You never listen". And, when receiving feedback, keep in mind that feedback is the best way to improve, and that others giving you feedback want to see you succeed.
Do it yourself
Our collaboration value is about helping each other when we have questions, need critique, or need help. No need to brainstorm, wait for consensus, or .
Blameless problem solving
Investigate mistakes in a way that focuses on the situational aspects of a failure’s mechanism and the decision-making process that led to the failure, rather than cast blame on a person or team. We hold blameless and retrospectives for stakeholders to speak up without fear of punishment or retribution.
Short toes
People joining the company frequently say, "I don't want to step on anyone's toes." At GitLab, we should be more accepting of people taking initiative in trying to improve things. As companies grow, their speed of decision-making goes down since there are more people involved. We should counteract that by having short toes and feeling comfortable letting others contribute to our domain. For example, pointed, respectful feedback to a proposal by GitLab's CEO led to his own merge request being closed.
It's impossible to know everything
We know we must rely on others for the expertise they have that we don't. It's OK to admit you don't know something and to ask for help, even if doing so makes you feel vulnerable. It is never too late to ask a question, and by doing so, you can get the information you need to produce results and to strengthen your own skills as well as GitLab as a whole. After your question is answered, please document the answer so that it can be shared.
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." (As inspired by .)
Collaboration is not consensus
When collaborating, it is always important to stay above radar and work transparently, but collaboration is not consensus. You don't need to ask people for their input, and they shouldn't ask you "Why didn't you ask me?" You don't have to wait for people to provide input, if you did ask them. We believe in permissionless innovation—you don't need to involve people, but everyone can contribute. This is core to how we iterate, since we want smaller teams moving quickly rather than large teams achieving consensus slowly.
Collaboration is not playing politics
We don't want people to play politics at GitLab. One way to spot when this is happening is when people discussing a proposal focus overly on whose proposal it is. This is a manifestation of the , where we judge an argument’s strength not by how strongly it supports the conclusion but by how strongly we support the conclusion. Proposals should be weighed on their merits and not on who proposed them. The other thing to observe is whether people are being promoted based on others liking them or having a lot of alliances. We want people to be promoted based on their results. We do value collaboration, but that's different than being promoted just because people like you.
Collaboration Competency
Competencies are the Single Source of Truth (SSoT) framework for things we need team members to learn. We demonstrate collaboration when we take action to help others and include other's (both internal and external) input (both help and feedback) to achieve the best possible outcome.
Level
Demonstrates Competency By...
Take Knowledge Assessment
Junior/Associate
Develops collaboration skills by learning from other team members
Open Assessment
Intermediate
Grows collaboration skills by using different types of communication; files issues appropriately, asks in the right Slack channels and uses the right labels.
Open Assessment
Senior
Models collaborative behavior for fellow team members and others within the group.
Open Assessment
Staff/Manager
Coaches team members on how to collaborate more effectively and pointing team members to the right channels to collaborate.
Open Assessment
Senior Manager
Fosters collaborative decision making and problem solving across the departments.
Open Assessment
Director
Drives team collaboration across divisions/departments, silos, and division boundaries.
Open Assessment
Senior Director
Develops networks and builds partnerships, engages in cross-functional activities; collaborates across boundaries, and finds common ground with a widening range of stakeholders. Utilizes contacts to build and strengthen internal support base
Open Assessment
VP
Leads collaboration and teamwork in daily routines, prioritizing interactions, information sharing, and real time decision making across divisions/departments. Encourages greater cross-functional collaboration among e-team leaders.
Open Assessment
EVP/CXO
Champions collaboration and teamwork into daily routines, prioritizing interactions, information sharing, and real time decision making across divisions/departments. Champions cross-functional collaboration among e-team leaders and GitLab.
Open Assessment
📈 Results
We do what we promised to each other, customers, users, and investors.
Dogfooding
Measure results not hours
We care about what you achieve: the code you shipped, the user you made happy, and the team member you helped. Someone who took the afternoon off shouldn't feel like they did something wrong. You don't have to defend how you spend your day. We trust team members to do the right thing instead of having rigid rules. Do not incite competition by proclaiming how many hours you worked yesterday. If you are working too many hours, talk to your manager to discuss solutions.
Give agency
We give people agency to focus on what they think is most beneficial. If a meeting doesn't seem interesting and someone's active participation is not critical to the outcome of the meeting, they can always opt to not attend, or during a video call they can work on other things if they want. Staying in the call may still make sense even if you are working on other tasks, so other peers can ping you and get fast answers when needed. This is particularly useful in multi-purpose meetings where you may be involved for just a few minutes.
Write promises down
Agree in writing on measurable goals. Within the company we use public OKRs for that.
Growth mindset
You don't always get results and this will result in criticism from yourself and/or others. We believe our talents can be developed through hard work, good strategies, and input from others. We try to hire people based on .
Global optimization
This name comes from the . Our definition of global optimization is that you do what is best for the organization as a whole. Don't optimize for the goals of your team when it negatively impacts the goals of other teams, our users, and/or the company. Those goals are also your problem and your job. Keep your team as lean as possible, and help other teams achieve their goals. In the context of collaboration, this means that if anyone is blocked by you on a question, your approval, or a merge request review, your top priority is always to unblock them, either directly or through helping them find someone else who can, even if this takes time away from your own or your team's priorities.
Tenacity
We refer to this as "persistence of purpose". As talked about in , tenacity is the ability to display commitment to what you believe in. You keep picking yourself up, dusting yourself off, and quickly get going again having learned a little more.
Ownership
We expect team members to complete tasks that they are assigned. Having a task means you are responsible for anticipating and solving problems. As an owner, you are responsible for overcoming challenges, not suppliers or other team members. Take initiative and proactively inform stakeholders when there is something you might not be able to solve.
Sense of urgency
At an exponentially-scaling startup, time gained or lost has compounding effects. Try to get the results as fast as possible, but without compromising our other values and ways we communicate, so the compounding of results can begin and we can focus on the next improvement.
Ambitious
While we iterate with small changes, we strive for large, ambitious results.
Perseverance
Working at GitLab will expose you to situations of various levels of difficulty and complexity. This requires focus and the ability to defer gratification. We value the ability to maintain focus and motivation when work is tough and asking for help when needed.
Bias for Action
It's important that we keep our focus on action, and don't fall into the trap of analysis paralysis or sticking to a slow, quiet path without risk. Decisions should be thoughtful, but delivering fast results requires the fearless acceptance of occasionally making mistakes; our bias for action also allows us to course correct quickly. Everyone will make mistakes, but it's the relative number of mistakes against all decisions made (i.e. percentage of mistakes), and the swift correction or resolution of that mistake, which is important. A key to success with transparency is to always combine an observation with questions to ensure understanding and suggestions for solutions / improvement to the group that can take action. We don't take the easy path of general complaints without including and supporting the groups that can affect change. Success with transparency almost always requires effective collaboration.
Accepting Uncertainty
We should strive to accept that there are things that we don’t know about the work we’re trying to do, and that the best way to drive out that uncertainty is not by layering analysis and conjecture over it, but rather accepting it and moving forward, driving it out as we go along. Wrong solutions can be fixed, but non-existent ones aren’t adjustable at all.
Customer results
Our focus is to improve the results that customers achieve, which requires being aware of , see for a specific UX example. Customer results are more important than:
Results Competency
Competencies are the Single Source of Truth (SSoT) framework for things we need team members to learn. We demonstrate results when we do what we promised to each other, customers, users, and investors.
Level
Demonstrates Competency By...
Take Knowledge Assessment
Junior/Associate
Develops the skills needed to commit and execute on agreed actions.
Open Assessment
Intermediate
Applies commitment to results and demonstrates ability to execute on agreed actions.
Open Assessment
Senior
Models a sense of urgency and commitment to deliver results.
Open Assessment
Staff/Manager
Coaches team members to collaborate and work iteratively towards results with the focus on the outcome and not hours worked.
Open Assessment
Senior Manager
Fosters a culture of ownership for own performance.
Open Assessment
Director
Drives efficient execution of results ensuring collaboration between team members.
Open Assessment
Senior Director
Develops quarterly OKR's ensuring the performance and results of one or more teams.
Open Assessment
VP
Leads the achievement of results while driving the continued alignment to our values of collaboration, efficiency, diversity, iteration and transparency.
Open Assessment
EVP/CXO
Leads the achievement of results while driving the continued alignment to our values of collaboration, efficiency, diversity, iteration and transparency.
Open Assessment
⏱️ Efficiency
We care about working on the right things, not doing more than needed, and not duplicating work. This enables us to achieve more progress, which makes our work more fulfilling.
Write things down
We document everything: in the handbook, in meeting notes, in issues. We do that because "." It is far more efficient to read a document at your convenience than to have to ask and explain. Having something in version control also lets everyone contribute suggestions to improve it.
Boring solutions
Use the simplest and most boring solution for a problem, and remember that The speed of innovation for our organization and product is constrained by the total complexity we have added so far, so every little reduction in complexity helps. Don’t pick an interesting technology just to make your work more fun; using established, popular tech will ensure a more stable and more familiar experience for you and other contributors.
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.
Self-service and self-learning
Team members should first search for their own answers and, if an answer is not readily found or the answer is not clear, ask in public as we all should have a low level of shame. Write down any new information discovered and pay it forward so that those coming after will have better efficiency built on top of practicing collaboration, inclusion, and documenting the results.
Efficiency for the right group
Optimize solutions globally for the broader GitLab community. Making a process efficient for one person or a small group may not be the efficient outcome for the whole GitLab community. As an example, it may be best to discard a renewal process that requires thousands of customers to each spend two hours in favor of one that only takes sixty seconds, even when it may make a monthly report less efficient internally! In a decision, ask yourself "For whom does this need to be most efficient?" Quite often, the answer may be your users, contributors, customers, or team members that are dependent upon your decision.
Be respectful of others' time
Consider the time investment you are asking others to make with meetings and a permission process. Try to avoid meetings, and if one is necessary, try to make attendance optional for as many people as possible. Any meeting should have an agenda linked from the invite, and you should document the outcome. Instead of having people ask permission, trust their judgment and offer a consultation process if they have questions.
Spend company money like it's your own
Every dollar we spend will have to be earned back; be as frugal with company money as you are with your own.
Frugality
with: "Accomplish more with less. Constraints breed resourcefulness, self-sufficiency, and invention. There are no extra points for growing headcount, budget size, or fixed expense."
ConvDev
Freedom
You should have clear objectives and the freedom to work on them as you see fit.
Short verbal answers
Give short answers to verbal questions so the other party has the opportunity to ask more or move on.
Keep broadcasts short
Keep one-to-many written communication short, as mentioned in : "A majority say that what they read is frequently ineffective because it’s too long, poorly organized, unclear, filled with jargon, and imprecise."
Managers of one
We want each team member to be a manager of one who doesn't need daily check-ins to achieve their goals.
Responsibility over rigidity
When possible, we give people the responsibility to make a decision and hold them accountable for that, instead of imposing rules and approval processes.
Accept mistakes
Not every problem should lead to a new process to prevent them. Additional processes make all actions more inefficient; a mistake only affects one.
Move fast by shipping the minimal viable change
We value constant improvement by iterating quickly, month after month. If a task is not the smallest thing possible, cut the scope.
Efficiency Competency
Competencies are the Single Source of Truth (SSoT) framework for things we need team members to learn. We demonstrate efficiency when we work on the right things, not doing more than needed, and not duplicating work.
Want to print your doc?
This is not the way.
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
CtrlP
) instead.