Promotions and Transfers

Information and protocols related to GitLab promotions and transfers.

Developing talent internally is a key component of our success at GitLab, and our promotion and transfer 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 cyclical promotion calibration process, and 2) by applying and interviewing for open positions.

We encourage team members to take control of their own career advancement, and are empowered to own their development. Team members are encouraged to utilize the Individual Growth Plan as a tool to articulate and align with their manager on the skills they want to develop as they think about growing into a different or larger role. This page captures information about transfers, promotions, realignments and career mobility.

Definitions

Internal Mobility

Internal mobility is the process by which team members move into open positions at GitLab. When a position is open and posted on the career site via Greenhouse, and then filled by a current GitLab team member, it is classified as ‘internal mobility’. Similar to filling a role with an external candidate, internal team member candidates will also follow the same Greenhouse hiring steps and experience a full interview process to enable an informed hiring decision. All open positions should be posted to allow for equal opportunity for consideration.

The type of action resulting from receiving an offer for an open role following the Greenhouse hiring process will depend on the changes in level and job scope:

  • If a team member applies for and accepts a position at the same grade, it will most likely be considered a lateral transfer. In most cases, a lateral transfer will not result in a compensation increase, unless there is a significant difference in the compensation structure between the new and prior job families. When a team member moves to a new role, a review of the job level, family, and scope will determine if this is indeed a lateral move.
  • If a team member applies for and accepts a position at a higher grade, it will most likely be considered a “promotion” and will result in a change in compensation and/or promotional stock grant. Some job families differ in their job grading and when a team member moves to a new job family, a review of the level and job scope will determine if this is indeed a promotion.
  • If a team member applies for and accepts a position at a lower grade, it will most likely be considered a “demotion” and may or may not result in a change in compensation. Some job families differ in their job grading and when a team member moves to a new job family, a review of the level and job scope will determine if this is indeed a demotion.

Upon applying for a new role, it’s recommended that team members understand the impact of the change based on their current job grade and family.

Note: If a team member wishes to move from an Individual Contributor to a Management position, the position must be posted and follow the normal hiring process steps to ensure all interested candidates have the chance to apply. This provides an equitable and transparent process for everyone.  

Internal mobility opportunities are dependent on employee eligibility and available open headcount.  

  • Timelines
    • Based on an open requisition and internal hiring process via Greenhouse.
    • All positions must be open for a minimum of 5 calendar days.
    • At least 2 interviews must be completed before moving to an offer for a candidate internal or external.  
    • If there is a change in compensation, the start date should fall on the start of a pay period aligned with the team member’s country. If the team is in a commissions role, the start date should always align with the first of the month.

Job Detail Changes Due to Business Requirements or Reorganizations

At times, the business may need to change job attributes such as the direct manager or department. These changes may be a result of consolidating teams, creating new departments, or moving team members to report to a new manager. These types of changes are specified as job attribute changes and don’t meet the definition of internal mobility, and can be initiated by the current manager via Workday.  

Engineering Internal Mobility

For Engineering, please see Engineering Mobility Principles for additional guidelines and justification.

Promotions

In-Cycle Promotions:  An in-cycle promotion is any individual that is within the same job family, and has a similar but increased job scope. A promotion is not necessarily defined with a new grade due to differences in job families. This process does not require interview(s), does not create backfill headcount and occurs semi-annually through the calibrated promotion process. All in-cycle promotions are processed in Workday and not in Greenhouse.  

Internal Mobility Promotions:  Internal Mobility promotions occur when a team member applies for an open position and accepts a role at a higher grade/job responsibilities when compared to their current role.  

  • In order for promotions through internal mobility to occur, approval from the skip-level leader is required.
  • Additionally, the aligned People Business Partner should be consulted for alignment and visibility.

Promotion Philosophy

Our promotion philosophy comprises core pillars surrounding the approach and process alignment to our values.

Pillars

  • Promotions are based on performance, not on growth potential. If being considered for an in-line promotion, Team members should already be executing at the next level job frameworks level prior to promotion.
  • Career growth should be a partnership between team member and manager. As a manager, it is important to create space to regularly discuss your team members’ development and career aspirations, and identify opportunities to support them in their advancement and growth.
  • When reviewing a proposed promotion, we consider: 1) readiness of the individual, and 2) business justification/opportunity.
  • All in-line promotions at GitLab require a promotion document. We believe in transparency within the promotion process.
  • We encourage team members to live our efficiency value, be a manager of one, and take ownership of their promotion document in partnership with their manager.
  • We calibrate planned promotions on a twice per year basis to ensure an equitable review, and through this process track metrics that help us understand if our promotions are occurring at a healthy and fair rate.

Values Alignment

Our promotion philosophy is also aligned with our values:

  • Collaboration: Cross-functional lens for feedback and calibration
  • Results: Business justification, scope, and team member results are demonstrated and documented to support promotions
  • Efficiency: Consistency and scalability in our promotion processes by twice per year planning and calibration. The planning and calibration timing considers existing programs and cycles for the business and aims to embed promotions into cadences where they best align for efficiency.
  • Diversity, Inclusion, and Belonging: Fairness and equity reflected through a consistent approach and documentation to promotions at all levels in the organization and supported by our job frameworks and Total Rewards URG audit
  • Iteration: Process is improved each cycle. In FY23, we moved to quarterly promotions with calibration and updated our processes and metrics accordingly. In FY24, we moved to a twice per year promotion cadence to ensure efficiency and scalability in our process as the business continues to grow.
  • Transparency: Clarity and efficacy of promotion metrics, budget, and guidelines, in addition to transparency in promotion justification through internally public promotion documents.

Processing a Promotion

Most promotions are processed through our twice per year 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.

Twice per Year Promotion Calibration Process & Timeline

At GitLab, we promote on a twice per year basis. This means that there is one effective date every 6 months when team members can be promoted. We process promotions in Q1 (effective date February 1st) and Q3 (effective date August 1st). 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 twice per year 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 twice per year 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. Below is the timeline for FY24:

Previously, we promoted on a quarterly basis, but transitioned to twice per year to ensure efficiency and scalability of our promotion process. We will move to our twice per year cadence effective in Q1 FY'25, meaning that Q3 FY'24 will be our last quarterly promotion cycle.

Please note that the Calibration timeline for Senior Director+ promotions will differ slightly from the timelines indicated above, as Senior Director+ promotions are calibrated twice per year at the E-group offsite.

FY24-Q1

Status: Completed. Aligned with Annual Compensation Cycle

  • Planning: 2022-12-20 to 2023-01-06
  • Calibrations: 2023-01-09 to 2023-01-20
  • Processing: 2023-01-23 to 2023-02-01 (Promotions must be added to Workday by 2023-01-20)
    • Effective date for promotions: 2023-02-01.
    • Communication: In conjunction with annual compensation review raises. After communicating 1:1 with individuals, updates can be posted publicly in #team-member-updates.

FY24-Q2

Status: Completed.

  • Planning: 2023-03-15 to 2023-04-01
  • Calibrations: 2023-04-01 to 2023-04-15
  • Processing: 2023-04-15 to 2023-05-01 (promotions must be added to Workday by 2023-04-20)
    • Effective date for promotions: 2023-05-01.
    • Communication: After fully approved in either Greenhouse or Workday
    • After communicating 1:1 with individuals on or after 2023-04-24, updates can be posted publicly in #team-member-updates. Managers should not communicate until Total Rewards communicates that the promotions are approved.

FY24-Q3

Status: Completed.

  • Planning: 2023-06-12 to 2023-06-23
  • Calibrations: 2023-06-26 to 2023-07-14
  • Processing: 2023-07-17 to 2023-08-01 (promotions must be added to HRIS by 2023-07-20)
    • Effective date for promotions: 2023-08-01.
    • Communication: After fully approved in either Greenhouse or Workday
    • After communicating 1:1 with individuals on or after 2023-07-24, updates can be posted publicly in #team-member-updates. Managers should not communicate until Total Rewards communicates that the promotions are approved.

FY25-Q1

Status: Upcoming. Aligned with Annual Compensation Cycle

  • Planning: 2023-12-01 to 2023-12-15
  • Calibrations: 2023-12-18 to 2024-01-08
  • Workday Entry (manager responsibility): 2024-01-09 to 2024-01-17
  • Processing (Total Rewards): 2024-02-19 to 2024-03-01
    • Effective date for promotions: 2024-02-01.
    • Communication: In conjunction with annual compensation review raises. After communicating 1:1 with individuals, updates can be posted publicly in #team-member-updates.
      • There will be a window from 2024-02-21 to 2024-02-29 for manager to proactively communicate promotion approval and new job titles.

Planning

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.

Promotion Document

The promotion document is required for all in-line 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.

In-line 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:

  1. Promotion Summary
  2. Values Alignment
  3. Business Results
  4. Business Justification

When creating promotion documents, remember:

  • Promotions are based on performance, not growth potential.
  • GitLab considers both individual readiness and business need when we think about promotions. Managers are responsible for completing the business justification section of the promotion document to include what justifies the need for the team members skills and work to be completed at the higher level. Possible business justifications typically include for example: more complex projects, additional scope of work required as the team scales, additional responsibility due to XYZ business reason.
  • Promotion documents should not exceed 3 pages total.
  • Please reference the job frameworks in the handbook for guidance pertaining to expectations at the various levels at GitLab. The job levels should help guide data chosen to be included in the promotion document, in addition to discussion during calibration sessions.
  • Please review our guidance on DIB behaviours aligned to each job level which provides examples of how to demonstrate our Diversity Inclusion & Belonging Value
  • Please be sure that the promotion document has “comment” access enabled to ‘Anyone at GitLab who has the link!’ to ensure the review and approval process is not delayed. Please delete the instructions associated with each section of the promotion document below before submitting the promotions.
  • If you find yourself struggling to articulate your accomplishments, your manager can help support you and provide feedback. You can also consider reaching out to stakeholders for feedback, or meeting with a trusted colleague or mentor to brainstorm.
  • It should not include Talent Assessment ratings, such as “Exceeding Performance”, as these must remain confidential and only discussed in confidential settings such as Promotion Calibration, talent assessment calibrations, and within reporting structures.

Calibration

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, to allow peer reviews, and provide an opportunity to ask questions. These sessions can be async or sync.

During calibration sessions, leaders should be prepared to discuss:

  1. Core themes of the promotion document: Values alignment, business justification, business results.
  2. Development areas: The promotion document outlines strengths, but we also want to highlight how we will support a team member’s opportunity to develop at the next level.
  3. Cross-functional feedback: As our business goals and initiatives become increasingly cross-functional, managers should have a picture of how their team member collaborates effectively within their immediate teams, and with their core cross-functional partners and stakeholders.
  4. Performance against with the current and (some) next level expectations aligned with the job framework.
  5. Competencies: Where available and applicable.
  6. Most recent talent assessment (and any relevant changes since).

Calibration should be aligned to the following levels of leaders and people managers:

Promotion Level Level Calibrated
Under Director level (Job Grade 5-9) 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.

Promotions to Senior Director+

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:

  1. Planning: Senior Director+ promotions need to be added to E-group’s promotion project sheet at least two quarters ahead of the desired promotion quarter for visibility. For example, if I want to promote an individual effective in Q1 (February), then I need to have this team member added to E-group’s projection sheet within Q3 (latest October). Please work with your aligned People Business Partner, who will ensure the promotion projection is added.
  2. Calibration: All Senior Director+ level promotions are calibrated at the E-group level, as opposed to at the Department level. Calibration timeline will align to the timing of the E-group offsite, and will thus differ from the Calibration timeline of the rest of the organization. All promotion documents need to be completed and shared with the E-group for visibility and preparation at least 2 weeks before the off-site date.

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.

Promotion Metrics

GitLab tracks the following promotion metrics in Tableau

Internal Mobility

GitLab tracks Internal Mobility rate. Market data indicates a 15% 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.

Average % Compensation Change

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.

Budget Impact (see below)

FP&A tracks budget impact by Department/Division twice per year.

Promotion Budget

Promotion budget is held at the division leader level, and optionally scaled down to department heads twice per year depending on department size. Decision to scale the budget down is at the division leader’s discretion.

Please review the Compensation Program Budget to understand how the promotion budget is allocated and the process to review potential tradeoffs if divisions/departments are over/under budget for any given quarter.

Promotions Processed Outside of the Twice Per Year Promotion Calibration Process

Certain types of promotions can be handled outside of the Twice Per Year Promotion Calibration process:

  1. Application to a new, approved headcount in Greenhouse:
    • Internal candidates go through an interview process as defined further in the Greenhouse Promotions/Transfers section.
  2. Promotions stemming from individuals in interim/acting roles.
  3. Exceptions that are outside of the twice per year process and not aligned with any of the types listed above.

How to Process an Exception: Submitting an out-of-cycle Promotion request in Workday

For exceptional situations where a promotion is not handled through the twice per year promotion calibration process or via an open requisition in Greenhouse, managers can work with their People Business Partner to submit promotions through Workday. Managers should reach out to their PBP via email and include a promotion document, justification for the exception, and next level manager approval for any compensation increase recommendations above 10%. Once the People Business Partner approves an exception, the promotion can be processed and the People Business Partner can submit the promotion in Workday. See the Workday Guide for help with submitting the changes.

Exception Approvals

Promotion Level Approvals Required
Under Director level (Job Grade 5-9) 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.

Engineering Promotion Feedback Pilot

In the Engineering Division, we are incorporating peer feedback into the promotion process for Engineers who are pursuing a promotion to an individual contributor role at a Staff level or higher as outlined in our individual contributor job framework.

We will incorporate feedback from 2-3 individuals who work directly, closely, and regularly with the team member. Feedback can be from team members within Engineering, or from stakeholders that work closely with the team member including stable counterparts in other divisions (I.E. Product). Ideally, we would have a mix of both Engineering and cross-functional feedback for completeness and balance.

  • Within the Engineering division, feedback should be provided by team members who are currently at or above the Job Grade we are proposing to promote the team member into (for example, if the team member is currently a Senior Backend Engineer (Job Grade 7), and we are proposing to promote them to Staff Backend Engineer (Job Grade 8), feedback should be solicited from team members at Job Grade 8 or higher).
  • Outside of the Engineering division, feedback should ideally be provided by team members at or above the level we are proposing to promote the team member - however, there may be exceptions to this rule due to stable counterpart alignment (I.E. If the team member is currently a Staff Backend Engineer, and we are proposing to promote them to Principal Engineer and their Product stable counterpart is a Senior Product Manager, it is acceptable to solicit feedback from them despite the fact that this is not at/above the promotion level)

To ensure this feedback is provided in a structured and safe way, and to support the objectivity of the feedback collection process, an Indirect Manager (a people manager who is not the direct manager of the team member) will be responsible for collecting the feedback and compiling the themes to supplement the promotion document materials presented at the promotion committee meeting. Only people managers should be collecting feedback as part of the process, individual contributors should not drive this portion of the promotion process. Once feedback is collected, the Indirect Manager should share with the Engineering People Business Partners via the pbp-r-and-d@gitlab.com email alias to ensure appropriate access is in place ahead of CTO level calibration.

Promotion Feedback Template

Until Workday is enabled to collect feedback, managers will use the linked template to collect feedback. The template is structured in a Start/Stop/Continue format with question prompts that can help guide relevant inputs. The team member’s promotion document can also be shared with the 2-3 individuals selected to provide feedback.

We encourage feedback providers to provide specific examples and actionable recommendations to ensure the feedback is meaningful and constructive. Please provide your feedback based on your firsthand interactions and observations of the team members’ performance. Your input should be specific, constructive, and focused on their work. Consider their skills, abilities, behaviors, and areas for improvement.

Promotion Feedback Confidentiality

The promotion candidate will be aware that their promotion has moved to the feedback phase, however, we ask team members providing promotion feedback to keep it confidential throughout the feedback process. Regardless of whether or not the promotion is approved, team members will receive a summary of the feedback provided to them when the promotion cycle is complete to support their ongoing growth and development.

Aligned with our company-wide promotion timeline, we do not communicate promotion status (approved/denied) to team members until we are fully through the approval process, so it is important to ensure team members are clear on the fact that participating in the feedback promotion phase does not indicate promotion approval.

Promotion feedback documents differ from promotion documents in terms of who they are shared with. While promotion documents are shared company-wide upon promotion approval, promotion feedback documents will not be shared publicly. The intention of promotion feedback is to ensure we are incorporating cross-functional feedback into the promotion process and providing team members with holistic feedback on their strengths and opportunity areas with the ultimate goal of supporting growth. Promotion feedback documents will only be shared with the People group, CTO Staff, the team member’s leadership chain, and the Indirect Manager facilitating the feedback process.

Promotion Feedback Steps & Timeline

We have built in a few additional touchpoints into the company-wide promotion calibration and processing timeline to ensure enough time in the process for feedback sessions to take place.

For clarity, Indirect Manager in the timeline below refers to the people manager that is driving the promotion feedback process.

  1. Week of 2023-11-20: Department level calibrations started utilizing the promotion document
  2. NEW Promotion Feedback Obtained: The promotion feeback portion of the cycle should kick off after department level calibration has concluded. Manager and Team Members collaboratively select 2-3 team members to participate in the feedback collection process. Once the team members to participate are selected, the Manager engages another Indirect Manager to collect the feedback objectively.
  3. The selected Indirect Manager reaches out to the 2-3 team members selected to request their participation in the promotion feedback process using Promotion Feedback template. A separate copy of the template should be shared with each individual providing feedback. Feedback can be provided asynchronously, or synchronously in a session set up by the Indirect Manager.
  4. Indirect Managers review this content and can schedule follow up interviews to gain additional clarity and dig into any themes that have arisen if necessary.
  5. Indirect Manager compiles a summary of written feedback along with any relevant interview notes that is presented at CTO calibration by their department leader in conjunction with the promotion document. Indirect Manager should share the feedback overview with the direct Manager. Due date for Indirect Managers to complete the feedback process and have the final summary compiled and shared with direct Manager is 2023-12-21 5pm PT. ``1
  6. As soon as the direct Managers confirm they have received and reviewed the feedback summary document provided by the Indirect Manager, the Indirect Manager should share the summary with the Engineering People Business Partners via the pbp-r-and-d@gitlab.com email alias to ensure appropriate access is in place ahead of promotion committee calibration. Feedback summary documents should be shared with the aliases above by 2023-12-22 @ EOD PT latest.
  7. Week of 2024-01-01 to 2024-01-04: Promotion Committee meetings are held. Promo committees are comprised of a cross-functional committee of team members & managers at or above the level of the promotion nominations being reviewed.
  8. 2024-01-08: CTO level final promotion review
  9. Upon final approval of promotions: The direct manager will provide a consolidated summary of the themes collected in the promotion feedback process to the team member directly. The goal of this conversation is to aid in the ongoing growth of the team member and should be presented in a way that provides the team member with actionable insights for development. Unless specifically agreed upon with the team member who provided feedback, feedback should be presented thematically vs directly attributable. The Indirect Manager who collected the feedback should plan to meet with the direct manager to share the findings. Managers should plan to discuss promotion feedback with all promotion candidates for whom feedback was solicited, not just those whose promotions were approved. If a promotion was not approved, the collective feedback from calibration and the promotion feedback process should inform a discussion about growth areas for the team member to focus on to be more ready for future promotion.

Hiring for VP+ Roles

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 justification 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:

  1. We decide to backfill an existing role at a higher level (VP+)
  2. We open a net new headcount for a VP+ role (that is was not accounted for in the current fiscal year headcount plan)

Process for Managers: Requesting a Promotion

  1. Determine whether the promotion change should be processed through the twice per year promotion cycle or through Greenhouse
  2. If proceeding with the twice per year promotion cycle, work with your People Business Partner and Leadership to recommend the promotion ahead of the planning process so the team member included in planning and calibrations. Ensure the Promotion or Compensation Change Document has been created at this time.
  3. If the promotion/compensation change should be processed through Greenhouse, please follow the steps outlined in the Greenhouse Promotions/Transfers Process section.
  4. If the promotion is considered an exception, please follow the steps outlined in the How to Process an Exception: Submitting an out-of-cycle Promotion request in Workday.

Things to consider before you start the process:

  • There will be situations when a team member is ready to move to the next level through a promotion, however, due to the nature of the business, that particular role or next level may not be available. For example, the team member is ready for a Manager or Director role, however, the business does not have the need, budget or scope for an additional manager/director at that time. The position may or may not become available in the future.
  • If the vacancy is being advertised via the jobs page the individual must submit an application for the role. Similarly, if there is no vacancy posting, one must be created and shared on the #new-vacancies Slack channel so that everyone has the opportunity to apply and be considered.

Recommending a Compensation Increase

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.

Promotion Compensation Guidelines

  • When a team member is promoted from one level to the next in the same job family, it is typical to be brought between the minimum and median of the compensation range.
  • The Total Rewards Team typically recommends a 5%-10% increase as part of the promotion to cash compensation. Additional equity is fixed based on equity for promotions.
  • Any promotions with the following conditions will require additional justification to the Total Rewards team and executive approver. Please add the business justification as a comment in the promotion worksheet.
    1. An increase of more than 10%
    2. The promotion exceeds the range in the compensation calculator.

Transfer Compensation Guidelines

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:

  1. Lateral Transfer (different or same job family, same grade): Typically we expect a team member to receive no increase for a lateral transfer. This includes team members receiving a change in territory, segment, or specialty with no change in grade or job level.
  2. Promotional Transfer (different or same job family, higher grade): Typically we expect team members to receive a 5-10% increase (aligned to the promotional expected increase).
  3. Other Transfer types: There are other transfers that can be reviewed on a case by case basis. For example, if someone is transferring to a lower grade in a different or same job family, compensation may be adjusted down to ensure alignment to market rates for the role. Please tag the Total Rewards team in Greenhouse to conduct a review.

Workday Out-of-Cycle Promotion Approval Process

This section describes the approval chain after the People Business Partner submits a promotion request in Workday.

  1. The changes will route for approval to the manager, next level manager,and e-Group leader.
  2. If the request is approved, the People Connect Team will stage the Job Change Letter in DocuSign.
  3. DocuSign will prompt the manager to discuss the promotion with the team member. The Manager will communicate the change to the team member in their 1-1 meeting by sharing the job change letter on the call. The Manager and the team member will process/sign the letter. Following the signatures, the manager will announce the promotion on the slack #team-member-updates channel. In the announcement the manager will describe how the individual met the promotion criteria and offer congratulations.
  4. For change of departments and managers, People Connect Team members will create a Career Mobility Issue.

For People Connect Team: Processing Promotions, Internal Transfers & Compensation Changes

  1. If the request is approved through Workday, the People Connect Team will create the Job Change Letter, whereas if the request is through Greenhouse the People Connect Team will be notified via the People Connect team email inbox that the Job Change Letter has been created by the CES team and signed.
  2. The People Connect Team member notifies Payroll of the changes by adding the relevant details to the applicable payroll sheet depending on the country under the ‘Compensation’ header and starting month tab
  3. If there is a sales commission change: Add the details to the Final Sales OTE sheet

Job Change Letter

  1. For all the GitLab entities and Independent Contractors create a job change letter as per the steps mentioned below. If the team member is employed by a PEO, notify the applicable PEO either by email or for remote.com via their dashboard. See the People Connect 1password vault for contact details.
  2. Review the Signature requirements per country and process the job change letter accordingly.
  3. Make a copy of the Job Change Letter template and enter all applicable information based on the Workday request and add the applicable Signatory or Company Signature Stamp. The effective date is as follows:
    • For sales personnel with a variable change, the effective date is always the 1st of the month regardless of their entity.
    • If the team member is making a lateral move where there is no change in compensation, then the start date can be any Monday.
    • For US team members, the effective date should be either the 1st or the 16th. If the payroll cut off date has passed for the current pay period, the effective date should be made for the start of the next pay period. The GitLab Inc and Federal Payroll calendar should be referenced when determining the effective date.
    • For example, if the change is being processed on June 22, since this date is before the payroll cut off date of June 23, the effective date should be June 16.
    • If the change instead is being processed on June 25, the effective date should be July 1 since this is after the payroll cut off date.
    • For Canada team members, the effective should be the start of the pay period closest to, but not after the payroll cut off date depending on when the change is processed. The GitLab Canada Corp Payroll calendar should be referenced when determining the effective date.
    • For example, if the change is being processed on June 15, since the payroll cut off date of June 6 has passed, this would go to the next pay period with a cut off date of June 20. The corresponding start of the pay period for the June 20 cut off date is June 21 so June 21 should be the effective date.
    • For all other changes, the effective date should be the first of the current month if processed on or before the 8th of the month and the first of the next month if processed after the 8th of the month.
    • For example, if a GitLab Ltd team member has a change being processed on June 7, this would be effective June 1.
    • If the change was instead being processed on June 15, this would be effective July 1.
  4. If only the company stamp is required the letter should get emailed to the team member’s manager to communicate the change
  5. If e-signatures are required stage the letter in DocuSign and add the following team members to sign via their GitLab email addresses:
    • Add radio button (Delete the additional one) for the Manager to communicate the change to the team member by sharing the job change letter during the 1:1 Zoom call and then again add one radio button to (Delete the additional one) announce on the #team-member-updates Slack channel.
    • Add signature field for the team member
    • Add sign date field for the team member
    • Note: Make sure that a) “Set signing order” option has been selected while preparing the doc, and b) Select radio button instead of checkboxes as only radio button allows you to select the required field/mandatory field option. This prohibits the Manager to process the letter without checking the tasks on the letters.
  6. Save the signed letter to the respective team members Documents Tab within their Workday Profile.
  7. If the here mentioned criteria for a Career Mobility Issue is met the People Connect Specialists will receive an alert from Workday and ensure that an issue is opened for the transitioning team member.

Interim and Acting Roles

Interim

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.

Beginning Interim Period

As highlighted in the Definition 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:

  1. Team Member: Apply for the interim position in Greenhouse.

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.

  1. CES: Issue a Job Change Letter to finalize the beginning of the interim period. The Letter should include: interim job title, start date, and end date (if known). Job Change letters are important as this is the process by which Total Rewards is notified of change from Greenhouse.
  2. People Connect: Update the team member’s job and business titles in Workday to reflect that they have started an interim role e.g. 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.
  3. Current Manager: In the instance that there are direct reports that need to be moved to an Interim Manager this change needs to be initiated by the Current Manager or where necessary the People Business Partner for the respective group in Workday by following the Change Manager Process. The philosophy here is that if a team member has successfully gone through the interview process and has demonstrated they are ready/able for an interim period in a manager role, they have the required level of EQ and discretion to have direct reports in Workday. It is, of course, expected that should the interim period not end in promotion, the team member continue to treat confidential information confidentially.

Ending Interim Period

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.
    • As a general guideline, the interim period should last no less than 30 days, and no more than 4 months .
    • The People Business Partner should submit the promotion request through Workday using the Change Job job aid including the promotion document to make the change official. In Workday, the reason for the change should be Promotion - Promotion. The accomplishments leading up to the interim and during the interim can be used for the promotion document. The manager is responsible for creating the promotion document and recommending a compensation increase. Note: Promotion documents are only required if the team member’s move results in a promotion. For lateral moves, we do not require promotion documents.
  • The team member does not complete the interim period successfully or decides that the manager track is not something they want to pursue, and moves back to their role prior to the interim period.
    • A feedback session between the team member and hiring manager should take place, so it is clear to the team member why the interim period was not successful.
    • The People Business Partner at the request of the Manager should submit a Workday Change Job Process and Approval Flow in Workday to revert the team member’s job title once the interim period comes to an end.
    • Not successfully completing the interim period does not mean the team member can not move into a similar role in the future

Regardless 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.

Updating Interim Movements in Workday

If you receive a Job Change letter to an interim role, process the change by:

  1. Saving the letter to Documents > Contracts & Changes Document Category (Do not choose Contracts & Changes - Confidential (No Employee View))
  2. Review for compensation change
  3. Access Level
    • Interim roles - Access changed (if required)
  4. Update Job title (if required)
  5. Update Manager (if required)
  6. Update Acting/Interim Tracker Spreadsheet
  7. Update Transition Tracker Spreadsheet (if required)

Note: There are no changes that are made in Workday for acting roles. To track acting positions please follow this process.

Acting

A person “acting” in the role is someone who occupies a role temporarily and will move back to their original role. “Acting” in a role may be to experiment with the role to determine if it fits an individual’s career development path goals, 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:

  • Upcoming Acting roles will be discussed during staff meetings.
  • Leadership can gather interest from their team members for the upcoming acting roles.
  • The hiring manager will determine the most suitable team member for the acting role.
  • Please make sure that the department head is in the loop and supportive of the acting period and candidate selected before moving forward.

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.

Acting Roles and Internal Mobility

In the event that a team member is working in an acting capacity in a role that then becomes an officially open position, the team member in the informal acting capacity may be considered for the open role along with other candidates. If the team member demonstrates interest in making the acting position permanent, the following process should be followed:

  1. Team member expresses interest to their manager in pursuing the position on a permanent basis.
  2. Team member reaches out to the Hiring Manager to receive feedback on their performance in the role thus far in the acting capacity.
  3. Team member is welcome to apply for the position in Greenhouse aligned with our standard hiring practices. Note: If the Hiring Manager and acting team member mutually agree to move forward with consideration for the role, the position is at the same or lower job grade as their current role, the position is within the same division, and the position is not a people management position, a formal interview process may not be required. If the Hiring Manager prefers to not include an interview process, they must connect with their aligned People Business Partner (PBP) to ensure they are supportive. This interview exception possibility exists due to the unique experience team members in acting positions have to demonstrate their ability to be successful in the position over time.
  4. After the team member officially moves into the open role, a backfill position will be created.

Demotions

Demotions are not always considered a step backwards. It may be an opportunity for a team member to acquire new skills or to move to a role that more closely aligns with their area of interest. To demote one of your direct reports, a manager should follow the following steps:

  • If the demotion is due to performance, the manager should discuss any performance issues or possible demotions with Team Member Relations.
  • Demotions should also include a review of compensation and equity in the google doc. Managers should consult with Total Rewards team on these topics; and of course always adhere to the Global Compensation Calculator.
  • Once agreement is reached on the demotion and changes (if any) in Team will act as the point of escalation to have any demotion reviewed and approved by the Compensation Group once the relevant google doc is complete.
  • Once approved, the manager informs the individual. Please cc ‘peopleops@gitlab.com’ once the individual has been informed, so the changes can be processed in the relevant administrative systems. A Job Change Letter will then be created.
  • The People Connect team should then follow the process listed under the For People Connect Team: Processing Promotions & Compensation Changes.
  • Communication should be on a need-to-know basis only and should not be made public out of respect for the individual.
  • The manager will initiate any necessary access requests or access change requests.

Job Title Specialty Changes

Job title specialties are used to indicate a stage, group and/or a specific focus area of the team member within their responsibilities. These specialties are not part of the job title, but are used to feed into reporting around stage, group and/or focus area investments. It is also a resource for the People Group and leaders to leverage to review organizational health metrics and ratios.

If any changes are required to a team members Job Title Speciality, the manager should email the People Connect team (people-connect@gitlab.com) promptly with the new job title specialty information along with the effective date of the change. If a new Job Title Specialty that does not already exist needs to be created, please open an issue to get it created in Workday using the Workday: Job Title Specialty Request template. It is an important manager responsibility to ensure this field remains accurate in Workday.

Job Title Specialty Guidance For Managers

Different departments at GitLab manage job title specialties in different ways. Below, we have outlined guidance for certain departments to document how they thing through job title specialties to ensure a consistent approach.

To easily access a report for what current job title specialties are for your team, you can follow these steps:

  • Log into Workday
  • Type “My Team Job Title Specialties” in the search bar
  • Click “OK” for your organization

For Development, Infrastructure, and Quality departments:

  • Who should have a specialty:
    • ICs: Job grade 11 and below should should have Stage and/or primary group (if applicable)
    • People Mgrs: Managers, Senior Engineering Managers, and Group Product Managers managing ICs should have Stage and/or primary group (if applicable)
  • When requesting a job title specialty update, please follow the following formatting:
    • Review Product/Categories and make sure the group names you use match these. If they don’t, please connect with your Product Manager to confirm and work with them to update if needed.
    • Add both stage and group in the job title specialty field
      • Example: Add “Govern: Authentication” instead of “Authentication”
      • Important: Please ensure that you leave a space after the colon (:) between stage and group.. For example, Create: Source Code is correct formatting, and Create:Source Code is incorrect formatting. This helps ensure that when pulling reports we have accurate counts for investment alignment.
    • Review each person and make sure it only lists one group.
      • Note: In situations where there are two groups, pick the primary group.
    • Ensure all specialty information is in the Job Title Specialty field as opposed to the Job Title Specialty (Multi-Select) field.

For Customer Support department:

  • Who should have a specialty:
    • ICs: Job Grade 9 and below to indicate the focus of the role being Global, Federal or Readiness (if applicable)
    • People Managers: Managers and Senior Managers to indicate the primary focus of their role (if applicable).

Note: For Support it’s not tied to stage, group but rather the focus of the role that is not captured in the Job title.

  • When requesting a job title specialty update, please make sure to use any of the below focus areas when reaching out to People Connect:
    • Global
    • Federal
    • Readiness

Manager Self-Service in Workday: Job Information Change

Job information changes are used to update any information on the team member’s profile in Workday that is not compensation related. The current manager submits all job information change requests (including requests to change team member’s manager). These changes are required through Workday to have an approval trail for compliance reasons.

For Current Manager: Processing Manager Changes

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” created. 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 set it up in Workday.

Note for Sales Managers: If team members are not moved under the correct sales manager in Workday, credits will not be rolled-up to the correct manager for sales commissions. See additional promotion and transfer considerations for commissionable roles here.

For People Connect: Processing Manager changes

  1. The People Connect Specialist logs into Workday via Okta to approve the transfer in Workday > click on Inbox in top right corner
  2. Review the business process titled ‘Transfer’ and reason ‘Manager to Another Manager’ > click: approve
  3. Log into BambooHR and update the manager, as this is currently connected to Time Off by Deel: Click on tab: Job > scroll to: Job Information > Click on: Add Entry > Fill in the following fields: Under ‘Effective Date’ add the same effective date as in Workday and select under ‘Reports To’ the applicable new manager > click: save

Process for EBA to update senior leadership:

  1. Send an email to People Connect, people-connect@gitlab.com requesting the changes to be made in Workday and provide an effective date.
  2. The People Connect Team will process the changes in Workday.
  3. Once complete, the team will follow-up with the EBA to let them know all changes have been made.
  4. The EBA will then need to make the changes on the Team Page.

For People Connect: Processing Job Information Change Requests

  1. Audit all job change requests and ensure the changes are captured in the Payroll tracker.
  2. In case of Job Title Specialty change requests, managers will reach out to the People Connect Team (email people-connect@gitlab.com) to have a team members Speciality updated in Workday.

Department Transfers

If you are interested in applying for an open role, please do so through Greenhouse or the internal job board, link found on the #new-vacancies Slack channel.

Please understand the following eligibility guidelines that need to be met to be able to proceed with your application:

  • Guidelines for performance eligibility:
    • Team members who are assessed at a Performing or Exceeding Performance level during Talent Assessment are eligible to be considered for another role
    • Team members whose Performance is assessed as Developing or are actively undergoing written performance management, may not be eligible. These situations require manager and/or PBP approval to proceed.
    • Team members that have not had a Talent Assessment require manager and/or PBP approval to proceed
    • Time in role eligibility will be 6 months in current role. Exceptions to this:
    • Business Impact (revenue-dependencies, interim role to perm)
    • Business driven transfers (example of realignments)
    • SDR/BDR 12 months in role

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.

For Internal Applicants

Different Job Family

  • If you are interested in transferring, simply submit an application for the new position. If you are not sure the new role is a good fit, schedule time with the hiring manager to learn more about the role and the skills needed. If after that conversation you are interested in pursuing the internal opportunity, it is recommended that you inform your current manager of your intent to apply for the role. While you do not need their permission to apply, we encourage you to be transparent with them. Most will appreciate that transparency since it’s generally better than learning about your move from someone reaching out to them as a reference check. You can also use this as an opportunity to discuss the feedback that would be given to the potential new manager regarding your performance from your current and/or past managers.
  • Transfers must go through the application process for the new position by applying on the jobs page. The team member may go through the entire interview process outlined on the vacancy description. Common exceptions to the standard interview process are behavioral or “values alignment” stages. The Recruiter will document the reason behind alterations to the standard interview plan in the team member’s Greenhouse profile. If you have any questions about the role or the process, please reach out to your Department or Division’s People Business Partner and/or please visit our Internal Hiring Process handbook page. In all cases, the applicable People Business Partner should be informed via email, before a transfer is confirmed.
  • In the case of transfers, it is expected and required that the gaining manager will check with internal references at GitLab limited to the previous and current managers; please do not conduct internal reference checks with peers or direct reports. For questions or exceptions, please engage your recruiter and people business partner.
  • It is recommended (but not required) that the applicant, current manager, or gaining manager create a private Slack channel to help coordinate the transfer. Invite anyone who will be involved such as the relevant managers, directors, people business partners, finance business partners, and recruiters.
  • If the current manager needs to backfill the role in Engineering they should follow this process. For other divisions they should work with their department leader, recruiter, and the Finance Business Partner to confirm that a backfill is available. When the transfer is confirmed, the current manager should work with recruiter and Finance Partner to obtain a GHP ID for the backfill and open the role in Greenhouse.
  • Before the offer is made the recruiter will confirm with the team member and the gaining manager that they have indeed reached out to the current manager. They will discuss the new opportunity and that an offer will be made to the team member.
  • Talent Acquisition team will ensure that, if applicable, the position has been posted for at least three business days before an offer is made.
  • Compensation and equity may be reviewed during the hiring process to reflect the new level and position.
  • If after interviews, the manager and the GitLab team member want to proceed with the transfer, internal references should be checked. While a manager cannot block a transfer, there is often good feedback that can help inform the decision. It is advised that the GitLab team member talk to their manager to explain their preference for the new team and to understand the feedback that will be given to the new manager. It should also be noted, that performance requirements are not always equal across roles, so if a GitLab team member struggles in one role, those weakness may not be as pronounced in the new role, and vice versa.
  • The Recruiter and Hiring Manager will review the offer details with the internal candidate and a Job Change Letter will be sent out by the Total Rewards team following the hiring process
  • If the team member is transferred, the new manager will announce in the #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.
  • Team members changing functional roles should complete onboarding for the new function. For example, a Backend Engineer who transferring to become or work on Frontend work should do Frontend Engineer onboarding.

Same Job Family, Different Department or Specialty

If the team member is staying in the current 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. The recruitment procedure might be shortened if the requirements for the role are the same. At a minimum we ask that the hiring manager interview the team member.

If selected for the role, a Job Change Letter will be sent by the People Connect Team outlining the changes to department and specialty for the People Connect team to process in Workday. If the current manager needs to backfill the role, they should reach out to the Finance Partner.

Internal Department Transfers

If you are interested in another position within your department and the manager is also your manager you must do the following:

  • Present your proposition to your manager with a Google doc.
  • If the vacancy is advertised on the jobs page, to be considered, you must submit an application. If there is no vacancy posting, one must be created and shared in the #new-vacancies channel so that everyone has the opportunity to apply and be considered.
  • The manager will assess the function requirements; each level should be defined in the vacancy description.
  • If approved, your manager will need to obtain approval from their manager, through the relevant chain of command.
  • Compensation and equity will be reevaluated to ensure it adheres to the compensation calculator. Do not send the proposal until this part is included.
  • If the team member is transferred, the manager will announce in the #team-member-updates Slack channel and begin any additional onboarding or offboarding necessary.

Internal Transfer Start Date

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 in 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. This is to ensure a smooth and speedy transfer and a positive team member experience. When aligning on a start date, please also consider 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.

Department Transfers Manager Initiated

All transfers should eventually be initiated by team members.

  • During the application process, we highly encourage the hiring manager to be transparent with the team member’s current manager. Doing so will allow the current manager the maximum amount of time to plan for the transfer and speed up the overall process.
  • The hiring manager should post the open role in the #new-vacancies Slack channel to attract all potentially interested candidates.
  • It is highly discouraged to reach out to a potential candidate directly without talking to their manager first. The hiring manager should share their intention of reaching out to the current manager’s team member to ensure transparency and awareness.

When promotion is a consideration - Within Same Job Family

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.

It is the manager’s responsibility to be honest with the team member about their performance as it relates to their promotion readiness. If the manager agrees that the team member is ready, then they will follow the cyclical promotion calibration process. 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.

For Internal Applicants - Different Job Family

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 process. Internal and external candidates will follow the same process with the exception of the full screening call (which will instead be 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 the team member 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 with the hiring manager.

Announcing Internal Promotions/Transfers

While the Career Mobility 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.

  1. Prior to any company-wide announcement, the team member should be given the opportunity to share the news with their immediate team members.
  2. Promotions typically also include equity grants. If the equity grant amount is not listed on the Job Change Letter, managers can navigate to Workday to find the amount to communicate to the team member following these steps:
    • Navigate to Workday
    • Go to promoted team member’s profile
    • Click Job on the left panel
    • Click Worker History from the tabs at the top.
    • Click the Business Process with Stock Grant in the title and effective date of the promotion.
    • This will open a new page to view the event. Scroll down to the Stock Grant Details table to see the proposed amount.

Please Note: Equity grants require board approval. When communicating, managers should highlight that this equity amount is the proposed amount, but will not be officially approved until the next board meeting.

  1. The new manager should post the announcement in the #team-member-updates Slack channel. This should ideally happen (timezone permitting) on the same day that the candidate signs their Job Change Letter.
  2. For cases where announcing on the same day the Job Change Letter is signed is not possible, the announcement should be no more than 24 hours after the candidate has signed.
  3. Following this initial announcement, the current manager can proceed with making this announcement in other relevant team-specific channels.

NOTE: Although 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/transfer until an announcement has been made._

Team Alignment Changes

Company priorities can change and occasionally team members may be asked to transfer to high priority initiatives or projects within other teams. While team alignment changes can occur in all areas of the business, they occur most frequently in R&D (Product and Engineering divisions), which is why most of the documentation below is R&D-centric.

Types of Team Alignment Changes

There are several types of Team Alignment Changes, including Global Prioritization changes, and Engineering Allocations, all of which are ways to ensure the organization is prioritizing and delivering effectively.

The different types of group alignment changes vary in length, purpose, DRI, and overall change impact.

Team Alignment Change Principles

The core Team Alignment Change Principles are: Communication, Collaboration, and Compliance.

Communication

For all changes, early and ongoing communication with impacted team members and their respective managers is key to ensuring group alignment changes are successful. Managers should be able to clearly articulate the business need and benefits from the change, as well as position team focus and roadmap that gives affected teams an understanding of how their future contributions will benefit GitLab.

Helpful artifacts can include:

  • Links to Team handbook page outlining goals and vision
  • Roadmap, issue backlog, and links to key epics
  • Staffing allocation plans
  • Expected impact or success criteria
Collaboration

Close cross-functional collaboration between Product and Engineering teams are critical in ensuring team member alignment changes are successful. Both groups should have a full understanding of the purpose, timeline, and actions stemming from the alignment change that they can clearly articulate to their teams and stakeholders to support the change management process. Involving the People Group and Finance (if there is budgetary impact) is also essential in ensuring a smooth transition and overall process.

Consideration should be given to impacts on product category maturity commitments for teams with team members that are moving to new groups. When possible, change should respect the Product Development Timeline to allow impacted teams to complete existing work and ensure smooth and efficient transitions.

Compliance

The Team Alignment Change process below serves to ensure that DRIs are consulting with their aligned People Business Partner (PBP) at appropriate touch points during the team alignment process. The PBP can help determine whether additional involvement from Legal and/or People Operations team is necessary. Depending on the team alignment change type, Job Change letters may be a necessary part of ensuring compliance during team member alignment changes. The PBP can help determine if additional steps like these are or are not necessary, which is why it is essential that they are looped in early.

Team Alignment Change Process

Regardless of the change type, the following steps should always be followed to ensure appropriate parties are aware of changes. Engaging your PBP early in the dicussion related to organizational design will ensure you have a thorough strategy in place for the change. Your PBP can also connect relevant information from across the business where appropriate.

  1. Inform the aligned People Business Partner (PBP) early. In addition to engaging the appropriate teams to review for compliance, PBPs should be notified of all organizational changes as the group’s partner for organizational design.
  2. Ensure the PBP reviews the changes and provides input. The PBP will ask the following questions to understand the scope of the change and team member impact:
    • Is there any team member compensation impact?
    • Is there any other budgetary impact or headcount trade offs?
    • Is there any job title impact? (not job title specialty, but job title I.E. Frontend Engineer changed to Backend Engineer)
    • Are any team members changing managers?
    • How long will the change be in effect?
  3. Depending on the response to the questions above, the PBP will loop in other groups if needed (I.E. People Operations and/or Legal). Our Legal team only needs to be involved in the process outlined below if: 1) the change is permanent (as opposed to a temporary change), and/or 2) more than just job title specialty and manager is changing (I.E. there is a change to compensation or job title).
  4. The team alignment change DRI is responsible for looping in your Finance Business Partner if there are any budgetary changes or headcount tradeoffs associated with the realignment to ensure awareness and ability to fund.
Realignment Process

We have process outlined for our various Global Prioritization team member alignment changes outlined in addition to Engineering Allocations on the Product Processes page.

Realignments are used when a permanent assignment to a team is required to resolve ongoing challenges. This has the highest impact to team members and should be considered if other options cannot achieve the desired goal. While the processes that only apply to R&D are listed in the Product Processes page, the Realignment process is outlined below as it could be applied to other departments and divisions at GitLab.

The process below outlines the process for Realignments specifically:

  1. Select a DRI to coordinate the overall realignment process.
  2. Loop in your aligned People Business Partner (PBP) and ensure the Team Alignment Change Process steps above are followed.
  3. Document the realignment decision in a confidential issue with details such as impacted parties and reasoning for realignment.
  4. Communicate the reassignment decision to affected team members. Emphasize this is not about poor performance, but rather a way to shift high value individuals to the highest priorities.
  5. Encourage individuals considering transfers to meet with hiring managers to get more information about the roles they are interested in.
  6. Ask for and record each individual’s role transfer preference. Also ask for their second choice and third choice.
  7. After individuals give their preference, the skills/requirements of the roles will be matched to the skills of the individuals. For example: level, product/technical skills, potentially soft skills.
  8. Ask hiring manager to approve transfer. If they don’t approve, review the individual’s first or second choice.
  9. Once choices are finalized, approved, and rationale is documented, the current manager should communicate the decision directly with individual impacted team members.
  10. The current manager follows the standard process for updating job information in Workday. Before communicating company-wide, all changes should be reflected in Workday.
  11. Ensure job title specialty is updated in Workday. This ensures our investment reporting data and metrics remain accurate.
  12. R&D specific: Move the confidential issue to the Product project, and label it with ~“realignment”.
  13. R&D specific: Product leader announces the realignment in #product (for smaller realignments) or #company-fyi (for larger realignments)
  14. The new manager follows the steps outlined for announcing transfers.
  15. Managers can leverage our realignment transition template to ensure that both logistical changes and team members experience touch points occur.
  16. After the realignment, the DRI opens a retrospective issue to gather feedback from affected teams in order to improve this process.
  17. After the realignment, the DRI makes the realignment issue public and closes it. This is because only planned realignments are not public. In cases where the issue does contain public information the DRI may choose to leave the issue confidential with a comment explaining the reason.

For People Success & Talent Acquisition Team

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 Workday documents of the team member who received the new role. See Department Transfers for additional details.

More details can be found in the Job Change Letter section.

Career Mobility Issue

A Career Mobility Issue is created when the one of the following criteria is met:

  • Migration from Manager to Individual Contributor (defined as a decrease in management level from Mgr+ to IC within Workday)
  • Migration of Team (for purposes of Career Mobility issues, team changes are defined as a change in both manager & cost center)

Individual contributors moving into a Management level may or may not need their access to be reviewed, please check-in with your current and new manager to confirm this step. If access should be updated follow the AR process documented here.

Or, if the team member already has access to the systems and tools needed, the manager can open ‘Becoming a GitLab Manager’ and ‘Interview Training’ issues that are housed within the Traininig Project in GitLab.

  • To open the ‘Becoming a GitLab Manager’ and ‘Interview Training’ issues visit the Training project in GitLab -> Issues -> New Issue.
  • Under ‘Description’ select the specified project template and then select Create Issue at the bottom.

When a career mobility may not be needed (but can be requested):

  • Team/Speciality change but no access request needed

Any other role changes where a Manager feels their team member’s role may require a career mobility issue, please reach out to people-connect@gitlab.com.

Career Mobility Issue Creation Process

The People Connect Specialist in the respective rotation will open a Career Mobility issue when an alert is received from Workday (for qualifying team members based on the criteria) and will be assigned to the migration for support.

The People Connect Leads will pull a monthly report to check that any qualifying team members did get their Career Mobility issue is opened.

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 member’s transition.

Important things to ensure:

  1. Add a due date of two weeks from the migration effective date.
  2. Check to see that the previous Manager and new Manager is listed correctly in the issue.
  3. Complete all applicable tasks under the People Connect list.

Important Tasks once Career Mobility has been finalized

Actions by both the current and new managers are required to set the team member up for success:

  • Creating the correct Access Requests for systems needed and for systems no longer needed.
  • Create any training issue that may be required.
  • Reminding the team member to update their title on the team page, on their GitLab profile, in Zoom, in Slack and on professional networks like LinkedIn. If relevant, remind them to order new business cards as well.
  • If we are in the middle of Annual Compensation Review, it is encouraged that the current manager and new manager arrange a successful handover of the feedback, whether sync or async.
  • All migration tasks by the applicable team members need to be completed within 2 weeks of the migration start date.

Career Mobility Retrospective

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, and proposals. 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.

Promotions and Transfers of Employees in Commissionable Roles

This section describes the steps required for promoting or transferring employees with a Sales Commission Plan. When a promotion or transfer occurs, it is important for Sales Managers to follow specific steps to ensure a smooth employee experience during the transition. The Sales Operations, Sales Finance, and the Commissions team need to be informed so the necessary systems can be updated and the team member can receive a new compensation plan.

Note These steps are in addition to all other steps required for promotions and transfers in partnership with the People team.

For the Current Sales Managers:

  1. Determine the right path for the promotion and/or transfer. Our promotion process can be found in the handbook. For transfers, please confirm if there is an open role with your Sales recruiting team. Ensure necessary stakeholders and processes are followed in advance of processing a promotion and/or transfer.
  2. Open a Territory Change Request issue to inform Sales Operations of the change so they can update Salesforce and the Territory Mapping SSOT.

For Sales Recruiting:

  1. Open a Utilizing Backfill Headcount issue to inform Sales Finance of the promotion/transfer so they can update Adaptive.
  2. Tag the appropriate members of the Sales Finance and Sales Commissions team as indicated in the ‘Approval’ section of the issue template.

For Sales Finance:

  1. Update the team member’s profile in Adaptive to account for the promotion/transfer.
  2. Partner with leadership and the People team on whether we need to open a requisition to backfill the empty role from which the team member was promoted/transferred.

For Sales Commissions:

  1. Every month, identify new hires, promotions, and transfers in Workday.
  2. Create a monthly issue to notify the Sales Strategy and Analytics team of headcount changes. The Sales Strategy and Analytics team assigns quotas1 to sales employees within 4 weeks of the employee’s hire/promotion/transfer date.
  3. The quotas are submitted to the Commissions team to then add to the Xactly system where all commissions are managed and monitored.
  4. Issue new compensation plan to the New Sales Manager for approval and release to team member.

For Team Members: Transitioning To A New Manager

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:

  • Transitioning 1-1s is a very important part of manager transitions. This helps ensure the new manager is up to speed on important discussions, deliverables, etc. so this information does not get lost in the transition.
  • The Career Mobility Handover template helps to ensure accomplishments, strengths, development areas, etc. are all captured with evidence moving forward. This makes sure career development progress continues and is not lost with manager changes.
  • Sharing your most recent 360 feedback review and most recent performance review with your new manager can also be a great way to align on your strengths and improvement areas and discuss how they can partner with you in developing both.

For Managers : Moving a Team Member to your team

When a new team member moves to your team, in addition to the items above in “Transitioning To A New Manager”, there are some additional things to consider for the new manager.

  • Do an initial confidential handover for any confidential topics between the previous and new manager (separate from the 1-1-1 with the previous manager, new manager, and team manager).
  • Do this confidential handover periodically (perhaps 2 weeks, 4 weeks and 6 weeks after transition). This will allow not only initial questions and considerations to come up, but also new ones as they arise.
  • Include in this handover the information you need for talent assessment planning that was confidential and not discussed in the 1-1-1.
  • If your new direct report is potentially up for promotion in the next 6 months, be sure to transition the information that supports from the previous manager and be the DRI to drive this forward, including both information discussed in the 1-1-1 and any confidential information discussed in the confidential handover.

Footnotes


  1. During fiscal year planning, Sales Strategy and Analytics work closely with Sales Management to assign values (full quota) to all the different Sales Territories. When a new sales employee joins, their ASM assigns them a territory (at which point there is a pre-determined value), and Sales Commissions applies a ramp schedule based on the employee’s start date and role to arrive at their carried quota. ↩︎