All People Group Metrics are being moved from manual calculation to an automated calculation of KPIs through Sisense (formerly Periscope).
The average location factor of all team members per department or division. The location factor directly correlates to geographical area in the Compensation Calculator. The company wide average location factor target is < 0.65. Each division and department also has their own average location factor target.
|Brand & Digital Design||0.80|
This metric is manually calculated by the Total Rewards Team. This metric is in the process of being moved to Periscope in the following issue (internal link).
The Total Rewards Analysts will analyze against how many team members in a division or department are compensated above the bands specific by our Global Compensation policy. To determine this, use the "In Range? (Metrics)" column from the Low Location Factor Reporting and generate a pivot table using a count of "FALSE" per department and division. Add this information to the "Location Factor Graphs/Summary" tab to generate a percentage based on total headcount per department and division as well as the raw number. The number can help explain the percentage if a department or division is small, for example.
The percent over compensation band cap is <= 1%.
Weight of Percent Over Compensation Band:
|% Over Top End of Comp Band||Weighting|
|0.01% to 4.9%||0.25|
|5% to 9.9%||0.5|
|10% to 14.9%||0.75|
The purpose of weighting how far over someone is from compensation band is to ensure if there are those over comp band slightly, they are not held at the same level as those hired well over range.
The Onboarding Satisfaction (OSAT) Survey allows new team members to provide feedback around their Onboarding and Onboarding Buddy experience within thirty days of joining GitLab. The Onboarding Satisfaction target is currently > 4.5 and is measured against month of hire as opposed to month of survey completion. View the Onboarding Satisfaction (OSAT) Survey here. Read more about how we measure satisfaction at GitLab.
Tracking the days it takes to complete onboarding task completion from the day the onboarding task is open to the day all People Group tasks are complete on the onboarding task. The target is still to be determined.
All compliance tasks within the Onboarding Issue must be closed out in alignment with the issue deadline i.e. thirty days from team member start date. Though certain tasks within the issue can be self-paced the tasks that pertain to security; code of conduct; policy acknowledgement etc. should be completed with a greater sense of urgency.
All tasks within the Offboarding Issues bar that pertainng to laptop recovery where applicable, should be completed within the five days of the issue being opened in support of internal security practices.
Ensuring team member requests to the People Experience Team are carried out efficiently and in consistent aligment with the lead times documented within the handbook.
For calculating KPIs we define Team Members on the date measured as the number of full time equivalent employees or contractors who are providing services to GitLab and are listed on our Team page. Excluded from this category are board members, board observers, core team members, and advisors. The canonical source of truth of the number of team members comes from BambooHR.
Voluntary turnover is any instance in which a team member actively chooses to leave GitLab. GitLab measures voluntary turnover over a rolling 12 month period, as well as over a calendar month. (The default period is over a rolling 12 month period.) The rolling 12 month voluntary team member turnover cap is < 10%. In order to achieve the rolling 12 month voluntary team member turnover cap, the monthly voluntary team member turnover cap is < 0.83% (10/12). The data is housed in BambooHR.
Rolling Voluntary Team Member Turnover = (Number of Team Members actively choosing to leave GitLab/Average Total Team Members Count) x 100
Industry Standard Turnover is 22% overall: 16% voluntary and 6% involuntary for software companies.
Team Member Retention = (1-(Number of Team Members leaving GitLab/Average of the 12 month Total Team Member Headcount)) x 100
GitLab measures team member retention over a rolling 12 month period, as well as over a calendar month. (The default period is over a rolling 12 month period.) The 12 month team member retention target is > 84%. In order to achieve the rolling 12 month team member retention target, the monthly team member total turnover target is < 1.3% (16/12). The data is housed in BambooHR.
Retention is calculated in Periscope.
Promotion Rate = Number of promotions over a rolling 12 month period / Current Headcount. The target is a 12% promotion rate for divisions as well as departments. Promotion Rate is calculated in SiSense. We set a promotion rate KPI since GitLab does not have specific promotion cycles (e.g. two times per year), but instead promotions can be submitted by the manager at any time. To ensure our promotions are in line with market, we analyze promotion rates each month to see trends for each group.
The promotion rate metric can be found in Sisense, which is aggregated at a company, division, and department level.
Promotion Reportand is only shared with Total Rewards and the data team as it contains sensitive compensation data. This report and Spend per Team Member can be pulled from snowflake.
This PBP team will work on updating this as a Performance Indicator / revisiting the content.
We should strive for a PIP success rate of 50% or more. This indicates that we identify underperformance early when it is easier to remediate than later. It also indicates to our team members a PIP means we still believe in them and want to make them successful, it isn't a one way street to job termination.