Incentives at GitLab

The page contains information about incentives available for GitLab team members.

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.

Discretionary Bonuses

Discretionary Bonuses for Individuals

  1. Every now and then, individual GitLab team members really shine as they live our values. We especially like to celebrate the special moments that exemplify the behavior we want to see in all GitLab team members.
  2. We recognize this through the #thanks channel, and sometimes also through a discretionary bonus which is also celebrated in #thanks.
  3. Any GitLab team member can recommend a discretionary bonus for another GitLab team member to the GitLab team member’s manager using the Nominator Bot for a $1,000 at the exchange rate. The exception is that direct reports cannot nominate their manager or anyone in their management chain for a discretionary bonus.
  4. Only GitLab team members are eligible to receive a discretionary bonus / working group bonus or nominate other GitLab team members. Hence, 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.
  5. We are fixing this amount at $1,000 thoughtfully and purposefully. We want the focus to be on the value and the behavior, not on the perceived monetary impact to GitLab. This is about recognition.
  6. A general guideline is that 1 in 10 team members might receive a discretionary bonus each month. This can vary greatly as we don’t give out bonuses just to hit a quota, nor would we hold one back because a certain number had already been awarded.
  7. There is no limit to the frequency with which someone can receive a bonus. If someone deserves a bonus a day after being nominated for one we should do a second one.
    • Note: If you received the same nomination twice (for the same person and the same reason), you must reject one. See more details in section for multiple discretionary bonuses
  8. As with other bonuses, only active GitLab team members can be nominated and can nominate other GitLab team members to receive discretionary bonuses. Should a nominated team member leave GitLab, they will not receive a discretionary bonus. It’s at the discretion of the manager if they still want to publicly recognize the team member’s behavior for the nomination.
  9. Only individuals in good standing with the company are eligible for discretionary bonuses (I.E. not currently undergoing underperformance remediation). If a team member receives a discretionary bonus nomination during a period of underperformance remediation, managers should wait until the underperformance remediation period concludes successfully before determining whether to admit the discretionary bonus request.
  10. Any bonus that sits idle for 90 days will be automatically canceled. At GitLab, only 90 days of Slack is retained and therefore any history of this request has also been deleted for the approver.

Valid and Invalid criteria for discretionary bonuses

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

  • Going above and beyond what is expected in regard to the team member’s role description.
  • Truly exceptional work. Good and great is already expected in a team member’s work and performance.
  • Providing additional coverage or project load for other team members.
  • Team member’s work results in higher productivity or improved processes that create efficiencies and results. This may also result in identifying cost saving initiatives.

Invalid bonus criteria

  • Supplement to income.
  • For being nice and friendly.
  • For being helpful.
  • Doing a project or task that is core to their role.
  • For help onboarding a new GitLab team member.
  • Hitting sales target or quota
  • Providing customer insight
  • Partnering or collaborating with other groups within GitLab
  • Working long hours or on weekends

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

  • “X has been an integral part to my onboarding experience, working tirelessly to help me get access and answers questions. X truly embodies GitLab’s value of efficiency, collaboration and results”
  • “X has continually met or exceeding their sales quota for 3 months”
  • “X is always willing to jump in even at the last moments to help out a team member”
  • “X has helped to update handbook pages, keeping the handbook alive”
  • “I find the team member is doing very inspiring work and easy to collaborate with”

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:

  • Look at other successfully approved bonuses in that person’s stage. Is this work similar?
  • Look at the level above the person’s current job responsibilities. Do their actions exceed their current role?
  • Look at the impact of the person’s work across the wider organization. Does the work have a large-scale impact outside of their team or stage?

Any bonus submitted that does not include clear and valid reasons for submission may be denied and the nominator / manager will be asked to provide further content and details.

Multiple Discretionary Bonuses

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 #thanks Slack channel announcement.

For example:

  • Person A submits a valid nomination for Project X on 2021-01-01
  • Manager approves and it progresses in the approval process
  • Person B submits a valid nomination for Project X (same project) on 2021-01-02
  • Manager copies the nomination (because Nominator Bot may not save the message), reaches out to let Person B know, and rejects Person B’s nomination.
  • Person A’s nomination is fully approved
  • Manager shares in #thanks Slack channel, mentioning nomination by both Person A and Person B and with the descriptions from both

Process for Recommending a Team Member for a Discretionary Bonus

Note: Kindly use Nominator Bot for discretionary bonus requests instead of Workday.

Nominator Bot Process

Any GitLab team member
  1. Go to Slack and type /nominate
  2. Slack will open a dialog and ask you for some details about the nomination. Use the motivation text field, to write a few sentences describing how the GitLab team member has demonstrated a specific GitLab value in their work. Please make sure you have viewed the valid and invalid criteria listed above. Don’t forget that the nomination request should tie to our values and be detailed enough to ensure that the nomination meets the criteria. You can select the values it applies to.
  3. If applicable, please be sure to include any relevant issues or merge requests that support the nomination.
  4. Once submitted, the bot will send this over to the manager to kick-off the approval flow.
  5. If at any point in the approval flow the manager or the manager’s manager has a question about approving the bonus they can reach out to the manager and/or nominator for more context. If they have remaining questions related to the process and logistics (e.g., where is the bonus in the approval chain?), this FAQ guide could help clarify, alternatively they can reach out to people connect. For remaining questions regarding guidance on whether to approve a nomination, they can reach out to their aligned People Business Partner.
  6. If the manager or second level approver is on an extended leave and unable to respond to the nomination in a reasonable timeframe (more than 2 weeks), please create a case for the People Connect team in HelpLab with who the nomination is for, so it can be manually moved to the next level manager to be processed.
  7. Once everyone has approved the bot will report back to you with the good news. If it’s rejected we ask the person who rejects, to reach out to you. That is not done by the bot.
Manager Process
  1. The Nominator bot will send you a Slack DM asking to approve or reject the nomination.
  2. When you decide to approve, all you need to do is click the approve button. The bot will take care of the next steps (sending it to the second level manager and the People Connect team).
  3. When you decide to reject, click the reject button. The nomination will be updated as 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.
  4. If the next level approver is on an extended leave and unable to respond to the nomination in a reasonable timeframe (more than 2 weeks), please create a case for the People Connect team in HelpLab with who the nomination is for, so it can be manually moved to the next level manager to be processed.
  5. When everyone else has approved, the bot will reach out to you so you can share this with the team member, in the #thanks Slack channel, and make sure the team member’s direct peers can easily see it:
    • For example, cross-post to the team member’s group channel
    • For Support, add it to the Support Week in Review as a “Team Member Update” item
Approval flow
graph TD;
  A[Nomination] -->|Bot logs and sends to manager| C;
  C{Manager}
  C -->|Reject| D[Bot logs];
  C -->|Approve| F;
  F{Manager's Leader}
  F -->|Reject| H[Bot logs];
  F -->|Approve| L;
  L{People Connect}
  L -->|Reject| M[Bot logs];
  L -->|Approve| N[Bot logs and sends to Workday];

Working Group Bonus

  1. Sometimes a working group strongly displays GitLab Values over a period, project or situation. For this case, use the Working Group Bonus.
  2. As with individuals, we recognize those who make up that group through the #thanks channel and sometimes through a Working Group Bonus.
  3. Anybody can recommend a Working Group Bonus through the managers of the individuals involved for $100 per person at the exchange rate.

Process for Recommending Working Group Bonus in Workday

Any GitLab team-member

  1. Write a description of how the working group has demonstrated a specific GitLab value in their work.
  2. Email that sentence to the managers of the individuals, suggesting a Working Group Bonus, and set-up a 15 minute Zoom meeting with all the managers to discuss your proposal. Note: The alignment with managers can also be done asynchronously in a private Slack channel.
  3. Remember that the manager(s) may or may not agree and they have full discretion (with approval of their manager) on whether their reports get a bonus. Don’t forget that you can also use the #thanks channel to recognize people, as well.

Sales Development Focus Bonus (Sales Development specific working bonus)

  1. 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.
  2. 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

  1. Please submit as a One Time Payment in Workday. Make sure to write in the Additional Information box what the working group bonus is for.

Approval Process:

  1. The next level Manager receives an alert from Workday and can approve or deny.
  2. Once approved by the next level manager, the request is sent to People Connect for review and final approval.
  3. Once fully approved, Payroll is notified of the bonus and can begin processing.
  4. After this, the manager is able to notify the team member of the bonus and will announce it on the GitLab Slack channel [#thanks](https://gitlab.slack.com/archives/C038E3Q6L). The announcement should include the “who” and “why” of the bonus.

Communicating Discretionary Bonuses

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:

  • Confirm that all bonuses have gone through all layers of approval
  • Confirm with each nominees direct manager that it is ok for them to announce on behalf of the group

Discretionary bonus reporting

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.

Real Examples of Real Team Members Who Received Bonuses for Doing Great Things

  • This document presents the case for awarding a UX team member an incentive. The UX team member is reliable, fair and respectful, consistently acting in the best interest of the company as well as the team.
    • Collaboration: The UX team member took on the extra duties of UX Lead and handled the interim duties seamlessly. She responded kindly to the community feedback on sidebar issue in 9.0 well. She personally helped the VP of Engineering finish the merit review process for the UX team.
    • The UX team member has greatly helped the UX Lead transition to her new role by assisting with meetings, transferring knowledge openly, and being available for questions whenever necessary.
    • Results and Efficiency: The UX team member quickly delivered screenshots for a partnership in a day or two. She did a great job with the UX team updates, providing clear and visual screenshots of what the team was working on. She helped the team deliver the UX improvements shown in those updates.
  • A Support team member received a bonus for:
    • Results & boring solutions: He managed to swap the database from PG9.2 to PG9.6 without significant downtime. It was even boring. ­
    • Sharing: His issues, guidelines, monitoring, you­name­it are exemplary. He keeps raising the bar and leaving a written trace to follow when he is not around. ­
    • Efficiency: He always hits the nail and does the right thing, has a great sense of priorities and can jump into production to solve a right now pain in a heartbeat. ­
    • Quirkiness: What to say? Do you want someone washing grapes or painting a wall in a call, just invite him.
  • A Marketing team member received a bonus for:
    • Transparency: The marketing team member always works in the open. In our 1:1s she is very clear on her focus and aligns priorities with team priorities. Everything she is working on links to an issue.
    • Efficiency: The marketing team member is an excellent example of someone who can get multiple things done in a short amount of time. She can efficiently manage many high quality projects without getting bogged down in the details.
    • Collaboration: The marketing team member worked with the VP of Scaling to update the general handbook to make it prettier. This shows she collaborates well outside of her team. The marketing team member has also been helping a colleague with content management.
    • Directness: The marketing team member gives excellent review feedback on blog posts. She is very direct and not afraid of perfection.
  • A Product team member received a bonus for:
    • Collaboration: Works together well with everyone and actively recruits opinions across the organization.
    • Results: Shipping consistent and meaningful improvements in issues, board, etc.
    • Efficiency: Actively avoids meetings and encourages async work.
    • Iteration: Reduces everything to its very minimal iteration, not paying with quality or usability, yet moving forward with each release.

GitLab Awards Program

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.

The DZ Award

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:

  • The recipient of The DZ award will receive a one time cash bonus equivalent to $10,000 USD at using the local exchange rate. This is designed to honor DZ’s 10 years of contributions to GitLab and the recipient’s role in continuing DZ’s legacy.
  • Special designed GitLab Award and Headphone Stand

Criteria for The DZ Award

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:

  • OKR results and outcomes
  • Significant business result/impact from the boring solution in this Fiscal Year.
  • Contributions outside the general scope of the role (e.g. this award would not be granted for business as usual boring solutions)

Criteria not used to calibrate:

  • The team member holding a technical role or creating a solution to a technical problem is not a requirement to be nominated for this award.
  • Grade within the business - this award is not intended to be granted to only leaders, but instead available to all team members.
  • Talent Assessment - while we want to ensure we continue our pay for performance compensation philosophy, team members can be eligible for this award regardless of the output of the last review cycle.
  • The only criteria is that the team member would need to be in good standing (e.g. not on a PIP/recently received a Written warning).

The Values Awards

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:

  • There are six awards, one for: Collaboration, Results, Efficiency, Diversity, Inclusion and Belonging, Iteration and Transparency.
  • The recipient of each value award will receive a one time cash bonus equivalent to $5,000 USD at the exchange rate.
  • Special designed GitLab Awards medal.

Values Award Descriptions

Collaboration Award

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.

Results Award

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.

Efficiency Award

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.

Diversity, Inclusion & Belonging Award

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.

Iteration Award

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 valuable change (MVC) or low level of shame.

Transparency Award

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.

Criteria for value awards

  • Significant contribution or display of GitLab Value in this Fiscal year.
  • The contribution or display of GitLab Value led to tangible results.
  • The contribution or display was visible to team members outside of their direct team, customers, users or investors.
  • Contribution or display was outside the general scope of their role/Job Family responsibilities
  • ​​Truly exceptional work. Good and great is already expected in a team member’s work and performance
  • Team member is in good standing with the company (e.g. not on a PIP/recently received a Written warning).

Nomination process for awards

All team members can make nominations for both The DZ Award and Values Awards. When you submit a nomination, the People Communications & Engagement DRI will create a document looping in your manager and 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 to review the final nominations. The People Communications and Engagement DRI will coordinate the nominations for both awards and ultimately nominations will be calibrated at the E-Group level.

Overview of the nomination process

  • When the nomination window opens all team members can submit both Values Award and DZ Award nominations through this form.
  • The People Communications and Engagement DRI will create a document looping in the nominator’s manager and Department Head to review the nomination.
  • When the nomination window closes the People Communications and Engagement DRI will ensure all nomination documents are completed before calibration.
  • The People Communications and Engagement DRI and People Business Partners will then calibrate between department nominations with the E-group leader to select one team member nomination for The DZ Award and up to one team member per Value for the Values Awards.
    • Engineering and Sales will be able to nominate two team members for The DZ Award.
  • The nominations are finalized and E-group will discuss the nominees from each group and select the award winners.
  • The award winners will be announced.

Referral Bonuses

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 a Referral Bonus that work as follows:

  • We offer a referral bonus once the new team member has been employed with the company for 3 months.
  • In the past, we had a tiered system of referral bonuses, but we’ve simplified the structure to add a flat bonus amount.
  • $1,500 base referral bonus for a new hire.

We encourage and support diversity on our team and in our hiring practices and encourage team members to consider whether there are potential candidates in their networks who identify as members of underrepresented groups in tech.

Please note if the team member has a hire date effective before 2023-11-20, then the previous mentioned referral bonus amounts apply.

How to make a referral

For information regarding the program details and team member eligibility and understanding, please visit our guide in the Hiring section of GitLab’s handbook.

Exceptions

  • no bonus for hiring people who report to you directly or are in your direct reporting chain,
  • no bonus if you refer current team members,
  • no bonus for referring a Boomerang Team Member (returning team member),
  • no bonus if the referring Team Member is a part of the Talent Acquisition team - they are not eligible given the nature of their position is to engage candidates.
  • no bonus if there’s a perceived conflict of interest.
  • no bonus for VP level grade 12 or the Executive Group.
  • 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.
  • If the referral was submitted on or before 2022-06-01, then refer to the bonus amounts as listed under Referral Operations.

Referral Bonus Processing

  1. The People Connect team processes referral bonuses weekly out of the GitLab Referral Bonus Audit Workday report
  2. One Time Payments are added to Workday after reviewing the report and ensuring all qualifications have been met
  3. Payroll is notified of the completed bonus and can begin processing

Temporary Add-on Campaign additional tracking for payout

  1. Talent Acquisition Manager will track all referrals set to hired in the time period of Add-on campaign.
  2. Talent Acquisition Manager will notify People Connect by Slack or email, the first of the month that aligns with the referred new hire’s 3 month employment at GitLab.
  3. People Connect will follow the steps outlined above

GitLab Anniversaries

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.

Get Together Grant

The Get Together Grant is currently paused. Stay tuned to the #whats-happening-at-gitlab Slack channel and this page for updates.

In FY24, each E-Group member has been allocated a budget (can be for a specific quarter or split out between FY24-Q2 to FY24-Q4 as decided upon by the E-Group member in coordination with Finance) for team building events. Each E-Group member can use their discretion when using the budget. This budget should cover leadership offsites, team member get togethers, holiday parties, and other virtual events to drive team bonding.

See the previous process for reference

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:

  1. Each team member can expense up to $50 USD each quarter on a meal, activity, and/or ground transportation to spend time with a GitLab team member in-person. Or, up to $25 USD each quarter for a virtual Get Together on a remote activity, remote coffees or remote meals (yes, this means you can have a real coffee for your remote coffee chat).
  2. To use the grant, get together with a team member and expense up to $50 USD for in-person meet-ups or $25 USD for virtual meet-ups in Navan by selecting the Get Together Grant category in the dropdown the first month of every quarter (Feb, May, Aug) and writing whether your get together was live or virtual in the line items. The expense report must be submitted within 1 month of the Get Together. Please note, Get Together expenses that are submitted outside of these months will not be approved and any amount over the allotted $50 USD per person for in-person and $25 USD per person for remote get togethers will not be approved. Limit one Get Together Grant per person the first month of each quarter.
  3. Team members can plan, pay for, and expense a Get Together in an eligible month (Feb, May, Aug, and Nov) for an activity or expense that allows them to get together with another team member later in that quarter.
  4. Once you participate in a Get Together with another team member, share your experience and a few pictures for a chance to be featured in social by submitting this form.

Group Get Togethers

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.

Visiting Grant

All Visiting Grant and Significant Life Event Grant programs remain suspended.

FY23-Q3 Visiting Grant Program (completed)

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

The Original Visiting Grant Program (suspended)

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.

Significant Life Event Grants (suspended)

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.

GitLab Ultimate

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.

Last modified October 30, 2024: Add HelpLab step to discretionary bonus manager process (8e3e2278)
View page source - Edit this page - please contribute. Creative Commons License