Developing talent internally is a key component of our success at GitLab, and our promotion process is built to support that development in alignment with our values. Team members have two main avenues to pursue career advancement at GitLab: 1) Via our promotion process, and 2) By applying and interviewing for open positions that are approved in our headcount plan (transfers).
Promotions are reviewed and approved once per quarter to support a consistent, predictable, and fair process. We leverage public (to GitLab) promotion documents where we outline the business results, increasing job scope, and values alignment that a team member demonstrates which support their promotion. The People Business Partner and leadership team are responsible for calibrating promotion nominations aligned with the timeline below.
We encourage team members to take control of their own career advancement, and believe every team member deserves a great manager to support them. If you feel your title is not aligned with your skill level, come prepared with an explanation of how you believe you meet the proposed level and can satisfy the business need. Team members are empowered to own their development and can use the Individual Growth Plan as a tool to articulate and align on the skills they want to develop as they think about growing into a larger role.
In addition to promotions, this page captures information about transfers, realignments and career mobility.
Our promotion philosophy comprises core pillars surrounding the approach and process alignment to our values.
Our promotion philosophy is also aligned with our values:
Most promotions are processed through our Quarterly Promotion Calibrations, with exceptions going through Greenhouse or Workday depending on whether or not the individual interviews and accepts a position filling an approved headcount. More info on these 3 methods for processing a promotion below.
At GitLab, we promote on a quarterly cadence. This means that there is one effective date per quarter when team members can be promoted. There are three core stages to the promotion process: Planning, Calibration, and Processing.
| Stage | Purpose |
|---|---|
| Planning | Managers and leaders to review their respective teams to determine promotion readiness, business need, and timeline for the upcoming quarters and project promotions |
| Calibration | The calibration exercise is an opportunity for leaders (sync or async) to review projected promotions on a quarterly basis. This is an opportunity to create visibility and ensure consistency in who we are promoting and why. |
| Processing | The final stage once promotions are defined, is to determine where to process the promotion to finalize (this will take place via Workday or Greenhouse). |
Managers do not need to submit promotions that are part of the quarterly calibration process via Workday or Greenhouse. These will be processed by the PBP, Total Rewards, and People Connect team following calibration and Division leader approval. The exception to this rule are promotions that are submitted as exceptions and not part of the quarterly cycle and timeline outlined below.
Below is the timeline for FY23:
Please note that the Calibration timeline for Senior Director+ promotions will differ slightly from the timelines indicated above, as Senior Director+ promotions are calibrated at the quarterly E-group offiste.
Quarterly Promotion Planning is generally done via spreadsheets to maintain confidentiality and enable collaboration across department leaders where appropriate. Prior to the Planning phase in the timeline above, People Business Partners will make sure the spreadsheets are up to date before going into the Calibration phase.
The promotion document is required for all promotions.
As the audience are other GitLab team members, the text should be written in third person using the team member's name and appropriate pronouns (he/she/they) to highlight the work and skills as evidence of the team member's suitability for the role.
Promotion documents should demonstrate values alignment, business need for the role, and team member readiness through delivery of impactful business results. The core sections in our promotion document are:
When creating promotion documents, remember:
Each quarter, Department/Division Leadership and the aligned People Business Partner plan a calibration session to review projected promotions. The goal of these calibration sessions is to set a fair and consistent standard in the Department for promotions, peer review promotions, and provide an opportunity for leaders to ask questions. These sessions can be async or sync.
During calibration sessions, leaders should be prepared to discuss:
Calibration should be aligned to the following levels of leaders and people managers:
| Promotion Level | Level Calibrated |
|---|---|
| Under Director level (Job Grade 5-9.5) | Calibrated at the Department level |
| Director level (Job Grade 10) | Calibrated at the Division level |
| Senior Director+ level (Job Grade 11-15) | Calibrated at the E-Group level |
Note that calibration structure may vary by division and department depending on size/scope/etc.
Philosophically, all promotions at GitLab are approached in the same way, follow the same high level process (Planning, Calibration, Processing), and use the same promotion document template.
Promotions to Senior Director+ level (job grade 11 and above) have the following differences:
The only exception to this process is when there is an open budgeted and publicly advertised vacancy for a Director or above level role that an internal team member interviews for and is offered. If external candidates have been considered and interviewed, and the internal candidate earns the role through a standard hiring process (screening, full interview process) then the recruiter may make an offer to the candidate as soon as the offer is approved. There should be no difference in the timing or process of making and accepting an offer for open roles between internal and external candidates.
GitLab tracks the following promotion metrics in Sisense
GitLab tracks Internal Mobility rate. Market data indicates that a 12% rolling promotion rate as the guideline for what we should see on average across the company for promotions. This is a guideline, not a cap.
GitLab targets an average of 5-10% compensation change in general for promotions. This metric is in place to ensure we are consistent and equitable across the company when allocating promotion compensation raises to team members, in addition to ensuring competitive and meaningful promotion increases across the board.
FP&A tracks budget impact by Department/Division on a quarterly basis
Promotion budget is held at the division leader level, and optionally scaled down to department heads on a quarterly basis depending on department size. Decision to scale budget down is at the division leader's discretion.
Please review the Compensation Program Budget to understand how quarterly promotion budget is allocated and the process to review potential tradeoffs if divisions/departments are over/under budget for any given quarter.
Certain types of promotions/transfers can be handled outside of the Quarterly Promotion Calibration process:
For exceptional situations where a promotion is not handled through the quarterly promotion process or Greenhouse, managers can submit promotions and job changes through Workday. Managers should align with their People Business Partner and leadership before submitting the exception in Workday.
Please see the Workday Guides for more information on how to submit the request. Managers should include justification for the exception and for any compensation increase recommendations above 10%.
| Promotion Level | Approvals Required |
|---|---|
| Under Director level (Job Grade 5-9.5) | 1) Direct Manager, 2) Department Head, 3) People Business Partner, 4) Total Rewards, 5) FP&A |
| Director+ level (Job Grade 10-15) | 1) Direct Manager, 2) Department Head, 3) People Business Partner, 4) Total Rewards, 5) FP&A, 6) E-Group Leader |
Approvals for the Director+ level off-cycle promotion exceptions require E-Group approval, and off-cycle promotions for levels under Director require approval through Department head.
Regardless of the promotion level, it is critical that leaders work with their People Business Partner, Total Rewards, and FP&A as outlined to identify tradeoffs we can review to fund the promotion.
The following types of promotions/transfers can be processed through Greenhouse:
For any transfer being submitted through Greenhouse hiring process, the following is required:
In order to ensure a consistent level of review for both internal promotions and new leadership roles, any net new VP and above "To be Hired" roles will be reviewed and approved by e-group. Senior leaders should partner with their People Business Partner to create a justficiation document for their proposed role. The justification document allows for e-group to better understand the business need for the role and how it will align within the organization.
This review is part of our organizational design discussions that occur during the e-group offsite.
Proposed roles can be reviewed as soon as the organization has visibility to the business need. However, if the need for a new VP+ role comes up outside of those organizational design discussions, it can be reviewed during the weekly e-group meeting to continue to ensure that we are agile and competitive in our hiring practices.
The justification document needs to be used when:
When the promotion cycle is running concurrently with our Annual Compensation review (FY23-Q4) we will use Workday for processing promotions to eliminate the need for two tools. These steps will be updated as part of our Annual Compensation Review planning.
Things to consider before you start the process:
#new-vacancies slack channel so that everyone has the opportunity to apply and be considered.At GitLab, we ensure that promotions are impactful from the compensation perspective, stay within range of the compensation calculator, and are equitable to peers in the same role. Managers propose a recommended increase in cash compensation for their direct report using the compensation calculator. If you have any questions feel free to reach out to your People Business Partner or the Total Rewards Team.
When reviewing compensation for a transfer in Greenhouse, the Total Rewards team will ensure internal equity among like roles ahead of approving the offer details using the following general guidelines:
This section describes the approval chain after a manager submits a promotion or compensation change request in Workday.
TO UPDATE
1-1 meeting by sharing the letter of adjustment on the call. The Manager and the team member will process/sign the letter on the same call or any other scheduled call (in case of further disccussion about the promotion). Post acceptance by the team member, the Manager will announce the promotion on Slack #team-member-updates channel. In the announcment the manager will describe how the individual met the promotion criteria and include a link to the merge request where the individual's title is updated on the team page.TO UPDATE
Promotion Request: [Team Member Name].@mention the skipped department leader for approval in the Division-specific promotion Slack channel. Example: Promotion for Backend Engineer to Senior Backend Engineer. The Workday process includes the direct manager, department Director and CTO. The missing department leader here is the VP of Development. In this case @mention the VP of Development for approval.TO UPDATE
People Connect Team will be notified via the People Connect team email inbox that the Letter of Adjustment has been created by the CES team and signed. If this is the case, only data systems will need to be updated.TO UPDATE
Total Rewards Analyst to audit#team-member-updates Slack channel.people-exp@gitlab.com alias). Once the tracker is filled in, sort it by effective date.Note Letter of adjustment is sent to team member's GitLab email address.
As part of the career development structure within the Engineering division, interim and acting role opportunities occasionally arise. For more information on how interim and acting roles fit into Engineering career development, please reference the Engineering career development handbook page. For information on the interim and acting processes, please continue reading below.
As highlighted in the Defition section, all interim roles (regardless of the number of applicants) should go through the Greenhouse application and interview process. The interview process steps will be determined by the hiring manager and next level leader. This will contain several steps of the standard GitLab hiring process. The process for team members interested in applying for an interim role is as follows:
Once a team member successfully completes the interview process and is selected for the interim period, the following steps should be taken to ensure the team member is set up for success in their interim role.
Senior Manager, Engineering (Interim). This update serves as the SSOT for tracking interim start and end dates, in addition to providing transparency pertaining to who is currently executing in an interim role. Job code and job grade will remain the same, as interim periods have no impact on compensation i.e. do not update any other fields when initiating the Change Job Process.When the interim period comes to a close, one of two outcomes can occur:
The team member successfully completes the interim period aligned with the success criteria and moves into the interim role permanently.
The team member does not complete the interim period successful or decides that the manager track is not something they want to pursue, and moves back to their role prior to the interim period.
Irrespective of the outcome, when the interim period ends, the manager should review the Criteria For Eligibility for the Interim Bonus and submit an interim bonus request for the team member. Please ensure that the full bonus calculation is laid out in a comment of the bonus submission.
A person "acting" in the role is someone who occupies a role temporarily and will move back to their original role after a set amount of time or other conditions. "Acting" in a role may be experimenting with the role as a part of determining an individual's career development path, or may be filling in for a vacant role while we hire someone to fill the role permanently. While interim is only applicable to the Engineering division, acting is used across GitLab.
Interviews are not required role Acting roles as they generally do not end in promotion, nor are direct reports in Workday generally moved to Acting managers. The process for selecting someone for an acting position is:
When the acting period ends, the manager should review the Criteria For Eligibility for the Interim Bonus and submit an interim bonus request for the team member.
If you receive a job change or letter of adjustment to an interim or acting role here is how to process the change.
Share with employeeTo demote one of your direct reports, a manager should follow the following steps:
Job information changes are anything that requires an update to the team member's profile in Workday that is not compensation related. The current manager is the person who needs to submit all job information change requests (including requests to change team member's manager). These changes need to get requested through Workday to have an approval trail for compliance reasons.
TO UPDATE
Process for the current manager:
This job aid will help provide people managers with instructions on how to move team members to another manager within Workday. If the manager you need to move your direct report to is not available, it likely means they do not have a supervisory organization set up. Even if their management level shows “Manager” a supervisory organization is needed in Workday for a team member to have a direct report. Supervisory organizations should have a name unique to the team they are managing (e.g. Commercial Sales - EMEA, Content Marketing (John Smith), Backend Engineering - Ruby). Please reach out to #people-connect with the name of the team member who needs the supervisory organization set up, the unique name, and the effective date of the supervisory organization. We can gladly help get it set up in Workday.
Process for EBA to update senior leadership:
people-connect@gitlab.com requesting the changes to be made in WorkdayJob Title Specialty change requests, managers will reach out to the People Connect Team to have a team members Speciality updated in Workday.
Job Speciality has been added to the respective departments Handbook page (example: https://about.gitlab.com/handbook/engineering/development/enablement/sharding/) or if the People Connect Team members are tagged in a respective issue to have it added. If unclear, reach out to the respective People Business PartnerJob Speciality change and a manager change, the People Connect Team will be notified in the internal Transition Tracker spreadsheet tracker (using the people-exp@gitlab.com alias) and the People Connect Team members will create an associated Career Mobility Issue with the Slack Command list and track associated tasks for the previous and new manager. Tag or mention the aligned People Business Partner in the Career Mobility Issue.If you are interested in a vacancy, regardless of level, outside your department or general career progression, you can apply for a transfer through Greenhouse or the internal job board, link found on the #new-vacancies Slack channel.
Please undertand the following eligibility guidelines that need to be met to be able to proceed with an opportunity here at GitLab:
Please note that internal applicants are required to speak with their current manager or People Business Partner prior to application submission. An official application is signaled by a team member applying to the open role or reaching out to the talent acquisition team. Informal conversations about the role do not require a team member to inform their manager. If you have concerns about communicating your interest in an internal role to your manager, please reach out to your People Business Partner.
For more information please visit our Internal Hiring Process handbook page.
#team-member-updates Slack Channel and begin any additional onboarding or offboarding necessary. Before the new manager makes the transfer announcement they must confirm with the team members current manager that the current team has been informed about the team members new position and transfer.If the team member is staying in the current benchmark for the Job Family, but changing their Specialty or Department (ex: moving from Plan to Secure or moving from Development to Infrastructure), the above steps will be followed. Solely the recruitment procedure might be shortened if the requirements for the role are the same. At a minimum we would ask for the hiring manager to have an interview with the team member.
If selected for the role, a Letter of Adjustment will be sent by the Total Rewards team outlining the changes to department and specialty for the Total Rewards team to process in Workday. If the current manager needs to backfill the role they should reach out to the Finance Partner.
If you are interested in another position within your department and the manager is also your manager you must do the following;
#team-member-update Slack channel and begin any additional onboarding or offboarding necessary.If a GitLab team-member is chosen for a new role, the managers should agree on a reasonable and speedy transfer plan. Up to 4 weeks is usually a reasonable period, but good judgment should be used on completing the transfer in a way that is the best interest of the company, impacted people, and projects.
The agreed upon transfer date should be reflected in the offer letter in Greenhouse to ensure transfer date alignment between current manager, new manager, and transferring team member. This is essential to ensure that both teams are able to plan and be set up for success. It is important to note that it is typically the former team of the team member that shuffles to ensure workload of the departing team member is covered while a backfill is hired for. This is to ensure a smooth and speedy transfer and a positive team member experience. When aligning on a start date, please also considering payroll alignment when selecting a start date.
Delaying transfers should be avoided to ensure a good team member experience for the transferring individual, however, if due to extenuating circumstances a transfer date needs to be pushed out, both managers need to agree on a new transfer date to communicate to the team member.
If you are a manager wishing to recruit someone, the process is the same as a team member-initiated transfer.
If a team member sees a vacancy posted that is the next level up within their job family (for example an Intermediate Frontend Engineer sees a vacancy for an Senior Frontend Engineer), the team member should have a conversation with their manager about exploring that opportunity. Once that discussion is completed the team member should follow the internal department transfers guidance above.
It is the manager’s responsibility to be honest with the team member about their performance as it relates their promotion readiness. If the manager agrees that the team member is ready, then they will be promoted to the next level. If they do not think the team member is ready for the promotion, they should walk through their career development document, as well as work on a promotion plan with the team member. The manager should be clear that the team member is not ready for the promotion at this time and what they need to work on. If the team member would still like to submit an application for the role after the conversation with their manager, they can apply and go through the same interview process as external candidates. The recruiter will confirm with the manager that the promotion readiness conversation has taken place before the internal interview process starts.
If the role is in a completely different job family (within their own division or in a completely different division, for example, if a Product Designer is interested in a Product Manager role), the team member must submit an application via the posting on GitLab’s internal job board on Greenhouse.
After the team member applies, the recruiter will reach out to the team member to connect regarding compensation for the role. In some cases, the compensation may be lower than the current one. Once the team member understands and agrees with the compensation for the new role, they can continue the interview process.
Internal and external candidates will have the same process with the same amount of interviews and when possible the same interviewers, with the exception of the full screening call (which will be instead a short conversation to discuss compensation, as mentioned above). However, if the internal applicant will be staying in the same division and the executive level interview is a part of the process, the executive may choose to skip their interview. All interview feedback and notes will be captured in the internal team member’s Greenhouse profile, which will be automatically hidden from the team member. After interviews are completed, internal “reference checks” will be completed with the applicant’s current manager by the new hiring manager.
It is recommended that team members inform their manager of their desire to move internally and their career aspirations. Your manager should not hear about your new opportunity from the new hiring manager; it should come from you prior to the new hiring manager checking in for references with the current manager.
If you are unsure of the role, set up a coffee chat with the hiring manager to introduce yourself. Express your interest in the role and your desire to learn more about the vacancy requirements and skills needed. If after that conversation you do not feel that you are qualified or comfortable making the move, ask the hiring manager to provide guidance on what you can do to develop yourself so you will be ready for the next opportunity. It may also be possible to set up an internship for learning situation with the hiring manager.
While the Career Mobility Issue Issue aims to kick off the logistics of switching roles, the guidelines below are meant to guide the communication of internal promotions and transitions to ensure consistency and alignment from all parties involved.
new manager should post the announcement in the #team-member-updates Slack channel. This should ideally happen (timezome permitting) on the same day that the candidate signs their Letter of Adjustment.current manager can proceed with making this announcement in other relevant team-specific channels.NOTE: Though the Total Rewards and People Connect Team may have visibility into promotions or transfers due to the administration of updating information as part of their roles, they should not communicate with the team member about their promotion/tranfer until an announcement has been made.–
Company priorities can change and occasionally some or all members of a team may be asked to transfer to high priority vacancies within other teams.
Early and ongoing communication with affected teams is key to ensuring a successful realignment. Hiring managers should clearly articulate the business need and quantifiable benefits from the realignment, as well as position a team focus and roadmap that gives affected teams an understanding of how their future contributions will benefit GitLab.
Consideration should be given to impacts on product category maturity commitments for teams with departing team members.
Relevant items that can assist include:
When possible, realignments should respect the Product Development Timeline to allow impacted teams to complete existing work.
In cases where multiple individuals are asked to transfer to high priority roles:
Vacancies will be posted internally using the Greenhouse internal job board for at least 3 business days. If a role is not posted internally there must be a business case documented in the HRIS file of the team member who received the new role. See Department Transfers for additional details.
More details can be found on the Internal Applications page and the Letter of Adjustment section.
There are a number of different ways to enhance or add to your skill-set at GitLab, for example, if you do not feel like you meet the requirements for an inter-department transfer, discuss with your manager about allocating time to achieve this. This can be at any level. If you're learning to program, but aren't sure how to make the leap to becoming a developer, you could contribute to an open-source project like GitLab in your own time.
As detailed in our Learning & Development Handbook, team members will be supported in developing their skills and increasing their knowledge even if promotion is not their end goal.
A Career Mobility Issue is created when the one of the following criteria is met;
When a career mobility may not be needed (but can be requested);
The People Connect Team will notify the People Connect Team of a pending migration of a team member via @ mention in the Promotion/Transfer Tracker. The People Connect Team member currently in the assignment rotation will assign the migration for support.
The Career Mobility Issue will then be created by the People Connect Team member assigned by using the automated Slack command three days prior to the effective date to allow for the managers to start preparing for the team members transition.
Important things to ensure:
The team member going through this transition and assigned to their Career Mobility issue have a set of tasks to complete. An important one is to create a retrospective thread within their Career Mobility issue, so that they and their respective previous and current managers can discuss any questions, comments, proposals and more about their issue within said issue. Retrospectives are used in many ways at GitLab, such as which are used after GitLab product releases and describing the Product retrospective workflow. For the Career Mobility issue, simply comment in the issue, starting a thread titled Retro thread or Retrospective. Please feel free to ping your assigned People Connect Team member in your issue if you have any questions.
The People Connect Team member completes a bi-weekly audit of all career mobility issues that are still open and checks that all tasks have been completed by all members applicable. In the event that tasks are still outstanding, the People Connect Team member will ping the relevant team members within the transition issue to call for tasks to be completed.
Once all tasks have been completed and the issue is still open, the People Connect Team member will close the transition issue accordingly. The transitioning team member can also close the issue once satisfied all the tasks are complete.
All migration tasks by the applicable team members needs to be completed within 2 weeks of the migration start date.
There are several situations at GitLab that could lead to team members changing managers, including promotions, lateral transfers, company restructuring, manager resignation, etc. The process of building a new relationship with a new manager can be uncertain at times, but there are resources to help this transition process go smoothly: