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.
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 considering 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 to your manager your intention to resign. We would advise you to review your employment contract for the statutory notice period and determine your last working day. Then you will work with your manager to discuss the handover/transition plan. If there’s no notice period included in your employment contract we ask 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. Please review and follow the process below for voluntary resignations.
location and employment status of 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.
#offboardings Slack channel so all stakeholders can acknowledge the offboarding.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.
| Form Element | Guidelines |
|---|---|
| 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:
Regrettable Offboarding
Non-Regrettable Offboarding
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 |
|---|---|
| Relocation | Yes |
| Career Development | Yes |
| Elimination of Position | Yes |
| Compensation | Yes |
| Attendance | with Review |
| Values Misalignment | with Review |
| Job Satisfaction | with Review |
| Knowledge, Skills, and Ability | with Review |
| Mutual Decision | with Review |
| Other | with Review |
| Performance | with Review |
| Not a fit for the role | with Review |
| Conduct | No |
| Job Abandonment | No |
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.
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, Slack) by the relevant Departments. Information about application & system deprovisioners can be found on the Tech Stack Applications handbook page. - Important When submitting the form please ensure to use PST format, even applicable to team members located in EMEA and APAC regions. See the below as a guide or alternatively this conversion chart: For Example, If a team member is located in Japan their offboarding issue will be created at 04:00 PM their regional time (APAC, EMEA, AMER) or 12pm their regional time on Friday. on their last day of employment.
people-exp@gitlab.com, the People Operations Specialist team email inbox peopleops@gitlab.com, 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 & Changes folder.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.
Experience: The People Experience Team will determine who will create the offboarding issue according to the offboarding guidelines, and confirm this in the People Exp/Ops Tracker.
The People Specialist will review the team members calendar and add an exit interview event to their calendar. The invite will include a message about how this interview is optional. A brief training on how to start and conduct exit interviews can be found here (internal only)
* An offboarding email will be sent [automatically](https://about.gitlab.com/handbook/people-group/engineering/offboarding/#voluntary-offboarding-email) to the team member once the offboarding form has been submitted.
* The assigned People Specialist will then send out the Exit Survey via Culture Amp (using the Exit Survey template in Culture Amp) and communicate with the departing team member to mention that they would like to schedule a non-mandatory exit interview, to occur during the team member's notice period.
* To send the Exit Survey, log into Culture Amp and click on `Surveys` from the top menu bar. Select `Exit Survey` and select the `start` exit button - this will allow the People Specialist to assign the survey to the departing team member.
* Review the team members calendar and add an invite for an exit interview. In the event description add the following [note](https://gitlab.com/gitlab-com/people-group/people-operations/General/-/blob/master/.gitlab/email_templates/exit-interview-template.md). This is to ensure the team member knows this interview is optional.
* Remind the departing team member it is necessary to complete the [Exit Survey](#exit-survey) _prior_ to the Exit Interview so it can be discussed.
* Before the exit interview the interviewer (The People Specialist and/or People Business Partner) should make sure to carve out time to review the Exit Survey answers and prepare for the interview. If any voilations to our Code of Conduct are mentioned in the exit survey, these should be discussed first in the exit interview.
* Once the exit interview has been completed and all notes entered, the assigned People Specialist will ping the PBP in the `#pbp-peopleops` Slack 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.
Non Regrettable Offboardings:
Unless otherwise directed to follow the Regrettable offboarding process, an offboarding email will be sent automatically to the team member once the offboarding form has been submitted.
In the case an offboarding date needs to be updated, follow the next steps.
#offboarding channel.@people-exp to update the following places.
Termination folder.The Exit Survey provides those team members being offboarded with the opportunity to freely express views about working at GitLab. People Operations Specialists will send the CultureAmp survey to the appropriate team members who are leaving GitLab voluntarily.
The People Specialist and the team member may proactively set up time to discuss their responses and ask for further information. Exit interviews are not mandatory, however 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.
Should you want to provide feedback and are not given the opportunity for an interview, please feel free to send your feedback to the People Business Partner for your division, or Team Member Relations.
Follow this process to send out an exit survey to an inactive team member;
activate user option - This will add them to CultureAmp until the next data sync. The sync runs daily at 1 am PDT.send invite on 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:
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 Business Conduct and Ethics is enforced in the channel.
Involuntary offboarding of any team member is never easy. We've created 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:
The manager and the team member should have walked through the guidelines on underperformance before reaching this point.
#Offboardings confidential 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 Elgibility guidelines accessible by PBPs, and Team Member Relations Specialist.Time Off section.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-updates Slack channel to share with the wider team.
#team-member-updates Slack channel until the team call has been completed.#team-member-updates Slack channel the following day.Infrastructure Managers to 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."
#offboardings Slack channel with the name of the team member to immediately start the offboarding process.After the involuntary offboarding call has taken place and the last working day has been determined, team members will have no access to GitLab systems and may not be required to do any work on GitLab's behalf. If they are on "Garden Leave" they will still be active on payroll through the termination date. When determining the timing of the involuntary offboarding call and termination date it is important to consider any effect this might have on ongoing tasks and responsibilities of the team member. As a manager, in collaboration with the Team Member Relations Specialist (TMR) and/or the People Business Partner (PBP), we recommend to avoid scheduling the involuntary offboarding call while a team member is scheduled for any sensitive customer meetings or is on-call. If this is unavoidable, the manager is responsible for ensuring a transition/remediation plan.
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) and 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.
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.
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 Agreements folder.assign signature order option in DocuSign to ensure the team member signs the document firsttermination folderImportant Notes:
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:
#offboarding channel. 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
Depending on the team members’ role, timing of communication may vary (e.g. direct team, key stakeholders, etc.), and managers have discretion to determine who should be informed most immediately. The typical order followed for communicating departures is:
The "direct team" is typically the team member's peers within their immediate team (I.E. reporting to the same manager and/or in the same functional group, etc.) and is typically a relatively small group of people.
In most cases, team members communicate their departures to their direct team, though messaging should be cross-checked with their manager for consistency.
Key stakeholder communication can be done through 1:1 notifications, and/or by posting the update in team-specific channels for general awareness. Key stakeholders are individuals that departing team members work very closely with (typically in their day-to-day work) that will feel the impact of the team member's departure in their work. Managers of key stakeholders should also be looped into communication to ensure awareness.
It is essential that key stakeholders are looped in to offboardings to:
Departures should be communicated with stakeholders as soon as possible, with a maximum timeframe of 2 business days after the team member's departure.
Where possible and appropriate, we also encourage managers to work with departing team members to align on transitions plans to transition as much of the departing team members' work as possible before their departure.
In most cases, managers communicate team member departures to key stakeholders.
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).
Managers should consider cross-posting the message in #team-member-updates to inform the wider Department of the departing team member.
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:
#team-member-updates on Slack.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 itops@gitlab.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 Corporate Credit Card assigned to them, please notify Accounts Payable 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.
Note: Prior to start date- If a team member has been added to BambooHR and the Payroll Changes Sheet but does not start, their profile will be deleted from BambooHR. Notify the Payroll Team accordingly and make a note against their particulars in the Payroll Changes Sheet.
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 peopleops@gitlab.com.
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 peopleops@gitlab.com. Additionally here is a link to the U.S Department of Labor Report Unemployment Insurance Fraud, which lists additional information.