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.
Temporary Contractors (Not included in GitLab Team Member Types) are not eligible to receive or nominate 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 continue 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. X delivers for the team in lots of MVCs, 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, 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 Workday. 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 Workday.
/nominaterejected_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.Any GitLab team-member
Sales Development Focus Bonus (Sales Development specific working bonus)
Sometimes a working group strongly displays GitLab Values over a period, project or situation. For this case, we have a Working Group Bonus. The requirements for the sales development teams can vary from month to month and therefore may require a special focus from one or a group of individuals to complete specific tasks. Examples include: Adoption of a new process, driving new behaviors or special focus on a specific prospecting task from the sales team. This bonus is not an income supplement or an incentive for the team to do their current job, but to reward extra effort.
The Focus Working Group Bonus can only be recommended by Sales Development Managers for individuals or a group of individuals within their teams. The budget for the focus bonus cannot exceed $500 monthly for any Sales Dev Team and will typically be divided amongst team members.
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 the nominator bot 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.
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 a 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:
Please note if the referral bonus was submitted before 2022-06-01, then the here mentioned referral bonus amounts apply.
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 Workday 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 Workday and will process the bonus.
no bonus if the referral is an intern. You will be paid a referral bonus if the referral(intern) is converted to a full-time, intermediate-level team member.
no bonus for a referring team member will be applicable if the team members employment is terminated prior to the referral bonus payout date. You need to be an active team member.
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 signed contract at the time of the new candidate's application.
In the event that a GitLab sourcer adds a candidate to GreenHouse and the recruiter screens the candidate a referring party cannot be added to their profile after. The candidate source would be Prospecting by the GitLab sourcer.
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.
The Get Together Grant is currently paused. Stay tuned to the #whats-happening-at-gitlab Slack channel and this page for updates.
Start your quarter off by getting to know someone new at GitLab, or meeting someone in person for the first time! During the first month of every quarter in Feb, May, and August we invite team members to use a Get Together Grant to meet up with a team member either in person or virtually. In the fourth quarter, we will have a holiday grant that will be coordinated by your E-group leader. To take part in the grant, check out the following details:
Please review the latest Covid-19 guidance for in-person GitLab events that include more than 5 attendees before planning a Group Get Together.
In areas where many GitLab team members live, stay tuned in Slack and on this page for planned events where we'll invite all GitLab team members in that area to join together in person. For team members who participate in Group Get Togethers, individual Get Togethers in person or remote will not be available in the month the Group Get Together takes place.
Planning a group get together is easy! Simply head to our GitLab Team Member Socials project and create an issue to start planning your group get together (example).
For more questions about Get Together Grants, please review the FAQ.
We canceled Contribute FY23-Q3 due to the COVID risk to team members in having a large, global event in an indoor facility in the middle of summer. Contribute's purpose was to "get team members together to interact with one another and cultivate our community." We introduced the FY23-Q3 Visiting Grants as a way to capture the spirit of this, by providing team members with another opportunity to spend time together within FY23-Q3 (2022-08-01 to 2022-10-31).
Please note in FY21-Q1, GitLab suspended the Original Visiting Grant program until further notice. GitLab is an all-remote company with GitLab team-members all over the world. 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 the 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!).
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.
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 2 hours of submission. If you have questions about this process or don't see this upgrade after 2 hours please reach out in the #it_help GitLab slack channel.