The offboarding process is facilitated by the People Connect team who collaborates throughout the process with various other stakeholders such as Team Member Relations, IT Operations and Payroll.
If you have any questions around the offboarding process, please be sure to review the Offboarding FAQs handbook page.
Note: Departing team members will receive a comprehensive email prior to their final date of employment with information such as the impact on benefits coverage, final pay, arranging for a laptop wipe and stock administration.
For system access questions and laptop wipes related to offboarding, send an email to itops@gitlab.com.
For payroll questions or outstanding expense claims, please reach out to either uspayroll@gitlab.com or nonuspayroll@gitlab.com.
For any other offboarding questions, please reach out to People Connect via people-connect@gitlab.com or directly in the #people-connect Slack channel.
Note: If a termination date changes, please reach out to People Connect via email. The team will update Workday and will alert the Payroll team. The email is used as supporting documentation of the change and is saved in the team members Workday record. If the team member is employed via a PEO, they will also be notified by People Connect.
Send Back. If you are satisfied with the information, click Approve.Actions followed by Job Change and finally Terminate Employee.Approve. In the instance that you feel further discussion is required a sync with the Manager and/or Team Member should be arranged and the particulars can be sent back for further review.location and employment status of the team member e.g. GitLab Ltd (UK) Resignation Acknowledgement and GitLab BV (Netherlands) Resignation Acknowledgement.Note: 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.
Note: Involuntary terminations are only facilitated by Team Member Relations (TMR) who will initiate the process both in Workday and in the #offboardings slack 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.
The manager and the team member should have walked through the guidelines on underperformance before reaching this point.
Severance Elgibility guidelines accessible by PBPs, and Team Member Relations Specialist.Time Off section.#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 Connect, 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.#offboardings Slack channel with the name of the team member to immediately start the offboarding process.Actions followed by Job Change and finally Terminate Employee.Approve. In the instance that you feel further discussion is required a sync with the Manager and TMR in question should be arranged and the particulars can be sent back for further review.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.
People Connect 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.
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 Connect Team 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 firstImportant 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.
The People Connect member in the relevant rotation will complete a weekly audit of all offboarding issues opened within that specific week and check that all tasks have been completed by all Team Member and/or Departments. In the event that tasks are still outstanding, the People Connect member will ping the relevant Departments within the offboarding issue to call for tasks to be completed.
Once all tasks have been completed, the People Connect Member 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 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.
To ensure a successful completion of the offboarding issue, it is important that all tasks are checked off, whether the system/tool is applicable to the offboarding team member or not. Checking the box indicates one of the following:
Voluntary exits that are eligible to be rehired and have been with GitLab longer than 6 months will be added to the Slack channel gitlab-alumni. The offboarding details provided by the Manager in Workday is how eligibility is determined and later shared with IT.
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.
To be documented
Our goals in communicating offboardings are transparency, and to provide an opportunity for team members to say goodbye. We understand that different individuals are comfortable with different levels of communication and that each offboarding situation has different situations and nuances. For this reason and out of respect for individuals, we have a couple of key guiding principles for communicating offboarding:
We ask that all offboardings are announced in the #team-member-updates Slack channel for transparency and awareness. While we encourage all offboardings to be posted in #team-member-updates, we recognize there may be select situations that we should consider a different approach for. If a team member or their manager does not want to post in #team-member-updates, please discuss with your People Business Partner or Team Member Relations.
Team members and managers have the discretion to determine who shares the news of the team member's offboarding (I.E. team member or manager). Regardless of who shares, it is required that team members review offboarding messaging with their managers prior to sharing.
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 is not always able to provide full context on 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 messaging to share 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 departure message should be shared in the #team-member-updates Slack channel.
Managers and team members can optionally leverage 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.)
There will be situations in which team members prefer to share their offboarding message, and situations in which managers prefer to do so. Either is ok, so long as team member and manager have reviewed the messaging together prior to posting.
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.
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 a state level and in compliance with Federal Law. Each state establishes its own eligibility criteria and regulations surrounding Unemployment Insurance with respect to the amount allocated, duration and eligibility for Unemployment Insurance.
Eligibility criteria include meeting the state specified requirements in terms of both earnings and time worked during the base period. In some instances the state may require additional supporting information particularly more extensive wage related details surrounding a claim.
Unemployment Insurance is funded through employer contributions and most states will have State Unemployment Taxes that apply however many employers typically pay the State Unemployment Taxes too.
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 people-connect@gitlab.com.
Additionally here is a link to the U.S Department of Labor Contact Particulars to report Unemployment Insurance Fraud.