Facilitation of the offboarding process is shared by the GitLab People Business Partners (PBPs), People Operations Specialists, People Experience Team, Team Member Relations Specialist and various Tech Stack Provisioners.
If you have any questions about the offboarding process, please review the Offboarding FAQ page.
The process to be followed will be guided by the nature of the offboarding at hand i.e. either Voluntary or Involuntary - both of which have been described in greater detail below. Each of the stakeholders listed play a critical role in ensuring that offboarding takes place in a manner that is efficient and best serves the unique needs and sensitivities surrounding the respective team members situation.
Offboarding officially commences once an Offboarding Issue has been created by the People Experience Team. This action is triggered by the submission of an Offboarding Workflow Form by the People Business Partner (PBP) responsible for overseeing the division in which the departing team member is based.
The form includes the following fields all of which will guide the People Experience Team in terms of when the process should commence and whether any factors unique to the offboarding in question should be kept in mind e.g. Garden Leave or Day to Turn Off Access.
|Team Member Name||As Detailed on BambooHR|
|Job Title||As Detailed on BambooHR|
|Termination Date||As Determined by PBP / Manager and Team Member|
|Garden Leave||Where Applicable (Non-US)|
|Last Working Day||Where Applicable (US)|
|Type of Offboarding||Voluntary or Involuntary|
|Regrettable vs Non-Regrettable||Further Detail Below|
|Offboarding Reason||Further Detail Below|
|Eligible for Rehire||Yes / No|
|Eligible for Alumni Channel||Yes / No|
|Team Member Location||As per BambooHR|
|Exit Interview Owner||PBP / Specialist|
When completing the form in instances of Voluntary Offboarding i.e. as a result of Team Member Resignation, the People Business Partner along with the Manager of the departing Team Member will need to give consideration to whether the offboarding could be considered Regrettable or Non-Regrettable - the explainations below should be used to guide the outcome:
The table below details the circumstances under which a Team Member will or will not be eligible for future rehire based on the primary reason for offboarding:
|Offboarding Reason||Re-Hire Eligibility|
|Elimination of Position||Yes|
|Values Misalignment||with Review|
|Job Satisfaction||with Review|
|Knowledge, Skills, and Ability||with Review|
|Mutual Decision||with Review|
|Not a fit for the role||with Review|
Opening of the offboarding issue which will in turn begin the process of systems de-provisioning will be aligned to the information presented by the People Business Partner within the Offboarding Workflow i.e. Termination Date / Last Working Day.
The People Experience Team endeavours to initiate the process within twelve hours of notification - sooner where possible however in instances of involuntary termination will work with IT Ops to ensure preliminary de-provisioning happens as required.
The People Experience Associates complete a weekly audit of all offboarding issues opened within that specific week and check that all tasks have been completed by all Departments. In the event that tasks are still outstanding, the People Experience Associate will ping the relevant Team Members / Departments within the offboarding issue to call for tasks to be completed.
Once all tasks have been completed, the People Experience Associate will close the offboarding issue and mark as completed in the offboarding tracker.
All offboarding tasks by all Departments need to be completed within 5 days of the offboarding due date. For systems that are more critical and time sensitive, these will be completed within the first 24 hours (example 1Password, Okta, Slack) by the relevant Departments. Information about application & system deprovisioners can be found on the Tech Stack Applications handbook page.
A voluntary offboarding occurs when a team member informs his or her manager of a resignation. The choice to leave GitLab was their decision.
If you are a current team member and you are thinking about resigning from GitLab, we encourage you to speak with your manager, your assigned PBP, or another trusted team member to discuss your reasons for wanting to leave. At GitLab we want to ensure that all issues team members are facing are discussed and resolved before a resignation decision has been made. This will allow GitLab the ability to address concerns and in return foster a great work environment.
If resignation is the only solution after you have discussed your concerns, please communicate your intention to resign to your manager. We would advise you to review your employment contract for the statutory notice period and determine your last working day. Then with your manager you can discuss the time needed to work on a handover/transition. If there’s no notice period included in your employment contract we would advise that you provide GitLab 2 weeks of notice. Depending on the situation and local laws, GitLab may choose to provide you payment in lieu of notice. Hereafter please review the below process which will be followed for a voluntary resignation.
employment statusof the team member.
Note: For GitLab UK team members, payroll can pay up to and including the 5th day of the following month. For example, if a team member's last day is February 2nd, the team member can receive their final pay for this in January's payroll.
#offboardingsSlack channel so all stakeholders can acknowledge the offboarding.
email@example.com, the People Operations Specialist team email inbox
firstname.lastname@example.org, as well as to the payroll lead. The PBP will indicate the last day, reason for resignation, and rehire eligibility in the email. Note: If the team member has a contract with a co-employer, the payroll lead will forward the email to the contact at the co-employer.
Contracts & Changesfolder.
Specialist: The Specialist handling the exit interview / survey process will add their name to column
AC in the offboarding People Exp/Ops Tracker as a DRI, or ping the other Specialists to be certain that there is a fair balance and rotation of who is the DRI.
Surveysfrom the top menu bar. Select
Exit Surveyand select the
startexit button - this will allow the People Specialist to assign the survey to the departing team member.
#pbp-peopleopsSlack channel to confirm that the notes have been added and that the Exit Interview has been completed. This ping will occur within 48 hours of the exit interview.
In the case an offboarding date needs to be updated, follow the next steps.
@people-expto update the following places.
The Exit Survey provides team members with the opportunity to freely express views about working at GitLab. People Operations Specialists will send the CultureAmp survey to all team members who are leaving voluntarily. If a team member leaves during a short notice and an exit interview cannot be scheduled prior to the team member leaving, one maybe scheduled after their offboarding date.
The People Specialist & the team member may proactively set up time to discuss their responses and ask for further information. Exit interviews are not mandatory, however your input will help provide GitLab with information regarding what is working well and what can be improved. Please point team member to the Offboarding FAQ page.
Follow this process to send out an exit survey to an inactive team member;
activateuser option - This will add them to CultureAmp until the next data sync. The sync runs daily at 1 am PDT.
send inviteon the right side of their name.
Culture Amp Exit Survey now has an additional "Reporting to" demographic. Initially, for reporting purposes we were using the "Manager" demographic which is no longer used on our account, i.e the data that syncs across from BambooHR is the "Reports to" field. However, this was not enabled on the actual exit survey. The "Manager" demographic was disabled on 19th November 2019. For reporting purposes, Culture Amp admins should use the "Reporting to" demographic while running reports on Culture Amp for team members who left after 19th November 2019 and the "Manager" Demographic for team members who left prior to that date.
All offboarding may request to be added to the Slack channel
gitlab-alumni by requesting through the PBP who can review the request and confirm to the People Experience Associate who can open an access request on behalf of the former team member.
Reasons that someone would not be permitted to join would be due to involuntary offboarding for extreme behavior or a violation of our Code of Conduct.
Underperformance or other causes for involuntary offboarding are not a reason to exclude someone from the alumni program.
The purpose of this channel is to network and socialize with team members.
Joining the channel is voluntary and subject to GitLab's Code of Conduct.
GitLab, the company, monitors the channel and can remove people from it at their sole discretion. The GitLab code of conduct is enforced in the channel.
Involuntary offboarding of any team member is never easy. We've created some guidelines and information to make this process as humane as we can. Beyond the points outlined below, make sure to refer to our guidelines on underperformance, as well as the offboarding issue.
If the need for Involuntary offboarding arises, the process is as indicated below:
Team members on
Last Working Date or
Garden leave will have no access to GitLab systems and may not be required to do any work on GitLab's behalf, but will still be active on payroll through the termination date. The People Experience team will generate the offboarding issue at the end of the team member's last working day, as per notification from the Team Member Relations Specialist (TMR) or the People Business Partner (PBP). Once the
Last Working Day or Garden leave expires the team member will be officially offboarded from GitLab. Prior to the offboarding issue and the overall process for the term listed below. The PBP will complete the following:
Last Working Day - Only for US Team members
Note: The offboarding process will remain the same as listed below in the
Involuntary Process section below. The People Specialist will notify the team via the confidential #offboardings Slack channel to start turning off the team member's access.
The manager and the team member should have walked through the guidelines on underperformance before reaching this point.
#Offboardingsconfidential Slack channel. The TMR will indicate the team member's name, last day, reason for resignation, and rehire eligibility. The first Specialist to respond to the post will be the Specialist that partners with the TMR for the offboarding process.
Severance Elgibilityguidelines accessible by PBPs, and Team Member Relations Specialist.
People Experience Associate: The PEA will confirm and coordinate the date and time of the offboarding and who will be available to assist with the offboarding. At this stage, the name of the departing team member is not yet shared. To share this information, the People Business Partner will complete the Offboarding Form. Once submitted a summary of the response will be posted to the
#offboarding Slack channel.
#team-member-updatesSlack channel to share with the wider team.
#team-member-updatesSlack channel until the team call has been completed.
#team-member-updatesSlack channel the following day.
Infrastructure Managersto determine who will be available to assist with the offboarding. Once an infrastructure team member has been identified, they should be added to the private calendar invite sent to People Experience, Security, and Payroll to hold the time for the team member offboarding. Once the offboarding conversation starts the TMR will privately Slack the infrastructure contact the name of the team member to start the offboarding process.
When on the call…
"Thanks for joining the call, [team member name]. Unfortunately, the reason I wanted to speak with you is because we have decided that we have to let you go and end your employment / contract with GitLab because of xyz."
#offboardingsSlack channel with the name of the team member to immediately start the offboarding process.
This form is used to help coordinate all necessary stakeholders for an involuntary offboarding. This will allow all stakeholders to be on standby to offboard the team member effeciently to prevent any possible security threats.
This form is located in the Offboarding Channel shortcuts.
The following points need to be covered for any team member:
The following points need to be covered for US-based employees:
If appropriate (to be determined by conversation with the manager, the Group Executive, and People Ops), use the following offboarding memo, which is provided here as an openly viewable Google Doc, but of course needs to be personalized and tailored to each individual's situation. As written, it is applicable to US-based employees only.
Separation and Release of Claims Agreements do not apply for all offboardings. To review in which cases they do/do not apply, please reference the
Severance Eligibility document accessible by People Specialists and PBPs. In the case that a severance agreement is applicable, the steps below should be followed:
Copies of Individual Severance Agreementsfolder.
assign signature orderoption in DocuSign to ensure the team member signs the document first
We treat team members equally and therefore do not take tenure into consideration when determining separation pay unless legally required. We know that other companies sometimes gives higher separation pay to longer tenure. We think that a short tenure can be harder to explain to a next employer and with a shorter tenure you might have less stock option upside, maybe you have not even reached your vesting cliff.
For team members who will be placed on leave during an investigation please follow the process below:
#offboardingchannel. Once you complete the form, a message will post to the slack channel, in this message thread you will find a message with a link to another form. This form is only needed/used when a team member is returning from leave.
For more information please review the handook page regarding the Leave during investigations.
To be documented
As explained briefly in the offboarding issue, GitLab does not provide any context around why people are leaving when they do. However as mentioned in the procedures, for voluntary offboarding, the team member can work with their manager on sharing a company-wide message about their departure.
Once the news has been shared with the team member’s team and other stakeholders, and messaging is agreed upon between the departing team members and their manager, the departing team member’s manager shares the following message company-wide about the team member’s upcoming departure in the
#team-member-updates Slack channel.
Managers can use this template as a guide on how to communicate a team member’s upcoming departure:
I want to share that [team member’s name] ([group] [role]) will be leaving GitLab, and [his/her/their] last day is (date of their last day). (Context to add about the team member’s time at GitLab - examples: their favorite contribution to the handbook or they can use the update to express gratitude towards teams and individuals that have made their experience at GitLab positive.) I would like to take this opportunity to thank (team member's name) for their contributions and wish them all the best for the future. If you have questions about tasks or projects that need to be picked up, please let me know. If you have concerns, please bring them up with your manager. To keep in touch with (team member's name) he/she/they can be reached at (contact info - e.g. LinkedIn, email, etc.)
If someone is let go involuntarily, this generally cannot be shared since it affects the individual's privacy and job performance is intentionally kept between an individual and their manager.
If you are not close to an employee's offboarding, it may seem unnecessarily swift. Please remember that these decisions are never made without following the above process to come to a positive resolution first - we need to protect the interests of the individual as well as the company, and offboarding is a last resort. According to our values negative feedback is 1-1 between you and your manager and we are limited in what we can share about private employee issues. Please discuss any concerns you have about another employee's offboarding with your manager or your People Business Partner.
Given the expectations and responsibility that come with a VP and above position, when there is an involuntary offboarding for one of these positions, additional context for the personnel change can be provided to the organization.
Silence is unpleasant. It's unpleasant because we are human, which means that we are generally curious and genuinely interested in the well-being of our team members.
Is it more unpleasant in a remote setting? Probably not. When people are all in the same office building, they can "kinda sorta" know what may be coming because of the grapevine, the water cooler, and so on. When the news hits it might be less of a shock - only because of unprofessional behavior in the first place. But at larger companies with multiple office buildings, departures will tend to come as more of a surprise and with less context (at least to the people in other buildings).
We strive to maintain personal information regarding all team members private, this includes information regarding a team members voluntary or involuntary departure from GitLab. However, a manager with the consent and approval of the departing team member can share more details with the GitLab team regarding the decision to leave GitLab.
For a voluntary departure a team member may have chosen to leave for many different reasons, career development, promotion, a new role or career path, dislike remote work, etc. For example, a team member may tell their manager that they really miss being in an office environment and remote work is not suitable for their personality. Based on that decision they have taken another opportunity that allows them to go to an office.
If the departing team member gives their manager permission to share that information then the manager will share while making the departure announcement on the team call. We want all GitLab team-members to be engaged, happy and fulfilled in their work and if remote work, the requirements of the job or the role it self are not fulfilling we wish our team members the best of luck in their next endeavor.
Regarding involuntary offboarding, certain information can also be shared with the GitLab team regarding the departure. Some team members do not thrive or enjoy the work that they were hired to do. For example after starting at GitLab a team member quickly learns they have no desire or interest to learn Git or work with Git. This doesn't make them a bad person, it just means they don't have the interest for the role and based on that the decision was made to exit the company. Again, we want all team members to enjoy and thrive in their work and that may or may not be at GitLab.
The departing team member may work with their manager to author a goodbye message for voluntary offboarding:
In some instances there will be no further clarification on why a team member has departed, if there are concerns you can address those with your manager. Different levels of transparency will exist based on maintaining respectful treatment for all departures. Having team members leave may be a learning opportunity for some, but should not be a point of gossip for anyone. Managers will need to balance the opportunity for learning with the expectation of privacy and consult their People Business Partner should they have questions.
Transparency is one of our values. In the case of offboarding transparency can be painfully specific, calling out an employee’s flaws, while inviting more questions and gossip. We opt to share the feedback only with peers and reports of the person since we balance transparency with our value of collaboration and negative is 1-1.
GitLab's turnover data is only viewable internally.
To track all tool deprovisioning, please open an offboarding issue following the offboarding guidelines.
As part of offboarding, any GitLab property valued above 1,000 USD needs to be returned to GitLab.
For laptops, please refer to the Laptop Buy Back Policy which states that team-members have the option to buy back their existing laptops either when it gets refreshed for a new one, or when the team member is offboarding. If the team member has completed 1 calendar year or more at GitLab at the time of laptop refresh or offboarding, they can opt to keep their laptop at no cost. If the team member hasn't completed 1 calendar year at GitLab at that time, they have the option to purchase their laptop for current market value.
To return your laptop to GitLab, please contact email@example.com immediately upon offboarding.
This section of the Accounting Department.
To remove someone from Expensify Log in to Expensify and go to "Settings" in the left sidebar. Select the right policy based upon the entity that employs the team member. Select "People" in the left menu. Select the individual's name and click "Remove". If the person has a company credit card assigned to them please notify Finance before un-assigning it.
For involuntary offboardings it is optional to do a retrospective on the hiring, onboarding and coaching/communication of the departing team member. As a manager, you can use this template for a retrospective. Please share the filled out template with your manager as well as the People Business Partner for your group.
Within the Engineering division this is a required process because it causes hiring managers to reflect on what led to the ultimate decision of parting ways with the team member, and how that might be prevented during future hiring processes.
Should a new hire be onboarded by the People Experience team, but:
This is not seen as a true offboarding, but there are still relevant steps to take.
As part of the country conversion process, the People Specialist team obtains information from our PEOs in each country regarding offboarding processes and requirements.
In the United States, unemployment insurance provides benefits to GitLab team members who have lost their jobs through no fault of their own. The purpose is to provide temporary financial assistance to employees who meet certain requirements. Unemployment insurance is administered at the state level in compliance with federal law. Each state establishes its own rules with respect to amounts, duration and eligibility for unemployment insurance.
Unemployment insurance is funded by employer contributions. Most states also have state unemployment taxes. With a few exceptions, employers typically pay the state unemployment taxes as well. Individual states establish eligibility requirements for unemployment benefits. To be eligible, employees are required to meet state requirements for earnings and for time worked during the base period. In some cases, the state may ask for more extensive wage details on a claim.
The People Operations Specialist team own the US Unemployment Claim process. Ashley Jameson is the GitLab US Unemployment Claim Designate since she is US-based, for this US process and she can be reached at
When unemployment claims are received, usually by company mail, they will be sent and reviewed by the GitLab US Unemployment Claim Designate. The designate will:
If you are a full-time team member and you are contacted by your state's Unemployment Commission to discuss your request for unemployment benefits, you may be a victim of unemployment claim fraud. Before giving out any information to the caller, please confirm that you are speaking with an agency employee. If you confirm with your state's Unemployment Commission that there is a fraudulent claim, please report it via email to
firstname.lastname@example.org. Additionally here is a link to the U.S Department of Labor Report Unemployment Insurance Fraud, which lists additional information.