Can't find what you're looking for? Try the main People Operations page.
The following incentives are available for GitLab team members. Also see our separate page on benefits available to GitLab team members.
The number of discretionary bonuses given divided by the total number of team members, in a given period as defined. The discretionary bonuses per team member target is > 0.1. This analysis can be found on the People Group Dashboard.
Discretionary bonuses are measured in BambooHR, as are the number of team members, in a given period as defined.
Temporary Contractors (Not included in GitLab Team Member Types) are not eligible for discretionary bonus / working group bonus. Any such nominations for the temporary contractors will not be approved by the People Connect team.Discretionary bonuses are to celebrate team members that live by our values. To make sure we are recognizing the right behaviors, below are some criteria to help you decide if a bonus meets the requirements for approval. Also in the nomination you are asked to elaborate on how this nomination is meeting the criteria.
Valid bonus criteria
Invalid bonus criteria
Examples of a valid discretionary bonus
The reason for the bonus is that this person (X, a Technical Writer) has single-handedly stepped in to act as a part-time documentation engineer in the absence of a full-time engineer.
The person's history of contributions is plain to see here: (Nominator included links to boards, issues or merge requests)
In particular, X's implementation of a Global Navigation and GitLab iconography for documentation are real highlights of X's impact for end-users. For developers, they have modernized the codebase and continues to work toward making gitlab-docs just like any other GitLab project for developers. X's dedication to the Technical Writing team over a long period of time motivates me to do more than just thank X in #thanks channel. X has specifically: Been active to see the Technical Writing team to succeed: /handbook/values/#see-others-succeed. X delivers for the team in lots of MVCs: /handbook/values/#minimal-viable-change-mvc, so we can get early value. For example, making iconography available using Markdown first, and planning to deliver other implementations later. X solutions are boring: /handbook/values/#boring-solutions, in that X aims to reuse as much GitLab code as possible, and raising instances where that isn’t the case as technical debt. For example, docs icons are the same library as icons in the product.
I’d like to nominate X for a discretionary bonus for exhibiting the values for results, efficiency, and collaboration. While the whole backend engineers in the X team were OOO, despite it wasn’t his team, X stepped in and handled a problem (link) that was blocking a deploy. X was able to debug the problem, not an easy one by the way, communicate it to the different counterparts, and also fix it. X also spotted that it could affect other features and provide a way to fix them as well.
I am nominating X for the values efficiency and results for the Nominator Bot. This bot assists us to nominate a team member for Discretionary Bonus without logging into BambooHR. This new bot speeds up the process probably by half the time it took to get approvals (for both me that administers the process and managers for approval) and directly now impacts our PI to increase discretionary bonuses. X is managing all the debugging and going above and beyond to solve any problems, without anyone asking X or having to follow up and this is out of scope of "just building a nominator" bot. You can read more about the process in our handbook
Examples of invalid discretionary bonus
What does 'going above and beyond' mean?
to do more or better than would usually be expected of you
What do we normally expect of a GitLab team member? Read their job family responsibilities to determine if their work is part of the normal job expectations. As an example, a senior Frontend developer is expected to solve technical problems of high scope and complexity.. Going above and beyond involves taking on work that is outside the scope of their job responsibility listing, and executing it to a high level.
Some tips for knowing if someone is going above and beyond:
If you received the same nomination twice (for the same person and the same reason), you may reject one. When you do this, please reach out to the team member who submitted the nomination to explain, and include the other nominator's name in the #team-member-updates announcement.
For example:
Note: Kindly use Nominator Bot for discretionary bonus requests instead of BambooHR.
Any GitLab team member
/nominateManager Process
rejected_by_manager. The bot will ask you to reach out to the nominator as to make sure they understand why the nomination was not approved.Approval flow
Any GitLab team-member
Manager Process
Approval Process:
As a general rule, the nominated team member's direct manager should be the only person who communicates discretionary bonuses. The manager will receive final notification via BambooHR or the nominator bot (depending on where the nomination process was initiated) and will know when the nomination has gone through all levels of approval.
The exception to this rule could be for working group bonuses if a single person nominated a group. If the nominator would like to announce on behalf of the group, they should:
On a quarterly basis there's a review of the discretionary bonuses data. This includes: # approved per manager, # rejected per manager and any trends on the reason for rejection. This way we can act on any trends and ensure an efficient and consistent process across the whole organization.
At 10:00 UTC on Thursday of every week, PeopleOps Bot slack bot will send a shout out on the #team-member-updates channel congratulating all team members who celebrates a hire date anniversary that week.
Visit our GitLab Anniversary Gift section for more information about the gifts.
Each fiscal year the GitLab Awards program recognizes team members who made great impact as a result of displaying our Values. The GitLab Awards Program consists of two different types of awards: The DZ Award and Values Awards. Generally we open the window for nominations in the fourth quarter of the fiscal year. Winners will be announced before the end of the fiscal year.
In honor of our valued co-founder, Dmitriy Zaporozhets “DZ”, his contributions and him dedicating 10 years to GitLab, GitLab recognizes a team member each fiscal year who made a great impact solving a hard problem by using a boring solution.
The DZ award details:
Potential nominees should be any team members who solved a challenging problem by creating and implementing a boring solution that resulted in a positive and profound impact.
Criteria used to calibrate:
Criteria not used to calibrate:
The Values Awards honor those who embody and employ the GitLab values which are fostering an environment where everyone can thrive. These awards specifically recognize team members who are inclusive with all team members in their diversity of thought and perspectives. Team members eligible for these awards demonstrate: no ego in the workplace, use a single source of truth, saying why not just what, and embracing uncomfortable ideas and conversations. The contributions or displays of the GitLab Value should be visible beyond the team member’s direct team, customers, users or investors.
The Values Awards details:
To achieve results, team members must work together effectively. The value award for Collaboration should be awarded to a team member that made helping others a priority and went above and beyond in ways that led to tangible results. This can come in the form of for example: giving feedback effectively, sharing, reaching across company departments or short toes.
We do what we promised to each other, customers, users, and investors. The value award for Results should be awarded to a team member that went above and beyond to get to significant results for a company wide impact. This can come in different forms through for example: ownership, perseverance, dogfooding or disagree, commit, and disagree.
Working efficiently on the most important business initiatives enables us to make fast progress, which makes our work more fulfilling. The value award for Efficiency should be awarded to a team member that helped make fast progress through for example championing writing things down, embracing change or being a manager of one.
We aim to make a significant impact in our efforts to foster an environment where everyone can thrive. The value award for Diversity, Inclusion and Belonging should be awarded to a team member that contributed to creating an environment where people from every background and circumstance feel like they belong and can contribute through for example: their bias towards asynchronous communication, seeking diverse perspectives or embracing neurodiversity.
We do the smallest thing possible and get it out as quickly as possible. The value award for Iteration should be awarded to a team member that contributed or displayed iteration that led to faster results through for example: setting a due date, minimal viable change (MVC) or low level of shame.
By making information public, we can reduce the threshold to contribution and make collaboration easier. The value award for transparency should be awarded to a team member that contributed or displayed transparency through for example: determining what is not public, use of single source of truth and saying why not what.
All team members can make nominations for both The DZ Award and Values Awards. When you want to nominate a peer it’s crucial to loop in your manager and your Department Head. Ultimately each Department Head can bring forward 1 nomination for the DZ Award and 1 nomination per value. The Department Head should loop in their People Business Partner with the final nominations in the correct format. The People Business Partners will coordinate the nominations for both awards and ultimately nominations will be calibrated at the E-Group level.
Chances are that if you work at GitLab, you have great friends and peers who would be fantastic additions to our Team and who may be interested in joining our team. To help us grow with exceptional people, we have Referral Bonuses that work as follows:
We encourage and support diversity and frugality on our team and in our hiring practices, so we will offer the following referral bonuses once the new team member has been with the company for 3 months. We will award the highest cumulative dollar amount as outlined below:
The following is an example of a cumulative Referral Bonus:
For information regarding the program details and team member eligibility and understanding, please visit our guide in the Hiring section of GitLab's handbook.
If a team member has been referred, the People Connect team will review team members' self-identification data in BambooHR including Gender, Ethnicity and Veteran status to determine if the team member qualifies as belonging to a select underrepresented group. The People Connect team will edit the referrer's referral bonus as applicable. People Connect will confirm the bonus amount when it is entered into BambooHR and will process the bonus.
In the event that more than one GitLab employee refers the same team member for the same role the People Ops team will ask the new team member to confirm who they were referred by (who should get the credit). If they mention two or more people then the bonus will be split between them.
In the event that someone wants to refer another candidate to GitLab before they have started the referring party must have a sign contract at the time of the new candidate's application.
As we continue to prioritize the health and safety of our team members, GitLab is temporarily suspending the Visiting Grant program until further notice. We continue to monitor the situation and will update this information and the travel policy accordingly.
This means that at this time we ask team members to refrain from booking travel that would normally be covered under the visiting grant. This includes local events and co-working days that don't require long-distance travel. In the event you had previously planned a visit, please cancel it and attempt to maximize any credits for future travel or refunds that you may be eligible for.
For those team members who have already completed visits, please expense your visit per the instructions below.
GitLab is an all-remote company with GitLab team-members all over the world (see the map on our Team page. If you want to visit other team members to get to know them, GitLab will assist with travel expenses (flights, trains, and ground transportation to and from airport) for a total of up to $150 for every team member that you visit and work with. Please note lodging is excluded. To be clearer, if you meet 2 GitLab team members during your visit, the maximum limit of your visiting grant could be $150x2. You don't need to work on the same project or team, either, so long as you discuss work for at least part of the time you're meeting. Before booking any travel using the travel grant budget please discuss your proposed travel with your manager. We encourage team members to utilize the travel grant, however in some cases - for example, a team member has performance issues related to their role - the visiting grant would not be applicable.
Note that meals and local travel while visiting are not typically covered for anyone as that wouldn't really be fair to those being visited. It may be acceptable to cover a meal, however, if the meeting is pre-announced to other people in the region to encourage as many of them to attend as possible and there are four or more GitLab team-members attending.
There are many regular meet-ups of GitLab team-members in many cities. We have a shared calendar to view the schedule. Subscribe to it, make use of the visiting grant, and join meet-ups near you (or far away!).
Douwe and Robert took advantage of the visiting grant when they traveled to 49 different colleagues in 20 cities, in 14 countries, on five continents, in 6 months. Inspired by them, Dimitrie went on a similar journey and provided a great template. Also, check out tips on working remotely while abroad.
To claim the grant, include a line item on your expense report or invoice along with the receipt of your flights, trains, and/or transportation to and from the airport with a list of the team members you visited. The expense report may be submitted during the first month of travel or up to 3 months after your trip has concluded. That said, if it's more frugal to book and expense your travel further in advance, please do so.
As we continue to prioritize the health and safety of our team members, GitLab is temporarily suspending the Significant Life Event Grant program until further notice. We continue to monitor the situation and will update this information and the travel policy accordingly.
Recognizing that GitLab Team Members may wish to share significant events in each other's lives, such as weddings or civil partnerships, GitLab will assist with travel expenses to attend these events. This grant works the same way as the Visiting Grant, except the reimbursement limit is $300 per team member you visit at an event.
If you're a GitLab team member who has traveled and utilized GitLab's Visiting Grant or are planning to do so soon, consider sharing your story! You can submit your experience using the GitLab Visiting Grant Story Submission Form. If you've made use of the Significant Life Event Grant, please check with the team member who invited you to their event if they are comfortable with you sharing their story first.
These stories are useful in showing the world how we stay connected as a geographically diverse team. This is important as we recruit the world's best talent to join us, as well as encouraging colleagues to take a leap, explore a new culture, and visit a team member in a new locale. They may be shared on GitLab's social media platforms, on hiring portals such as Glassdoor, or on the GitLab blog.
Each quarter, 3 GitLab team members who submit Visiting Grant stories will be randomly selected for a $50 voucher for the GitLab Swag Shop!
Every GitLab team member can request the Ultimate tier for GitLab.com. In case a team member has separate private and work accounts on GitLab.com, they can request it for both. This incentive does not apply to groups owned by GitLab team members (Group-level Ultimate features such as epics will not be available for Ultimate GitLab team-member personal accounts, for instance).
In order to request this benefit please submit this form. Your account(s) will be upgraded to the Ultimate tier within 30 minutes of submission. If you have questions about this process or don't see this upgrade after 30 minutes please reach out in the #it_help GitLab slack channel.