1. You are here:
2. Handbook
3. People Group
4. Contracts & International Expansion

Maintained by:

On this page

• On this page
• Team Member Types at GitLab
• Team Member Types by Country
  • GitLab Entities
  • PEO (Professional Employer Organization/ Employer of Record and not a GitLab entity)
  • Team members hired as Contractors via our GitLab IT BV Entity
• Employment and Contractor Agreements
  • United States
  • Belgium
  • Netherlands
  • Germany
  • Australia
  • New Zealand (subsidary of GitLab PTY Ltd, Australia)
  • United Kingdom
  • Canada
  • Japan
  • Other
  • Process for Suggesting Changes to the Contract Templates
• United States Employment Status
• Letter of Adjustment
• Probation Period
  • Important steps during the Probation Period
  • Probation Periods of Team Members Employed Through a PEO
• PIAA (Proprietary Information and Assignment Agreement)
  • Approval for Outside Projects & Activities (AKA Exceptions to PIAA)
    • Steps as a current candidate (actively engaged in the hiring process)
    • Steps as a current team member
• Usability Testing Consent
• International Expansion
  • Country hiring guidelines
  • Country Conversions
    • Phase 1: Pre-Conversion
    • Phase 2: Conversion
    • Contractor to PEO/Contractor Conversions
      • Gathering Benefits Information
    • Contractor/PEO to Legal Entity Conversion
    • Vendor Communications
    • Country Conversions Workflow
      • Country Conversion to PEO/Contractor Workflow
  • Compensation Review for Country Conversions
  • Relocation / Address Change
    • Short-Term Stay
    • Long-Term Relocation
      • Eligibility to Work
      • Long-Term Relocation Definition
      • How To Apply for a Long-Term Relocation
        • Approval
        • Relocation within the Same Country
        • Relocation to a New Country
    • How To Update Address In BambooHR
    • Contract Renewals
      • Netherlands Renewal Process

This page contains GitLab's Team Member contracts and many other things around how we have scaled team members in ~65 countries. The DRI for all GitLab Team Member contracts are the People Operations Specialist team. Any changes to any contracts should be requested to the People Operations Specialist team and will require approval from our Director of Legal, Employment.

Team Member Types at GitLab

• C2C means Company to Company
• IND means Independent

Team Member Types by Country

GitLab has a few different team member types. The following tables each show how we hire and scale in ~68 countries in the world, where we have entities, where we use Professional Employer Organisations, and how we add new countries to our list.

To ensure the accurate entry of information in BambooHR, we created this table as guidance of what is applicable in which location. When adding new team members to BambooHR, please ensure you use this terminology for accurate reporting.

More information related to payroll processes can be found on the Payroll handbook page.

GitLab Entities

PEO (Professional Employer Organization/ Employer of Record and not a GitLab entity)

There are multiple options for PEO (Professional Employer Organizations), also known as Employers of Record, in the market. This is not the exact list of providers GitLab uses, but is intended to help the wider community when looking for vendors:

• Safeguard (Mostly used as the Employer of Record for permanent employment.)
• CXC (Mostly used in locations where it is socially acceptable to be a Company to Company Contractor. Workers can usually choose to be contracted through their own limited company, or as a individual contractor, however in Russia we can only support Company to Company Contractors.)
• Global Upside (Mostly used as the Employer of Record for permanent employment.)
• Remote.com (Mostly used as the Employer of Record for permanent employment.)

This table reflects where we use PEO's currently:

Contact information for our PEO representatives is found in the Entity & Co-Employer HR Contacts note in the PeopleOps vault in 1Password. If a team member, manager or PBP has a question relating to a PEO, their process, or any related procedure for a PEO-employed team member, please email peopleops@gitlab.com and the People Operations Specialist team will liaise and find a solution with the PEO's support.

Team members hired as Contractors via our GitLab IT BV Entity

These are everywhere else, where we do not have an Entity or PEO.

Employment and Contractor Agreements

The following contracts are for reference only and are viewable by anyone with the link.

United States

• GitLab Inc., employee offer letter without OTE
• GitLab Inc., employee offer letter with OTE
• GitLab Inc., employee offer letter with director bonus
• GitLab Inc., employee offer letter with signing and director bonus
• GitLab Inc., employee offer letter with signing bonus
• GitLab Inc., part time employee offer letter without stock
• GitLab Inc., part time employee offer letter with stock
• GitLab Federal LLC, employee offer letter without clearance, without OTE
• GitLab Federal LLC, employee offer letter without clearance, with OTE
• GitLab Federal LLC, employee offer letter with clearance, with OTE

Belgium

• GitLab BV Belgium, Dutch & English employee contract without OTE
• GitLab BV Belgium, Dutch & English employee contract with OTE

Netherlands

For team members legally able to work and live in the Netherlands, we should use the GitLab BV contract template. PEO contract templates should be provided by the PEO directly. We should not use GitLab BV or GitLab IT BV contracts for PEO models.

• GitLab BV, Netherlands temporary/indefinite employee without OTE-Holiday Allowance Paid in May
• GitLab BV, Netherlands temporary/indefinite employee without OTE-Holiday Allowance Spread throught the year
• GitLab BV, Netherlands temporary/indefinite employee with OTE-Holiday Allowance Paid in May
• GitLab BV, Netherlands temporary/indefinite employee with OTE-Holiday Allowance Spread throught the year

Germany

• GitLab GmbH, employment agreement without OTE
• GitLab GmbH, employment agreement with OTE

Australia

• GitLab PTY Ltd, Australia, without OTE
• GitLab PTY Ltd, Australia, with OTE

New Zealand (subsidary of GitLab PTY Ltd, Australia)

• GitLab PTY Ltd, Australia, without OTE
• GitLab PTY Ltd, Australia, with OTE As of 1 July 2020, all team members in New Zealand will be employees of GitLab LTD Pty, the Australian entity. New Zealand new hires should use this New Zealand contract, which is governed by New Zealand law, even though the employer is an Australian entity.

United Kingdom

• GitLab UK Ltd, without OTE
• GitLab UK Ltd, with OTE

Canada

• GitLab Canada Corp, All Provinces except Quebec, employment agreement without OTE
• GitLab Canada Corp, All Provinces except Quebec, employment agreement with OTE
• GitLab Canada Corp, Quebec only, employment agreement without OTE
• GitLab Canada Corp, Quebec only, employment agreement with OTE

Japan

• GitLab GK employment agreement without OTE
• GitLab GK employment agreement with OTE

Other

Locations where we do not have an entity or Professional Employer Organisation or for anyone hired under Meltano, GitLab IT BV contractor agreements should _always_ be used. Kindly keep in mind that if you were hired under a GitLab IT BV or GitLab BV Contractor agreement, that we are continuously working towards a Scalable Employment Solution in these locations, and your contract will therefore change in future:

• GitLab IT BV, contractor agreement - C2C without OTE
• GitLab IT BV, contractor agreement - C2C with OTE
• GitLab IT BV, contractor agreement - Independent without OTE
• GitLab IT BV, contractor agreement - Independent with OTE

Process for Suggesting Changes to the Contract Templates

If any changes are needed to any one of the contract templates, please ping the Director of Legal, Employment, Senior Manager, People Operations or one of the People Operations Specialists to make the change(s). The following process needs to be followed by the People Operations Specialist team:

1. Create an Issue and tag the CES team with an explanation of what is being amended. This will act as a reference point in the future.
2. Open the relevant contract template, which automatically redirects to its original editable Google Doc.
3. If you have editing rights in the doc, change the document view to "Suggesting" mode (top right corner). If you do not have editing rights, you are able to make a comment on the doc or alternatively ping the People Ops Specialist team for assistance with having the suggestions added to the contract for approval.
4. Any edits that are made will then be made as a suggestion to the contract.
5. Once you have made the required changes, please tag the Senior Manager, People Operations as well as our Director of Legal, Employment to view and approve the relevant changes.
6. Once the changes have been approved, it is important to notify the Candidate Experience Specialist Team to update the contracts in Greenhouse.

No changes or edits should be made to the contracts without the required approval.

United States Employment Status

Fair Labor Standards Act: Exempt v. Non-exempt Employees

• Nonexempt employees are paid hourly and required to track and report all hours worked. If a non-exempt employee works more than 40 hours during a workweek, they are entitled to overtime pay. Overtime pay must have prior approval from the manager. Nonexempt employees are required to take two paid ten-minute breaks and one unpaid thirty-minute lunch break. As a fully distributed company, nonexempt employees are responsible for taking active ownership in ensuring they take the proper breaks. Please make the People Business Partner aware of circumstances where you feel compelled not to do so.
• Exempt employees are paid on a salaried basis, do not need to track their hours, and are not eligible for overtime pay. These employees must not spend more than 50% of their time doing nonexempt duties to remain exempt.
• For new positions, managers need to ensure the classification of the role is correct before sending an offer letter to the candidate. For guidelines on how to determine if a role is exempt or nonexempt, please reference the "Exempt vs Nonexempt Checklist" (which can be found on the google drive, but is only viewable to managers at GitLab). For positions that already exist, please verify the classification with People Ops Analysts.

Letter of Adjustment

When a team member receives any change in compensation and/or title we need to create a Letter of Adjustment instead of staging an entirely new contract. This document is signed by the Manager, Total Rewards or the Sr. Director, Global People Operations or the Chief People Officer and the team member through either DocuSign (if the adjustment was a transfer/promotion done through Greenhouse) or HelloSign (if the adjustment was not done through Greenhouse, e.g. cost-of-living increases). When a team member applies for and receives a new position through Greenhouse, a Letter of Adjustment is prepared in lieu of a new contract using DocuSign. The Candidate Experience Specialist will prepare the letter. Using the Offer through DocuSign - Letter of Adjustment template in Greenhouse the letter is Cc'd to the Total Rewards team for processing.

Effective dates for a letter of adjustment should be the first (1st) of the month or the sixteenth (16th).

Once the document has been signed, the Candidate Experience Specialist marks the individual as hired in GreenHouse. This will not initiate the team member to be exported to the HRIS (BambooHR), but if the team member is duplicated, reach out to the PeopleOps Engineering team. The signed letter is uploaded into BambooHR under the Contracts and Changes folder on the Documents Tab by the Total Rewards Analyst. The Total Rewards team ensures the information in HRIS and Payroll systems is updated.

Probation Period

Upon joining GitLab, some team members (location-dependent, see the below table for detail about each location) will have a probationary period between 3 and 9 months. Common practice is for contracts in each country to have the maximum allowable probationary period. In case of relocation to a different country or change of contract, if a team member has continued service with GitLab (tenure with GitLab has been uninterrupted) and they have already passed the probationary period of their original location or contract, they do not need to go through the probation period of their new location or contract. As per the onboarding process a notification in BambooHR would have been created.

The People Experience Team is responsible for managing the probationary period process internally (communication with the team member, their manager, confirmation of probationary period completion, and updating BambooHR), while the People Operations Specialist Team is responsible for managing relationships with legal counsel externally on a global scale to ensure compliance and iteration. If an exception request is made to end a probation period early, this should be escalated by the team member's manager to a skip-level and the People Business Partner via email. We will then evaluate the risk, performance and overall reason for the request. Further escalation to Legal might be necessary as well as decision making on how to proceed. There should be no expectation of approval.

Important steps during the Probation Period

For Managers

1. Managers are responsible for monitoring and specifically reviewing performance halfway through the probation period of their direct report.
2. If underperformance is an issue, or there is any hesitation regarding the successful completion of a probation period, this should be discussed immediately with the relevant People Business Partner.
3. 14 days prior to the end of their direct reports' Probation Period, the manager will receive an email from the People Experience Team, reminding them that their direct reports' probation period is coming to an end.
4. The Hiring Manager will respond confirming their approval of their direct reports' completion of their probation period, or that they are in discussions with their People Business Partner.

For People Experience Team

1. The People Experience team will be cc'ed on an email that is sent automatically as per the current email automation
   • If the email is not automatically sent out, then the People Experience Associate will need to create an issue and assign it to the People Group Engineer to triage.
2. From this email, they will log the team members name, manager's name, and probation period end date in the Probation Period tab of the People Exp/Ops Task Tracker
3. Once the Manager has confirmed that they are satisfied with their direct reports' performance, the People Experience Associate will send a confirmation email to the team member to notify them that their probation period has been completed. The PEA will cc people-exp@ gitlab.com and the manager.
4. The email thread between the People Experience team and the manager should be uploaded to the Contracts & Changes folder of the Documents tab of the direct reports' BambooHR profile.
5. If no response is received from the manager after 7 days, the People Experience Team will check in BambooHR if there has been an manager update or change and follow up with a second email and a private message in Slack.
6. If there is still no response after 10 days, the People Experience team will create a private Slack channel including the manager and relevant People Business Partner to get the needed confirmation.
7. If for some reason, a manager is not contacted prior to a team member's probation notice completion, the manager must still be contacted to notify them that a team member's probation period is over, using the relevant email template. This thread must be saved in the team member's BambooHR profile, in their Contracts & Changes folder.

Probation Periods of Team Members Employed Through a PEO

1. If the team member is contracted or employed through one of our PEOs, the People Experience Associate will also need to reach out to the appropriate point of contact for that PEO to inform them of the team member's probation period completion. That information is listed in the Entity & Co-Employer HR Contacts folder within the 1Password People Ops Vault.

2. If a manager is requesting an extension of a team members probation period who is employed via a PEO, the People Experience Associate will need to send an email to the appropriate point of contact to request an extention of a probation period.
3. Save this email to the BambooHR profile.
4. Update the BambooHR Job Status table with the new probation period.

Current Entities and Co-employers with Probationary Periods:

Countries without Probation Periods:

PIAA (Proprietary Information and Assignment Agreement)

GitLab strives to help its team members maintain the ability to work on projects that are unrelated to GitLab’s business, including other open-source projects. Our PIAA does not grant GitLab any rights to any creations that you may make that are not related to GitLab's business or the work you do for GitLab. That is, you are free to develop those creations without requesting approval in advance from GitLab.

If your employment contract was created prior to November 2017, we have created an amendment to the PIAA agreement which can be viewed here. It amends the 2A section of the PIAA. Please email the People Experience team who will complete and stage the document for signatures. The Amendment will first be signed by our Senior Director, People Success and then the team member.

Approval for Outside Projects & Activities (AKA Exceptions to PIAA)

Before beginning work on outside projects, second jobs, additional work - paid or unpaid, that could potentially impair your ability to perform your obligations to GitLab or could be deemed a conflict of interest, you must obtain approval in writing from your Manager, and further approval from your E-group leaders as needed, facilitated by the relevant People Partner for your department. This is also required to those at the offer stage who have yet to start their employment with GitLab.

Steps as a current candidate (actively engaged in the hiring process)

1. Once the candidate receives their employment agreement, they will list all outside projects and activities in Exhibit A of the PIAA section.
2. When the Candidate Experience Specialist receives the signed contract, they will review to see if the information was added to Exhibit A of the PIAA or if the candidate entered No or None. If content was entered, CES will notify the People Experience team in the #people-exp_ces private slack channel with the link to the candidate's Greenhouse profile.
3. The People Experience team will complete the approval process as described in the onboarding processes.

Steps as a current team member

1. Team member sends their request via email to their direct manager for approval and copies their relevant People Business Partner (PBP). Note: PBPs are not the decision-makers, but can flag any concerns or questions.

Information needed in the email:

• Project name (links to relevant website if available)
• Goal of the project/organization
• GitLab clients and/or team members who are involved in the project and scope of their involvement. (If applicable, please include tech stack used)
• Estimated time investment per week (in hours)
• Employment status/role in relation to the outside project (if applicable)

1. The manager will ask any additional questions if necessary. A manager may not approve a request for outside projects or activities for a variety of reasons, including team member performance. If the manager approves, they will then confirm this in the thread and add the applicable Director-level leader to the thread, for their review and approval. If the direct manager is also at a Director-level, they will add the next level leader (VP or C-level as appropriate) to the email thread for review and approval.
2. If the Director/next-level leader feels additional review and approval is needed, they will then add the next level leader (VP or C-level as appropriate) to the email thread. If this is not deemed necessary, the Director/next-level leader will respond indicating their approval. Note: A minimum of two leaders must approve all outside projects. Direct manager and Director-level are the usual levels. If the direct manager is at a Director-level, an additional level must approve.
3. If the next level leader (VP or C-level) feels additional review and guidance is needed, they will add the Director of Legal and any other relevant leader to the thread.
4. If a decision is made to approve and all approvals are documented, the PBP will forward the email to the People Operations Specialist team at peopleops@ gitlab.com for processing.
5. If a decision is made to deny, the People Business Partner will relay this to the team member, and then will forward the email to the People Operations Specialist team at peopleops@ gitlab.com for processing.
6. The People Operations Specialist will save the entire thread as a pdf to the team member's BambooHR profile in their Contracts and Changes folder.
7. The People Operations Specialist team will then respond confirming receipt and state that the entire thread has been saved in the team member's BambooHR profile.
8. For team members employed in the Netherlands, confirmation will be given in the form of the Authorization Letter. This letter must first be sent to the relevant E-group leader for signature, then to the team member. Once signed, this will be saved in the team member's BambooHR profile in the Contracts and Changes folder.

For any approved outside activity in which the GitLab team member will use their GitLab account, this activity must be stored in a separate, personal project. All other work completed as part of their GitLab employment or contract should be stored in a GitLab namespace with a GitLab copyright.

Usability Testing Consent

Consent Form for GitLab Usability Test

During this usability test, I agree to participate in an online session using my computer and telephone. During the session, I will be interviewed about the site, asked to find information or complete tasks using the site, asked to complete an online questionnaire about the experience, and I may be video recorded (together, these form the “Materials”).

I understand and consent to the use and release of the Materials by GitLab B.V. (“GitLab”). These materials will likely be made public. I understand that it is the discretion of GitLab to decide whether and how to use the Materials. I relinquish any rights to the Materials and understand the recording may be copied and used by GitLab without further permission. I hereby agree to release, defend, and hold harmless GitLab and its agents or employees, from and against any claims, damages or liability arising from or related to the use of the Materials, including but not limited to libel, defamation, invasion of privacy or right of publicity, infringement of copyright or trademark, misuse, distortion, blurring, alteration, optical illusion or use in composite form, either intentionally or otherwise, that may occur or be produced in taking, processing, reduction or production of the Materials, their publication or distribution.

I have read the above authorization, release, and agreement and I am fully familiar with the contents thereof. This release shall be binding upon me and my heirs, legal representatives, and assigns. I understand that participation is voluntary and I agree to immediately raise any concerns I might have.

If you have any questions after today, please contact {GitLab Contact Person}.

Please sign below to indicate that you have read and understand the information on this form and that any questions you might have about the session have been answered.

Date:{Date}

Please print your name: {Usability Tester Name}

Please sign your name:

Thank you!

We appreciate your participation.

International Expansion

Country hiring guidelines

At GitLab, we hire people from all over the world and all walks of life. Diversity, Inclusion & Belonging is one of our core values. However, as an all-remote company we do face challenges with hiring in certain countries. Each country has unique and complex rules, laws, and regulations, that can affect our ability to conduct business, as well as the employability of the citizens and residents of those countries.

We are growing and continuously expanding our hiring capabilities in a variety of geographies. However, at this time we are unable to hire employees and contractors in certain specified countries due to a variety of reasons. Specific country hiring information is discussed with potential candidates. GitLab is able to hire team members who are eligible to work in the location of their residence. GitLab cannot assist or facilitate a process to help you become eligible to work in a location if you do not already have that eligibility. The hiring in certain countries can be paused for a variety of reasons at any time. In other locations, hiring is not possible. Countries where hiring is either not possible or currently paused are:

• Iran
• North Korea
• Crimea
• Syria
• Sudan
• Cuba
• France
• Italy
• Brazil
• Spain
• China
• Portugal
• United Arab Emirates
• Sweden
• Argentina
• Serbia
• Chile
• Israel
• Turkey
• Kenya
• Denmark
• Costa Rica
• Singapore

Country Conversions

As GitLab continues to scale, we will be converting all team members to an employment scalable solution as per our OKR. Team members are hired in the following ways:

• Contractor through a PEO (Professional Employer Organization with a local presence)
• Employees through a PEO (Professional Employer Organization)
• GitLab entity

To better understand how we decide on what country to convert next, please follow this link to our risk matrix (this is an internal document, as this is unique to GitLab). We measure risk on both the total target cash & the number of team members in said location. To follow along on the progress, view our Country Conversions and Entity tracking issue(this link is internal to GitLab team members only).

This also aligns with GitLab's strategy and growth plans.

We were interviewed live by members of the Recruiting and People Business Partner teams, and we encourage all team members to watch this video with frequently asked questions about Country Conversions:

The People Operations Specialist is responsible for managing the country conversion processes outlined below.

Phase 1: Pre-Conversion

1. The People Operations Specialist team will pull a weekly report every Monday via BambooHR to review the amount of hires per country (this should include reporting on current offers). When we reach five team members in a country, this is the indicator to proceed with a country conversion (if that process is not already in progress). The People Operations Specialist team will rotate who pulls this report on a monthly basis. The monthly report owners can be reviewed in the Weekly Operations call agenda.
2. The DRI for Country Conversion decisions is our Director of Tax. All requests for converting a country will be sent by the Director of Tax to countryconversions@gitlab.com email alias and confirm the conversion priority (High-1 or High-2).
3. The People Operations Specialists will update the conversion status and link to the issue on the Country Conversion and Entity Creation Tracking issue. Add the statement HIRING PAUSED* to the Status of all converting countries.
4. The People Operations Specialists will notify the Recruiting team of the pause in hiring by pinging @gl-recruiting in the Country Conversion and Entity Creation Tracking issue.
5. The People Operations Specialist team will rotate which member of the team will be the country owner for the requested country. The assigned People Ops team member will send an email to all of our country vendors using the Country Conversions Quote Request template to request a quote from all current country vendors to compare benefits, cost, and ability to scale. The countryconversions@gitlab.com email alias should also be copied on this email for full transparency and visibility.
6. As the People Operations Specialist receives requested information from vendors, they should proceed with the following steps:

• Save all quotes in the appropriate vendor folder within the Country Vendor Information folder in Google Drive
• Add all data and team member information for the Country Conversions sheet found in the People Group Drive
• Create an issue in the People-Group general issue tracker by using the Country Conversions template

Phase 2: Conversion

Contractor to PEO/Contractor Conversions

1. The assigned People Operations Specialist sends an initial email to all team members currently located in the converting country and links the country issue so team members may follow progress and provide feedback.
2. In the created issue, ping all affected team members as well as all managers of affected team members. Comment to let the managers know that their direct report(s) is/are located in a country undergoing this process.
3. Once all country vendor quotes and benefits information are obtained, the People Operations Specialist will make a non-official country vendor recommendation based on: employee experience, social norms in the location, cost impact to the employee, overall SLA between GitLab and the country vendor, cost impact to GitLab, country vendor ability to scale and delivery quickly, alignment with our values, and meeting tech needs/digital way of working. This recommendation should be shared with the larger People Operations International Expansion for feedback in the #country_conversions Slack channel.
4. Once the initial recommendation is determined, the People Operations Specialist will ping the Manager of Total Rewards in the corresponding country issue, sharing benefits information from all vendors. Details of data gathering is mentioned in the Gathering Benefits Information section on this page.
5. The Total Rewards team will focus on benefits evaluation for the non-official country vendor recommendation first and aim to align the benefits package with GitLab's needs.
6. In the event that the Total Rewards team determine that the non-official country vendor recommendation is not a fit for GitLab's benefits needs, the People Operations Specialist will share the runner-up selection for benefits reviewal.
7. After a final recommendation is agreed upon, the People Operations Specialist country owner will send an email to the Director of Tax providing a comparative overview of the existing solution, all country vendor options, and rationale for the selected recommendation.
8. If the Director of Tax approves the recommendation, they will indicate written approval, and copy the CFO (Chief Financial Officer) on the email for final approval.
9. If the CFO approves the recommendation, proceed to the following steps. If the recommendation is not approved, the People Operations Specialist should proceed with investigating other options.
10. The People Operations Specialist will save documentation of the country vendor approval given via email by the CFO in the corresponding country folder found in the Country Vendor Information folder in Google Drive
11. The People Operations Specialist will send Payroll a note about the change that is coming and mention a follow-up confirmation will be sent once completed.
12. The People Operations Specialist will send the team member conversion email to team members and cc managers to share that a country vendor has been selected and the timeline for conversion. Note: All questions relating to the conversion should be sent to the People Operation Specialist via email with the countryconversions@gitlab.com email alias copied.
13. The People Operations Specialist should tag the Recruiting team in the country issue to confirm that a new country vendor has been selected and to highlight the conversion date.
14. The People Operations Specialist will search the handbook and update any mention of the country undergoing the conversion to "In Progress" so that any team member can be aware that a conversion is in progress. 
15. The People Operations Specialist should tag the Recruiting and CES team in the people-group-confidential Slack channel to confirm that a new country vendor has been selected and to highlight the conversion date.
16. The People Operations Specialist will check Contract Works to confirm the notice period with the current vendor (if applicable) and provide written notice as soon as possible.
    • Note: When written notice is provided to the current vendor, it is important that the Specialist confirms whether team members need to individually resign as well, and if so, what the timeline for individual resignations is.
17. The People Operations Specialist will complete the onboarding document for the country vendor that was selected. These templates are found in the Employee and Contracts Templates and Staging folder in the shared drive. These should then be sent to the main Account Manager of the selected PEO to confirm which local contact should be used for the conversion.
18. The selected vendor will share the drafted employment contracts with the People Specialist for review. The People Specialist should review the contracts themselves and seek additional feedback/approval from the Senior Manager, People Operations and Director of Legal, Employment.
19. The People Opertions Specialist will share a draft of the contract with the team members of the impacted country for additional feedback before having them signed.
20. The selected country vendor will then reach out to the team member and start the onboarding and contract signing process two weeks before the conversion date.
21. The People Operations Specialist will send a "heads up" email to the team members in the country converting regarding the Mutual Termination Agreement that will be shared using this template.
22. The Mutual Termination Agreements should be sent ~72 hours after team members have received their new contracts.
23. The People Operations Specialist will complete the Mutual Termination Agreement, found in the Drive called Employee and Contractor Templates and Staging mentioned above. This will need to be uploaded to HelloSign signed by both the team member and CFO in accordance with the new selected start date of the team member. The start date is usually within two calendar months after the initial conversion email was sent. Note: Once the Mutual Termination Agreement is signed, it is essential that it is uploaded to the team member's BambooHR profile in the Contracts & Changes section.
24. The People Operations Specialist will keep the issue created above up to date with any questions asked documented in the relevant section of the handbook.
25. The People Operations Specialist will update the Payroll team to confirm the change as well as the internal compensation calculator
26. The People Operations Specialist will update BambooHR with the team member status for: payroll type, location, and any other relevant updates.
27. The People Operations Specialist will notify the People Analyst team by emailing total-rewards@gitlab.com to audit BambooHR and other systems to ensure there are no pending updates.
28. The People Operations Specialist will remove the converted country from the Country Hiring Guidelines by searching for the country in the Country Hiring Status .yml file and changing hiring: false to hiring: true.
29. The People Operations Specialist will update the country status in the Country Conversions and Entity Creation Tracking issue to reflect the conversion as complete.
30. The People Operations Specialist will update to the entity mapper file.
31. The People Specialist will obtain the following information from each country-specific PEO regarding their offboarding process:

• What is the offboarding process?
• What is the notice period
• Which parts of the offboarding process does GitLab manage?
• Which parts of the offboading process does the PEO manage?
• What are performance management requirements?
• What are documentation requirements?
• Are there any templates you can share with us? (Ex. separation agreement templates, offboarding templates).
• What is the SLA for performance-related issues? (This needs to be less than 24 hours at least). The notice period will be documented in the entity mapper](https://gitlab.com/gitlab-com/www-gitlab-com/-/blob/master/data/entity_mapper.yml) file. All of the information obtained pertaining to the offboarding process will be stored in PBP Resources - Offboarding Documents and Templates - PEO Offboarding Processes

Gathering Benefits Information

To gather quotes from the Health Insurance/Life Insurance vendors, the Total Rewards team may need to share Team Members personal information with the PEO. This information can include: Name, DOB and Gender & the same details for Team Member’s Dependant.

Process of gathering information:

1. Total Rewards will email the team members to provide the required details as mentioned above.
2. For security, Team Members will upload the details in PDF format in BambooHR. (Documents » Employee Uploads Folder). We do not recommend team members replying directly via an email with personally identifable information.
3. The Total Rewards team will collect the information in a secure google sheet. Once all the details are collected, Total Rewards Team will share the details with the PEO via google sheets or a secured excel file.

Contractor/PEO to Legal Entity Conversion

1. The assigned People Operations Specialist sends an initial email to all team members currently located in the converting country and links the country issue so team members may follow progress and provide feedback. cc countryconversions@gitlab.com and nonuspayroll@gitlab.com, as well as the Sr. Manager, Global Payroll and Payments.
2. As soon as all legal requirements for the legal Entity are in place (bank account, entity name, payroll process) and you receive confirmation from the Director of Tax and Payroll that it is prudent to do so, give notice of termination to current PEO. In the issue, state that notice has been given and list the go live date for the Entity.
3. Ask the current PEO of the overlap or transition time. Certain PEOs require two weeks of transition time where they cannot hire any new team members. This means that new hires will not be able to start in this location during these two weeks, unless there is a contract ready for the entity.
4. In the created issue, ping all affected team members as well as all hiring managers of affected team members. Comment to let the hiring managers know that their direct report(s) is/are located in a country undergoing this process.
5. Ping the Total Rewards team in the issue, so that they may provide benefits information as it is received.
6. The People Operations Specialist will arrange a kick-off call with all team members in this location to communicate that we are transitioning and the transition date. There should be payroll and total reward representatives on the call to answer any questions the team members will have.
7. The People Operations Specialist will send the team member conversion email to team members and cc managers to confirm the conversion date and next steps. Note: All questions relating to the conversion should be sent to the People Operation Specialist via email with the countryconversions@gitlab.com email alias copied.
8. The People Operations Specialist should tag the Recruiting team in the country issue to confirm that the country is being converted to a legal entity and highlight the conversion date. Communicate any PEO overlap or transition time, per item 3.
9. The People Operations Specialist should tag the Recruiting Operations, Recruiting, and CES team in the people-group-confidential Slack channel to confirm that the country is being converted to a legal entity and highlight the conversion date. Communicate any PEO overlap or transition time, per item 3.
10. The People Operations Specialist will search the handbook and update any mention of the country undergoing the conversion to "In Progress" so that any team member can be aware that a conversion is in progress. 
11. The People Operations Specialist will share a draft of the contract with the team members of the impacted country for additional feedback before having them staged.
12. Four weeks prior to the conversion date, the People Operations Specialist should prepare and stage the new contracts in HelloSign. Always send any contracts to the Team member's personal address in BambooHR and not to their GitLab email address.
13. Once new contracts are signed, the People Operations Specialist should save copies in each team member's BambooHR profile, in the Contracts & Changes folder.
14. The People Operations Specialist will send a "heads up" email to the team members in the country converting regarding the Mutual Termination Agreement that will be shared using this template.
15. The Mutual Termination Agreements should be sent ~72 hours after team members have received their new contracts.
16. The People Operations Specialist will complete the Mutual Termination Agreement, found in the Drive called Employee and Contractor Templates and Staging mentioned above. This will need to be uploaded to HelloSign signed by both the team member and CFO in accordance with the new selected start date of the team member. The start date is usually within two calendar months after the initial conversion email was sent. Note: Once the Mutual Termination Agreement is signed, it is essential that it is uploaded to the team member's BambooHR profile in the Contracts & Changes folder.
17. The People Operations Specialist will work with Total Rewards, local counsel and Legal to create a new Time Off policy (if applicable). Document this policy in the handbook, add it to BambooHR and add all team members to said policy with the correct policy start date.
18. The People Operations Specialist will keep the issue created above up to date with any questions asked, documented in the relevant section of the handbook.
19. The People Operations Specialist will update the Payroll team to confirm the change as well as the internal compensation calculator.
20. The People Operations Specialist will update BambooHR with the team member status for: payroll type, location, and any other relevant updates.
21. The People Operations Specialist will update to the entity mapper file.
22. The People Operations Specialist will notify Recruiting Operations to update the dropdown for entity in Greenhouse.
23. The People Operations Specialist will notify the People Analyst team by emailing total-rewards@gitlab.com to audit BambooHR and other systems to ensure there are no pending updates.
24. The People Operations Specialist will update various handbook links, including: remove the converted country from the Country Hiring Guidelines by searching for the country in the Country Hiring Status .yml file and changing hiring: false to hiring: true; update the Employment Types at GitLab and collaborate with the Candidate Experience Specialist team to update the Contracts & International Expansion page.
25. The People Operations Specialist will update the country status in the Country Conversions and Entity Creation Tracking issue to reflect the conversion as complete.
26. The People Operations Specialist will update to the entity mapper file.
27. The notice period will be documented in the entity mapper](https://gitlab.com/gitlab-com/www-gitlab-com/-/blob/master/data/entity_mapper.yml) file and the remaining information will be documented in the Process for Team Members Outside of the US section of the Offboarding handbook page.

Vendor Communications

• Our primary source of communication with vendors is over email. In the event that our vendor can join a slack channel we must ensure that this is only for sharing non-critical and non-sensitive information - in the event that this information is shared please ensure to screenshot and save in the country/vendor-specific folder here.

Country Conversions Workflow

Below is a visual workflow that summarizes the country conversions process.

Country Conversion to PEO/Contractor Workflow

Compensation Review for Country Conversions

As part of the country conversion and benefits review process, the Total Rewards and People Operations team will review the gross value of cash compensation and benefits while also ensuring alignment to the employee rate in the compensation calculator.

The total rewards and people ops specialist team should also review alignment to the compensation ranges based on the new employee status and the range of the compensation calculator. Whenever we change salaries as part of a country conversion, these should be consistently applied among all team members in that country.

Relocation / Address Change

This process is managed by the People Operations Specialist team as the DRI, in partnership with Total Rewards and the People Business Partners.

Short-Term Stay

If you are not changing your permanent location (where you pay taxes and maintain residency), but instead are traveling to different locations over a period of time, you are responsible for maintaining your health insurance, visas, and any other item directly relating to your travel.

Since any short-term stay is your decision and not required by GitLab as part of your role, you will not be eligible to utilize the Business Accident Travel Policy or submit any expenses related to your travel. If you are hired in a role requiring a time zone alignment, you must still be able to fulfill that requirement.

If your short-term stay is for less than 6 months in a new location, there is no need to update your address in BambooHR. If you plan on staying in a location for more than 6 months, that becomes your residence and you must complete the long-term relocation process described below before any transition to that location. Team members must confirm with the people specialist team before they plan on working from a new location for 6 months or less. In most countries, tax residency is determined by the place where a GitLab Team Member keeps its vital interests. This is the place where you are registered, where your SO and/or dependents live, the place where you work, where you live, where you keep your subscriptions etc.

Long-Term Relocation

Eligibility to Work

If you are interested in a possible long-term relocation (defined below), you need to confirm that you are eligible to work in that location without any interference or aid from GitLab, please refer to our Visa page for more information about this. If you do research and see that you could be eligible if GitLab completed a task, even if it is just a letter, unfortunately that is not possible. GitLab cannot assist or facilitate a process to help you become eligible to work in a location if you do not already have that eligibility. You are of course free to apply and gain that eligibility if there are steps you can take that do not involve GitLab.

Once you are certain that you are eligible to work in your requested Relocation location, upload proof of your eligibility to the Employee Uploads folder in the Documents tab of your BambooHR profile. This eligibility needs to be for your employment as an employee or contractor, as different countries have different hiring models but the eventual goal is to convert all contractors to employees so we do need to know that you are eligible to be employed under all models.

Long-Term Relocation Definition

Different than business travel, vacation, or visiting a relative for a few weeks, a relocation means that you will establish yourself in a new location outside of your current metro area. If you are ending your current residential living arrangement, spending more than six months in one location as part of an extensive period of travel and/or will have your mail delivered to an address in a different city, please follow the steps below.

Please note, it is at the company's discretion to offer you a contract in your new location. Here are some examples why that is the case:

• There are some countries where we cannot hire team members. In these cases, GitLab would not be able to offer a new contract to you.
• Some job positions at GitLab require team members to be located in specific locations. For example, a salesperson hired to serve a specific region.

At the time of the location update, and assuming that we can make an offer in that location, we will take into consideration your new metro region when determining your compensation in that region.

At the onset, this practice sounds harsh when moving to a lower-paid region. One might argue that it seems unfair for the organization to pay someone less for the same work in the same role, regardless of where they go. However, if you look at it from another angle for a minute and compare this practice to what most companies do, it should make more sense. For example, say you work for a company with physical locations and say they haven't accepted that remote work is as productive as coming into the office yet. If you wanted to pack up and move to a location where they did not have a physical site, you would have no alternative but to resign and seek new employment in your new location. You would find quickly that companies in the area pay at a locally competitive rate.

Now, let's say the company did have a site in your new location and they offered the flexibility to transfer. If they did not have a similar position open, you would have to either apply for a different open position in the same company or resign and apply externally (back to the realization that other companies will pay at local competitive rate). If you were lucky enough that they did have a similar role in the new location, a transfer would come with a pay rate based on the local market to ensure equity across all incumbents (people in the job) by location.

Adjusting pay according to the local market in all cases is fair to everyone. We can't remain consistent if we make exceptions to the policy and allow someone to make greater than local competitive rate for the same work others in that region are doing (or will be hired to do). We realize we might lose a few good people over this pay policy, but being fair to all team members is not negotiable. It is a value we stand behind and take very seriously.

If you are considering a move it is best to discuss this with your manager as soon as possible, always before you are thinking of moving, to understand the impact to compensation or your role at GitLab. In almost all situations the compensation may change. In some instances a move will not align to your proposed location, (e.g. a recruiter hired in EMEA to support EMEA would not be approved to move to the US). It is the company's discretion to offer you a contract in your new location or to not continue with your contract based on a relocation. For an idea about the impact please check with our Total Rewards team for an accurate salary in the new geographical area, we also do involve the Total Rewards team during the process, the actual amount will be reviewed and will need approval before a relocation is approved.

How To Apply for a Long-Term Relocation

If you are going to spend six months or more in one location this will be considered as a relocation and your compensation will be evaluated based on the new geo area.

Approval

Team Member Please start this process more than 3 months before your ideal relocation date, if the relocation request is to a different country, or more than 30 days prior to your requested relocation date if the relocation is within the same country.

1. Per the Eligibility to Work section above, confirm that you have uploaded proof of your eligibility to work in your requested relocation location and explain this eligibility, as well as your timing and plans in your email to the People Operations Specialist team at peopleops@ gitlab.com.

Note: Any applicable changes in compensation will not be effective until your move date (or the date you start working in the new location), which will be listed as the effective date on your new contract.

People Ops, Total Rewards, PBP's & Payroll

1. If the relocation request is to a country where we currently do not have team members, the Employment Solutions Specialist will check the Country Conversion and Entity Creation Tracking issue whether the location is blocked for hiring. If the location is not included in either table on the main issue, the Employment Solutions Specialist will reach out to the Director of Legal and the Director of Tax, to confirm whether the country is blocked or open for hiring.
2. People Ops will confirm eligibility, documentation, timing and any other information as applicable. If the team member is not eligible to relocate, the Employment Solutions Specialist team will communicate this fact to the team member at this time.
3. If there is uncertainty on eligibility or any other questions, the Employment Solutions Specialist can escalate to the Senior Manager, People Operations, Director of Tax, and Director of Legal for further review from a legal and/or tax perspective.
4. If the relocation is within the exact same geographical location as linked to their current location factor, no approval is needed, but the team member's manager and relevant People Business Partner are still notified, and the notification email is saved in the team member's BambooHR profile. Direct the team member to update their address in the Personal tab in their BambooHR profile.
   • The Employment Solutions Specialist will confirm that the address has been updated in BambooHR and confirm to all team members involved that the relocation process is complete and that there are no other steps.
5. If the team member is eligible to work in their requested relocation location and there are no employment barriers, the Employment Solutions Specialist will request written approval from the team member's manager and relevant People Business Partner. The People Business Partner should connect with the manager to confirm there are no existing performance concerns. If there are, follow up discussion may be needed. This still applies if the relocation is within the same location factor in the same country.
6. If the relocation request relates to a higher location factor, forward both approvals to the team member's Division's E-Group leader for their written approval. Where applicable, copy in the Director and VP of the Division in the email to the E-Group Leader, as they are closer to the process. This is to create visibility for them and an opportunity for them to halt the relocation if need be.
7. If the relocation request relates to a lower location factor or equivalent location factor (even if it is in the same country), continue to the next step.
8. If the relocation is declined at any step, the People Operations Specialist will relay this to the team member and explain the reasoning.
9. The Employment Solutions Specialist will forward all approvals to the Total Rewards team at total-rewards@ gitlab.com so that they may review and approve any compensation change, with feedback from the manager and the People Business Partner.
10. Total Rewards will communicate final compensation information by email to the Employment Solutions Specialist team in the email thread.
11. The Employment Solutions Specialist will convert the approved compensation from USD to the local pay currency of the team member's new location, use the rounding best practice method, and then request approval from Total Rewards of this final compensation amount. Ex. Team member is approved $50,000 USD as their new comp and they are relocating to the Netherlands. Team members in the Netherlands are paid in Euro. Using the Jan 1, 2020 conversion, this converts to 44,577.20 Euro. Using the rounding best practice, the team member's comp will be 44,600 Euro, with Total Rewards approval.
12. The Employment Solutions Specialist will convey to the team member that their relocation has been approved and relay their new compensation, if applicable. cc the relevant Payroll team (uspayroll @gitlab.com or nonuspayroll @gitlab.com) for visibility on any upcoming changes.
13. The People Operations Specialist will ensure that all approval documents including email threads are saved in the team member's BambooHR Contracts & Changes folder.
14. The Employment Solutions Specialist will reach out to the People Experience team to prepare a Letter of Adjustment/ New contract where applicable.

Relocation within the Same Country

People Experience Associate

1. Create a letter of adjustment confirming the new location, location factor, and effective date in the Employee and Contracts Templates and Staging folder in the shared drive.

• A letter is only needed if there is a compensation change. If there is no change in compensation, then the People Operations Specialist should direct the team member to update their address in the Personal tab in their BambooHR profile.

1. Once the letter of adjustment has been created, ping the People Experience Associate or People Specialist team for auditing.
2. Stage the letter in HelloSign and send for signature first to the Senior Manager, Total Rewards and subsequently to the team member.
3. Upload the signed document to the team member's Contracts & Changes folder in BambooHR.
4. Make any necessary updates to the team member's BambooHR profile and email Total Rewards total-rewards@ gitlab.com and Payroll uspayroll@ gitlab.com or nonuspayroll@ gitlab.com to notify them of the changes.

Team Member

1. Update your address in the Personal tab in your BambooHR profile. Your address will then turn grey until it has been approved by the Total Rewards team.

Total Rewards

1. Confirm documentation of all necessary approvals.
2. Approve address change request in BambooHR.
3. If a compensation change is required, audit the team member's compensation details in BambooHR.
4. Update the appropriate payroll file (no need to follow this step for contractors).
5. For US team members - update the locality in BambooHR and update the benefit group if required.
6. If the team member is moving from one entity to another (certain countries have more than one entity), list them as terminated on the appropriate payroll changes file for the current entity and add them as a new hire in the appropriate payroll changes file for the new entity.
7. Check that any necessary changes to payroll and benefits administration are processed in time.

Relocation to a New Country

People Experience Team

1. Create a new contract for the team member confirming new compensation (if applicable) and effective date.
   • If the team member is relocating to the Netherlands ask them for their preferred method of administering their Holiday Allowance
   • There are two options:
     • Spread across 12 months which means their pay frequency will be 12 months
     • To be paid out in the month of May, which means their pay frequency will be 12.96
2. Once the contract has been created, ping the People Experience Associate or Manager, People Operations for auditing.
3. Stage the contract in HelloSign and send for signature first to the Senior Director, People Success and subsequently to the team member.
4. Upload the signed document to the team member's Contracts & Changes folder in BambooHR. -If the team member is relocating to the Netherlands, People Experience team will prepare another letter stating that it’s of economic importance that the team member is travelling to the Netherlands, and why it’s of economic importance. Besides this, the letter needs to state a reason why this work must be done from the Netherlands at this moment and not from abroad and why the travel can’t be postponed. The letter is for the airline and not for the IND.The airline decides based on the letter from the IND and employer’s letter if the person can go on the plane.The following templateshall be used.
5. If applicable, create a Mutual Termination Agreement. Stage in HelloSign and send for signature first to the Senior Director, People Success and subsequently to the team member. Upload the signed document to the team member's Contracts & Changes folder in BambooHR.
6. Make any necessary updates to the team member's BambooHR profile and email Total Rewards total-rewards@ gitlab.com and Payroll uspayroll@ gitlab.com or nonuspayroll@ gitlab.com to notify them of the changes.
7. Employment Solutions Specialist - Update the hiring manager and PBP in the original email thread that all tasks assigned to the DRI: Employment Solutions Specialist relating to the relocation process are complete, for clarity. Other teams, such as Total Rewards and Payroll may still be updating their systems.

Team Member

1. Update your address in the Personal tab in your BambooHR profile. Your address will then turn grey until it has been approved by the Total Rewards team.

Total Rewards

1. Confirm documentation of all necessary approvals.
2. Approve address change request in BambooHR.
3. If a compensation change is required, audit the team member's compensation details in BambooHR.
4. Update the appropriate payroll file (no need to follow this step for contractors).
5. For US team members - update the locality and region (if required) in BambooHR. Also uncheck their I-9 Processed field.
6. For US team members - Update the benefit group to INELIGIBLE and notify Lumity about the relocation with effective date.
7. If relocation is from one entity to another, list team member as terminated on the appropriate payroll changes file for the current entity and add them as a new hire in the appropriate payroll changes file for the new entity.
8. If relocation is from the US to outside of the US, change the benefit group in BambooHR to INELIGIBLE and send an email to Lumity with the termination date and coverages to be terminated.
9. If relocation is from outside the US to the US, place team member in the appropriate benefit group in BambooHR and send an email to Lumity with the relocation effective date.
10. Check that any necessary changes to payroll and benefits administration are processed in time.

How To Update Address In BambooHR

• Log into BambooHR
• On the Home tab, click My Info or hover over your job title and click View My Info
• In the Personal tab, scroll down to the section where your current address appears
• Make address changes
• Click Save Changes

Your request will be sent to the Total Rewards team for final review and approval. Until the change is approved, which usually occurs within 24 hours, your address section will be greyed out.

Contract Renewals

The below process can be used for the following:

• Temporary contract to indefinite contract
• Temporary contract to temporary contract (after the initial contract expires)
• Contract update for invoice purposes due to individual incorporation of an entity Note: In most cases this process will apply specifically for team members in the Netherlands.

When creating a new contract, if it is to be for 12 months, that timeframe is always to be written as (for example):

• Jan 1, 2010 to Dec 31, 2010
• Feb 20, 2004 to Feb 19, 2005

When renewing a contract, if it is to be for 12 months, the timeframes are at be seen as (for example):

• First 12-month contract starts on June 14, 2019. That entails that the contract ends on June 13, 2020.
• Second 12-month contract will start on June 14, 2020 and end on June 13, 2021.

1. Using the Relocation & Contract Renewal's tracker view the upcoming team member contract expiry's. On the sheet you will see the People Operations Specialist owner, if you are the owner be sure to note the end date and start the below process 2 months before the end date.
2. Take note of the team members details and reach out to the team members manager via email using the following template, be sure to CC the team members People Business Partner.
3. Once you have received confirmation on next steps from the team members line manager be sure to save the thread under the team members profile on BambooHR.
4. Using the correct contract template from the templates folder complete with required team member details. These details can be found on the team members BambooHR profile.
5. Do not keep the Stock Options line in the Key Terms section, unless additional shares are being given.
6. When you have a completed contract be sure to allow a team member to peer review it for you. This can be done by posting the document link in the People Ops private slack channel. Indicate that you are reviewing it by using the 'Eyes' emoji.
7. Once reviewed, stage the contract for signing in HelloSign.
8. Ensure that the GitLab signatory is the first to sign, followed by the team member. This can be done by selecting the assign signing order option.
9. When signed by both parties, save the contract to the team member's BambooHR profile in the Contracts & Changes folder.
10. Update BambooHR to reflect the correct Job Information. Ensure the new contract information is added along with an end date if applicable.
11. Notify the Total Rewards team so that they may audit any BambooHR changes.
12. DE (Germany) contracts only: If no payroll information is on file, send a payroll questionnaire from HelloSign. Once completed, upload to BambooHR and email nonuspayroll@ gitlab.com to notify.

Netherlands Renewal Process

1. Two months before the contract ends, the People Experience Associate sends an email to the manager and People Business Partner of the team member, notifiying them that their first 12-month contract is ending.
   • Set Due Date to give you 3 weeks to stage contract
2. Best practice and procedure at GitLab is to supply a second temporary 12-month contract. After two consecutive year-long temporary contracts, if the team member is in good standing, they are given an Indefinite Agreement beginning at the team member's third year with the company.
3. The Manager has then 3 weeks to evaluate the performance of the team member and discuss the planned course of action with the People Business Partner
4. At least 1 month before the end of the contract, the manager informs the People Operations team on whether to extend the contract and for what term.
5. At least 1 month before the end of the contract, the manager informs the team member of the extension or not. The People Business Partner can help with providing guidance on the messaging.
6. The People Operations team documents the emails in the Contracts & Changes folder in BambooHR.
7. If the contract extension is approved, the People Operations team creates the contract and stages it via HelloSign for the team member and Senior Director, People Success (on behalf of CPO if there is no current CPO) to sign.
8. Note: A second probation period should only be implemented if the team member's new contract reflects the start of an entirely new role. If the contract is simply a continuation of employment in the current role, a second probation period should not be applied.
9. The People Operations Team will then password-protect the signed contract and email to HR Savvy.

Note: A team member cannot have more than three temporary contracts with the same employer in a row. If a fourth contract is offered by GitLab then it must be a permanent one.

Important: Best practice for team members in the Netherlands is to issue two consecutive 1-year Temporary Contracts prior to moving to an indefinite contract. After the completion of two consecutive 1-year Temporary Contracts, we move to the indefinite contract. Should a team member request an indefinite employment contract after the initial 1-year Temporary Contract, approval via email should be requested based on performance from the team member's manager as well as the People Business Partner and a Division leader.