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: /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 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.
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
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:
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.
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.
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.
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, Aug, and Nov, we invite team members to use a Get Together Grant to meet up with a team member either in person or virtually. 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.
In FY21-Q1, GitLab suspended the Visiting Grant program until further notice. Due to the cancellation of Contribute in FY23, we have introduced a special Visiting Grant Program for FY23-Q3 (2022-08-01 to 2022-10-31). Program details differ.
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.” Introducing FY23-Q3 Visiting Grants is 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).
While the FY23-Q3 Visiting Grant Program shares a lot in common with the previous Visiting Grants Program, it varies in a few key ways:
For the purposes of the FY23-Q3 Visiting Grant Program, a team members local area is being defined as within 50 miles/80 km from the team members home OR requiring less than 1.5 hours travel time one-way.
If team members have opportunities for participation in their local area, they should consider these. Contribute was canceled to reduce travel time to minimize COVID risk.
The event must happen within FY23-Q3 and and expenses filed within 7 days of the event ending
Efforts should be made to welcome all team members and teams when there are opportunities to do so within a geography. We encourage team members to plan events that are inclusive of cross-functional team members, but team members can choose to use these funds for team events.
If you are planning a team event, you should still look for opportunities to include team members from other functions who live in the local area. For example, a team meeting in London, England could open up their dinner or happy hour to all team members within the location. This would be advertised in the shared event planner and posted in the local Slack group.
All events should include at least 4 people. Please ensure the activity is one where all team members attending would feel included. Exceptions to the number of people is okay if team members live in a location with few team members. In this case, team members can have local events that are inclusive of everyone who is within travel distance of the event. This may mean fewer than 4 people.
Please list any events or activities in our shared event planner, so all team members have the chance to opt in. Local or event/activity specific Slack channels can be used for organization.
When traveling and attending the event, please:
Everyone is encouraged to plan their Visiting Grant activities according to our Flexible PTO policies.
Team members are expected to manage their individual expenses and adhere to expense caps. If events are centrally organized, coordinators should be clear with team members on how much of their FY23-Q3 allocation is going to the event. Team members are responsible for spending company money like its their own and not exceeding their individual budgets.
In addition to transportation, team members can expense hotels when traveling outside of their local area, meals with other team members, passport, visas, COVID testing, and activities with other team members. As long as 4 team members are present on a given day, accommodations and related travel expenses will be covered. Team members may expense accomodations for the night prior to the event only if best efforts have been exhausted to arrive the day of the event.
All individual plane travel must be booked through TripActions when possible. You may also choose to book lodging and other travel through TripActions. In TripActions, you should put "FY23-Q3 Visiting Grant" in the Purpose field when booking. For flights booked outside of TripActions, team members should expense tickets up to the maximum amount through Expensify. Be aware that by not using TripActions, team members will be responsible for potential fees associated with any transport issues (ie. cancellations).
If team members have layovers related to travel to and from the event, please expense the airfare as one trip. If something happens in transit that cannot be supported through TripActions, you will be responsible for the fees. If you decide to stay over during the layover, you will be responsible for any related expenses to the extended stay.
Preference using your budget toward booking air travel through TripActions before you spend any of your allocation on other expenses. Unless you receive an exception, if you spend over $1,000 on airfare, you will need to reimburse GitLab for the overage. When your expense cap is exceeded, do not expense additional expenses, for example, hotel, events, and food, associated with your travels. If you choose to spend above your budget on air travel, you should still book through TripActions, but you will be responsible for your overages. You will also be responsible for any overages in Expensify.
To reimburse GitLab, please fill out the Travel Grant Reimbursements template by choosing the "Fy23Q3VistingGrantReimbursements" description to alert your manager and allow us to track repayments. Direct deposit instructions will be sent to you and tailored to your location. All reimbursement deposits must be received by GitLab by 2022-10-31.
If more than 10 people are traveling to a central location and booking a hotel, or if you are booking catering for the event, we require these purchases to have a purchase order to ensure the best rates. All purchases must be made following the procurement process.
You may pool your budgets across a group to make budgeting easier and increase purchasing power. E.g. a group of eight can have a collective budget of $8000. The decision to do this will be up to the DRI for the event. For large purchases related to the event (ie. group meals, activities), it is preferred that the DRI be responsible for paying upfront and splitting the expense in Expensify by team member in the ‘Attendees’ section.
Expensify can be used to reimburse other expenses within budget. In Expensify, the team member should code any related expense to the Category "Company Functions" and to the Classification "FY23-Q3 Visiting Grant".
We recommend that each event or activity has a DRI. This can be anyone who plans to attend that event or activity, and encourage team members to take a Bias for action to self nominate, or nominate someone they know will be attending who would like to be the DRI. Please ensure the DRI is entered in the FY23-Q3 Visiting Grant Events sheet, and if you're nominating someone else, please check with them first before adding them to the sheet.
Team members should be aware of key GitLab policies and asks.
This Program has a limited timeframe, but we’ll look to the success of this program and other alternatives that support team member interactions and cultivation as we determine how best to support team member relationship building in the future. If you have questions, please post them in the #fy23-q3-visiting-grants Slack Channel.
We'll attempt to document answers to frequently asked questions in the handbook, please also refer to this document.
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!
If you've previously made use of the Significant Life Event Grant (temporarily suspended), 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. You can also post pictures in the #fy23-q3-visiting-grants Slack Channel.
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.