- name: Engineering Hiring Actual vs Plan
  base_path: /handbook/engineering/performance-indicators/
  definition: Are we able to hire high quality workers to build our product vision in a timely manner? Hiring information comes from BambooHR where employees are in the division `Engineering`. This KPI is tracked and reported on a monthly basis but year to date (headcount v plan) is also measured.
  target: 525 engineering members by Jan 31, 2019
  org: Engineering Function
  is_key: true
  health:
    level: 3
    reasons:
      - Engineering is on plan. But we are lending some of our recruiters to sales for this quarter. And we just put in place a new "one star minimum" rule that might decrease offer volume.
      - "Health: Monitor health closely"
  urls:
    - /handbook/hiring/charts/engineering-function/

- name: Development Hiring Actual vs Plan
  base_path: /handbook/engineering/development/performance-indicators/
  parent: /handbook/engineering/performance-indicators/#engineering-hiring-actual-vs-plan
  definition: Employees are in the division "Engineering" and department is "development".
  target: 270 by April 1, 2020
  org: Development Department
  is_key: true
  health:
    level: 3
    reasons:
      - Development is curently seeing 265 by April 1st.  We were slightly ahead in February of plan, but we have seen hiring slow in the last two weeks.
      - "Health: Monitor health closely"
  sisense_data:
      chart: 7066126
      dashboard: 504639
      embed: v2

- name: Sales Renewal CSAT
  base_path: /handbook/engineering/development/performance-indicators/
  definition: Can we improve the sales renewal process to meet a 90% satisfaction rating from internal sales teams?
  target: 90% by May 1, 2020
  org: Development Department
  is_key: true
  health:
    level: 3
    reasons:
      - Currently tracking at above 90% for the financial quarter.
  urls:
    - https://gitlab.zendesk.com/explore#/dashboard-builder/11756352/tab/10756422

- name: Infrastructure Hiring Actual vs Plan
  base_path: /handbook/engineering/infrastructure/performance-indicators/
  definition: Are we able to hire high quality workers to build our product vision in a timely manner? Hiring information comes from BambooHR where employees are in the division `Engineering` and department is `infrastructure`. This KPI is tracked and reported on a monthly basis but year to date (headcount v plan) is also measured. The target of 0.9 measures the actual number of hires in a given month v the planned number of hires, so 1.0 would mean we hired the exact number of employees that we planned to hire for that month.
  target: 1
  org: Infrastructure Department
  is_key: true
  health:
    level: 3
    reasons:
      - on plan
  sisense_data:
      chart: 7839908
      dashboard: 528609
      embed: v2
  urls:
    - /handbook/hiring/charts/infrastructure-department/

- name: Quality Hiring Actual vs Plan
  base_path: /handbook/engineering/quality/performance-indicators/
  definition: Are we able to hire high quality workers to build our product vision in a timely manner? Hiring information comes from BambooHR where employees are in the division `Engineering` and department is `quality`. This KPI is tracked and reported on a monthly basis but year to date (headcount v plan) is also measured.
  target: 24 by November 1, 2019
  org: Quality Department
  is_key: true
  health:
    level: 3
    reasons:
      - Engineering is on plan. But we are lending some of our recruiters to sales for this quarter. And we just put in place a new "one star minimum" rule that might decrease offer volume.
      - "Health: Monitor health closely"
  sisense_data:
      chart: 7045851
      dashboard: 516343
      embed: v2
  urls:
    - /handbook/hiring/charts/quality-department/

- name: Security Hiring Actual vs Plan
  base_path: /handbook/engineering/security/performance-indicators/
  definition: Are we able to hire high quality workers to build our product vision in a timely manner? Hiring information comes from BambooHR where employees are in the division `Engineering` and department is `security`. This KPI is tracked and reported on a monthly basis but year to date (headcount v plan) is also measured.
  target:
  org: Security Department
  is_key: true
  health:
    level: 3
    reasons:
      - "Health: Monitor health closely"
  sisense_data:
    chart: 7864105
    dashboard: 592612
    embed: v2
  urls:
    - /handbook/hiring/charts/security-department/

- name: Support Hiring Actual vs Plan
  base_path: /handbook/support/performance-indicators/
  definition: Are we able to hire high quality workers to build our product vision in a timely manner? Hiring information comes from BambooHR where employees are in the division `Engineering` and department is `support`. This KPI is tracked and reported on a monthly basis but year to date (headcount v plan) is also measured.
  target: 90% to plan per quarter
  org: Support Department
  is_key: true
  health:
    level: 3
    reasons:
      - Engineering is on plan. But we are lending some of our recruiters to sales for this quarter. And we just put in place a new "one star minimum" rule that might decrease offer volume.
      - "Health: Monitor health closely"
  sisense_data:
    chart: 7019885
    dashboard: 421422
    embed: v2
  urls:
    - /handbook/hiring/charts/support-department/

- name: UX Hiring Actual vs Plan
  base_path: /handbook/engineering/ux/performance-indicators/
  definition: Are we able to hire high quality workers to build our product vision in a timely manner? Hiring information comes from BambooHR where employees are in the division `Engineering` and department is `UX`. This KPI is tracked and reported on a monthly basis but year to date (headcount v plan) is also measured.
  target: 67 by February 1, 2021
  org: UX Department
  is_key: true
  health:
    level: 3
    reasons:
      - UX hiring is on plan, but we just put in place a new "two-star minimum" rule that might decrease offer volume.
      - "Health: Monitor health closely"
  urls:
    - /handbook/hiring/charts/ux-department/

- name: Engineering Non-Headcount Plan vs Actuals
  base_path: /handbook/engineering/performance-indicators/
  definition: We need to spend our investors' money wisely. We also need to run a responsible business to be successful, and to one day go on the public market.
  target: Unknown until FY21 planning process
  org: Engineering Function
  is_key: true
  health:
    level: 0
    reasons:
      - Currently finance tells me when there is a problem, I’m not self-service.
      - Get the budget captured in a system
      - Chart budget vs. actual over time in periscope
  urls:
    - https://app.periscopedata.com/app/gitlab/633290/Engineering-Non-Headcount-BvAs

- name: UX Non-Headcount Plan vs Actuals
  base_path: /handbook/engineering/ux/performance-indicators/
  parent: /handbook/engineering/performance-indicators/#engineering-non-headcount-budget-vs-plan
  definition: We need to spend our investors' money wisely. We also need to run a responsible business to be successful, and to one day go on the public market.
  target: Unknown until FY21 planning process
  org: UX Department
  is_key: true
  health:
    level: 3
    reasons:
      - Chart budget vs. actual over time available in periscope with clear variance 
  urls:
    - https://app.periscopedata.com/app/gitlab/632490/UX-Non-Headcount-BvAs


- name: Security Non-Headcount Plan vs Actuals
  base_path: /handbook/engineering/security/performance-indicators/
  parent: /handbook/engineering/performance-indicators/#engineering-non-headcount-budget-vs-plan
  definition: We need to spend our investors' money wisely. We also need to run a responsible business to be successful, and to one day go on the public market.
  target: Unknown until FY21 planning process
  org: Security Department
  is_key: true
  health:
    level: 0
    reasons:
      - Currently finance tells me when there is a problem, I’m not self-service.
      - Get the budget captured in a system
      - Chart budget vs. actual over time in periscope
  urls:
    - https://app.periscopedata.com/app/gitlab/633239/Security-Non-Headcount-BvAs


- name: Quality Non-Headcount Plan vs Actuals
  base_path: /handbook/engineering/quality/performance-indicators/
  parent: /handbook/engineering/performance-indicators/#engineering-non-headcount-budget-vs-plan
  definition: We need to spend our investors' money wisely. We also need to run a responsible business to be successful, and to one day go on the public market.
  target: Unknown until FY21 planning process
  org: Quality Department
  is_key: true
  health:
    level: 0
    reasons:
      - Currently finance tells me when there is a problem, I’m not self-service.
      - Get the budget captured in a system
      - Chart budget vs. actual over time in periscope
  urls:
    - https://app.periscopedata.com/app/gitlab/633240/Quality-Non-Headcount-BvAs


- name: Development Non-Headcount Plan vs Actuals
  base_path: /handbook/engineering/development/performance-indicators/
  parent: /handbook/engineering/performance-indicators/#engineering-non-headcount-budget-vs-plan
  definition: We need to spend our investors' money wisely. We also need to run a responsible business to be successful, and to one day go on the public market.
  target: Unknown until FY21 planning process
  org: Development Department
  is_key: true
  health:
    level: 3
    reasons:
      - We are spending less than planned
  urls:
    - https://app.periscopedata.com/app/gitlab/633242/Development-Non-Headcount-BvAs

- name: Infrastructure Non-Headcount Plan vs Actuals
  base_path: /handbook/engineering/infrastructure/performance-indicators/
  parent: /handbook/engineering/performance-indicators/#engineering-non-headcount-budget-vs-plan
  definition: We need to spend our investors' money wisely. We also need to run a responsible business to be successful, and to one day go on the public market.
  target: Unknown until FY21 planning process
  org: Infrastructure Department
  is_key: true
  health:
    level: 0
    reasons:
      - Currently finance tells me when there is a problem, I’m not self-service.
      - Get the budget captured in a system
      - Chart budget vs. actual over time in periscope
  urls:
    - 

- name: Support Non-Headcount Plan vs Actuals
  base_path: /handbook/support/performance-indicators/
  parent: /handbook/engineering/performance-indicators/#engineering-non-headcount-budget-vs-plan
  definition: We need to spend our investors' money wisely. We also need to run a responsible business to be successful, and to one day go on the public market.
  target: Unknown until FY21 planning process
  org: Support Department
  is_key: true
  health:
    level: 0
    reasons:
      - Currently finance tells me when there is a problem, I’m not self-service.
      - Get the budget captured in a system
      - Chart budget vs. actual over time in periscope    
  urls:
    - https://app.periscopedata.com/app/gitlab/633248/Support-Non-Headcount-BvAs      
    
- name: Engineering Average Location Factor
  base_path: /handbook/engineering/performance-indicators/
  definition: We remain efficient financially if we are hiring globally, working asynchronously, and hiring great people in low-cost regions where we pay market rates. We track an average location factor by function and department so managers can make tradeoffs and hire in an expensive region when they really need specific talent unavailable elsewhere, and offset it with great people who happen to be in low cost areas.
  target: .58 average location factor
  org: Engineering Function
  is_key: true
  health:
    level: 2
    reasons:
      - We are trending upward.
      - We need to set the target location factors on our vacancies and make sure recruiting is targeting the right areas of the globe on a per role basis.
  sisense_data:
    chart: 6272001
    dashboard: 463858
    embed: v2

- name: Engineering Recruiting Average Top-of-Funnel Location Factor
  base_path: /handbook/engineering/performance-indicators/
  definition: We need to be proactive in measuring our location factor, starting with candidates who are at the top of the recruiting funnel.
  target: 0.58
  org: Engineering Function
  is_key: true
  health:
    level: 0
    reasons:
      - We need to get this as a chart in periscope.
      - We have set the target location factors on our vacancies and make sure recruiting is targeting the right areas of the globe on a per role basis.
  urls:
    - /handbook/hiring/charts/engineering-function/

- name: Development Average Location Factor
  base_path: /handbook/engineering/development/performance-indicators/
  definition: We remain efficient financially if we are hiring globally, working asynchronously, and hiring great people in low-cost regions where we pay market rates. We track an average location factor by function and department so managers can make tradeoffs and hire in an expensive region when they really need specific talent unavailable elsewhere, and offset it with great people who happen to be in low cost areas.
  target: .58 average location factor
  org: Development Department
  is_key: true
  health:
    level: 2
    reasons:
      - We are above our target.
      - We need to set the target location factors on our vacancies and make sure recruiting is targeting the right areas of the globe on a per role basis.
  sisense_data:
    chart: 7066152
    dashboard: 504639
    embed: v2


- name: Development Recruiting Average Top-of-Funnel Location Factor
  base_path: /handbook/engineering/development/performance-indicators/
  definition: We need to be proactive in measuring our location factor, starting with candidates who are at the top of the recruiting funnel.
  target: 0.58
  org: Development Department
  is_key: true
  health:
    level: 0
    reasons:
      - We need to get this as a chart in periscope.
      - We have set the target location factors on our vacancies and make sure recruiting is targeting the right areas of the globe on a per role basis.
  urls:
    - /handbook/hiring/charts/development-department/

- name: Infrastructure Average Location Factor
  base_path: /handbook/engineering/infrastructure/performance-indicators/
  definition: We remain efficient financially if we are hiring globally, working asynchronously, and hiring great people in low-cost regions where we pay market rates. We track an average location factor by function and department so managers can make tradeoffs and hire in an expensive region when they really need specific talent unavailable elsewhere, and offset it with great people who happen to be in low cost areas.
  target: 0.58
  org: Infrastructure Department
  is_key: true
  health:
    level: 3
    reasons:
      - We are close to our target of 0.58 overall, but trending upward.
  sisense_data:
      chart: 6847486
      dashboard: 528609
      embed: v2
  urls:
    - /handbook/hiring/charts/infrastructure-department/

- name: Infrastructure Recruiting Average Top-of-Funnel Location Factor
  base_path: /handbook/engineering/infrastructure/performance-indicators/
  definition: We need to be proactive in measuring our location factor, starting with candidates who are at the top of the recruiting funnel.
  target: 0.58
  org: Infrastructure Department
  is_key: true
  health:
    level: 0
    reasons:
      - We need to get this as a chart in periscope.
      - We have set the target location factors on our vacancies and make sure recruiting is targeting the right areas of the globe on a per role basis.
  urls:
    - /handbook/hiring/charts/infrastructure-department/

- name: Quality Average Location Factor
  base_path: /handbook/engineering/quality/performance-indicators/
  definition: We remain efficient financially if we are hiring globally, working asynchronously, and hiring great people in low-cost regions where we pay market rates. We track an average location factor by function and department so managers can make tradeoffs and hire in an expensive region when they really need specific talent unavailable elsewhere, and offset it with great people who happen to be in low cost areas.
  target: 0.58
  org: Quality Department
  is_key: true
  health:
    level: 2
    reasons:
      - We are at our target of 0.58 exactly overall, but trending upward.
      - We need to get the target location factors in the charts.
      - It will probably be cleaner if we get this in periscope.
      - We need to set the target location factors on our vacancies and make sure recruiting is targeting the right areas of the globe on a per role basis.
  sisense_data:
      chart: 7045895
      dashboard: 516343
      embed: v2
  urls:
    - /handbook/hiring/charts/quality-department/

- name: Quality Recruiting Average Top-of-Funnel Location Factor
  base_path: /handbook/engineering/quality/performance-indicators/
  definition: We need to be proactive in measuring our location factor, starting with candidates who are at the top of the recruiting funnel.
  target: 0.58
  org: Quality Department
  is_key: true
  health:
    level: 0
    reasons:
      - We need to get this as a chart in periscope.
      - We have set the target location factors on our vacancies and make sure recruiting is targeting the right areas of the globe on a per role basis.
  urls:
    - /handbook/hiring/charts/quality-department/

- name: Support Average Location Factor
  base_path: /handbook/support/performance-indicators/
  definition: We remain efficient financially if we are hiring globally, working asynchronously, and hiring great people in low-cost regions where we pay market rates. We track an average location factor by function and department so managers can make tradeoffs and hire in an expensive region when they really need specific talent unavailable elsewhere, and offset it with great people who happen to be in low cost areas.
  target: 0.6
  org: Support Department
  is_key: true
  health:
    level: 2
    reasons:
      - We are at our target of 0.58 exactly overall, but trending upward.
      - We need to get the target location factors in the charts.
      - It will probably be cleaner if we get this in periscope.
      - We need to set the target location factors on our vacancies and make sure recruiting is targeting the right areas of the globe on a per role basis.
  sisense_data:
    chart: 6119437
    dashboard: 421422
    embed: v2
  urls:
    - /handbook/hiring/charts/support-department/

- name: Support Recruiting Average Top-of-Funnel Location Factor
  base_path: /handbook/support/performance-indicators/
  definition: We need to be proactive in measuring our location factor, starting with candidates who are at the top of the recruiting funnel.
  target: 0.58
  org: Support Department
  is_key: true
  health:
    level: 0
    reasons:
      - We need to get this as a chart in periscope.
      - We have set the target location factors on our vacancies and make sure recruiting is targeting the right areas of the globe on a per role basis.
  urls:
    - /handbook/hiring/charts/support-department/

- name: Security Average Location Factor
  base_path: /handbook/engineering/security/performance-indicators/
  definition: We remain efficient financially if we are hiring globally, working asynchronously, and hiring great people in low-cost regions where we pay market rates. We track an average location factor by function and department so managers can make tradeoffs and hire in an expensive region when they really need specific talent unavailable elsewhere, and offset it with great people who happen to be in low cost areas. Data comes from BambooHR and is the average location factor of all team members in the Security department. 
  target:
  org: Security Department
  is_key: true
  health:
    level: 2
    reasons:
      - Security Operations having challenges pulling quality candidates in geo-diverse locations, in order to hit expectations and allow the team to grow, we will revisit our backlog US-based candidates.
  sisense_data:
    chart: 7864119
    dashboard: 592612
    embed: v2
  urls:
    - /handbook/hiring/charts/security-department/

- name: Security Recruiting Average Top-of-Funnel Location Factor
  base_path: /handbook/engineering/security/performance-indicators/
  definition: We need to be proactive in measuring our location factor, starting with candidates who are at the top of the recruiting funnel.
  target: 0.58
  org: Security Department
  is_key: true
  health:
    level: 0
    reasons:
      - We need to get this as a chart in periscope.
      - We have set the target location factors on our vacancies and make sure recruiting is targeting the right areas of the globe on a per role basis.
  urls:
    - /handbook/hiring/charts/security-department/

- name: UX Average Location Factor
  base_path: /handbook/engineering/ux/performance-indicators/
  definition: We remain efficient financially if we are hiring globally, working asynchronously, and hiring great people in low-cost regions where we pay market rates. We track an average location factor by function and department so managers can make tradeoffs and hire in an expensive region when they really need specific talent unavailable elsewhere, and offset it with great people who happen to be in low cost areas.
  target:
  org: UX Department
  is_key: true
  health:
    level: 2
    reasons:
      - Our average location factor trended upward to .68 due to hiring for more complex stage groups.
      - We are actively working with recruiting to target the right areas of the globe on a per role basis, and we expect to see this average go down during FY21.
  sisense_data:
    chart: 7003912
    dashboard: 462325
    embed: v2
  urls:
    - /handbook/hiring/charts/ux-department/

- name: UX Recruiting Average Top-of-Funnel Location Factor
  base_path: /handbook/engineering/ux/performance-indicators/
  definition: We need to be proactive in measuring our location factor, starting with candidates who are at the top of the recruiting funnel.
  target: 0.58
  org: UX Department
  is_key: true
  health:
    level: 0
    reasons:
      - We need to get this as a chart in periscope.
      - We have set the target location factors on our vacancies and make sure recruiting is targeting the right areas of the globe on a per role basis.
  urls:
    - /handbook/hiring/charts/ux-department/

- name: Diversity
  base_path: /handbook/engineering/performance-indicators/
  definition: Diversity & Inclusion is one of our core values, and a general challenge for the tech industry. GitLab is in a privileged position to positively impact diversity in tech because our remote lifestyle should be more friendly to people who may have left the tech industry, or studied a technical field but never entered industry. This means we can add to the diversity of our industry, and not just play a zero-sum recruiting game with our competitors.
  target: It's against company policy to set diversity quotas (but we may add benchmarks to compare ourselves against).
  org: Engineering Function
  is_key: false
  health:
    level: 2
    reasons:
      - Engineering is now at the tech benchmark for gender diversity (~16%), but our potential is greater and we can do better. 20% should be our floor in technical roles. Other types of diversity are unknown.
      - Get data wired up and visualized in periscope.
      - Clear data sharing with legal.
      - Get better data about racial and country diversity.
  urls:
    - https://docs.google.com/presentation/d/1Rj6brdP2hKU1zgj0ll1poywBw0aR9jIAdT4GsLZfIIU/edit#slide=id.g4bb9f44e0b_6_160
    - https://docs.google.com/spreadsheets/d/1Jef9oopd8AeZRYM2P9B8ye2TxfdzxI0FY6ixhlyzW_c/edit#gid=1035217495

- name: Engineering Handbook Update Frequency
  base_path: /handbook/engineering/performance-indicators/
  definition: The handbook is essential to working remote successfully, to keeping up our transparency, and to recruiting successfully. Our processes are constantly evolving and we need a way to make sure the handbook is being updated at a regular cadence. This data is retrieved by querying the API with a python script for merge requests that have files matching `/source/handbook/engineering/**` or `/source/handbook/support/**` over time.
  target: Unknown until we reach maturity level 2
  org: Engineering Function
  is_key: true
  health:
    level: 0
    reasons:
      - Unknown. But my sense is we are not doing enough. For instance, we have not been able to fully update the handbook after the development department re-org (dev backend, and ops backend are still present. Although many of the new teams do have their own pages already)
      - We’d like to query the API for merge requests that have files matching /source/handbook/engineering/** over time
      - Also facet by Department
  sisense_data:
    chart: 8072801
    dashboard: 620621
    shared_dashboard: 67555d1d-ab13-4f02-b189-92c83bf4603b
    embed: v2

- name: Development Handbook Update Frequency
  base_path: /handbook/engineering/development/performance-indicators/
  parent: /handbook/engineering/performance-indicators/#engineering-handbook-update-frequency
  definition: The handbook is essential to working remote successfully, to keeping up our transparency, and to recruiting successfully. Our processes are constantly evolving and we need a way to make sure the handbook is being updated at a regular cadence. This data is retrieved by querying the API with a python script for merge requests that have files matching `/source/handbook/engineering/development/**` over time.
  target: 90
  org: Development Department
  is_key: true
  health:
    level: 2
    reasons:
      - Needs attention. But my sense is we are not doing enough. For instance, we have not been able to fully update the handbook after the development department re-org (dev backend, and ops backend are still present. Although many of the new teams do have their own pages already)
      - We need to continue to push for more frequent handbook updates.
      - Our goal is set at 90 Handbook MRs per month.
  sisense_data:
    chart: 8073923
    dashboard: 621056
    shared_dashboard: 1224665d-3fd9-4f77-a1b2-46407e655407
    embed: v2

- name: Security Handbook Update Frequency
  base_path: /handbook/engineering/security/performance-indicators/
  parent: /handbook/engineering/performance-indicators/#engineering-handbook-update-frequency
  definition: The handbook is essential to working remote successfully, to keeping up our transparency, and to recruiting successfully. Our processes are constantly evolving and we need a way to make sure the handbook is being updated at a regular cadence. This data is retrieved by querying the API with a python script for merge requests that have files matching `/source/handbook/engineering/security` over time.
  target: 100
  org: Security Department
  is_key: true
  health:
    level: 0
    reasons:
      - Unknown. 
  sisense_data:
    chart: 8073973
    dashboard: 621064
    shared_dashboard: feac7198-86db-480b-9eae-c41cb479a209
    embed: v2

- name: Quality Handbook Update Frequency
  base_path: /handbook/engineering/quality/performance-indicators/
  parent: /handbook/engineering/performance-indicators/#engineering-handbook-update-frequency
  definition: The handbook is essential to working remote successfully, to keeping up our transparency, and to recruiting successfully. Our processes are constantly evolving and we need a way to make sure the handbook is being updated at a regular cadence. This data is retrieved by querying the API with a python script for merge requests that have files matching <code>/source/handbook/engineering/quality/**</code>over time.
  target: 35
  org: Quality Department
  is_key: true
  health:
    level: 0
    reasons:
      - Unknown.
  sisense_data:
    chart: 8073930
    dashboard: 621059
    shared_dashboard: 3f0e7d87-fc13-44c3-bbba-1a9feb48c3bd
    embed: v2

- name: Support Handbook Update Frequency
  base_path: /handbook/support/performance-indicators/
  parent: /handbook/engineering/performance-indicators/#engineering-handbook-update-frequency
  definition: The handbook is essential to working remote successfully, to keeping up our transparency, and to recruiting successfully. Our processes are constantly evolving and we need a way to make sure the handbook is being updated at a regular cadence. This data is retrieved by querying the API with a python script for merge requests that have files matching `/source/handbook/support/**` over time.
  target: 50
  org: Support Department
  is_key: true
  health:
    level: 0
    reasons:
      - Unknown.
  sisense_data:
    chart: 8073961
    dashboard: 621060
    shared_dashboard: 185b8e19-a99e-4718-9aba-96cc5d3ea88b
    embed: v2

- name: UX Handbook Update Frequency
  base_path: /handbook/engineering/ux/performance-indicators/index.html#ux-handbook-update-frequency
  parent: /handbook/engineering/performance-indicators/#engineering-handbook-update-frequency
  definition: The handbook is essential to working remote successfully, to keeping up our transparency, and to recruiting successfully. Our processes are constantly evolving and we need a way to make sure the handbook is being updated at a regular cadence. This data is retrieved by querying the API with a python script for merge requests that have files matching `/source/handbook/engineering/**` or `/source/handbook/support/**` over time.
  target: 50
  org: UX Department
  is_key: true
  health:
    level: 0
    reasons:
      - Unknown.
  sisense_data:
    chart: 8073963
    dashboard: 621062
    shared_dashboard: a3a7d250-712d-4982-8d02-f13f7bcbbf71
    embed: v2


- name: Team Member Retention
  base_path: /handbook/engineering/performance-indicators/
  definition: People are a priority and attrition comes at a great human cost to the individual and team. Additionally, recruiting (backfilling attrition) is a ludicrously expensive process, so we prefer to keep the people we have :)
  target: 90%
  org: Engineering Function
  is_key: false
  health:
    level: 3
    reasons:
      - I seem to recall our attrition is now below 10% which is great compared to the tech benchmark of 22% and the remote benchmark for 16%, but the fact that I can’t just look at a simple graph makes me nervous...
      - Get into a system (BambooHR?) and visualized in periscope
      - Break out voluntary and involuntary
  urls:
    - https://docs.google.com/spreadsheets/d/1Jef9oopd8AeZRYM2P9B8ye2TxfdzxI0FY6ixhlyzW_c/edit#gid=1405344200

- name: Engineering Discretionary Bonus Rate
  base_path: /handbook/engineering/performance-indicators/index.html#engineering-discretionary-bonuses
  definition:  Discretionary bonuses offer a highly motivating way to reward individual GitLab team members who really shine as they live our values. Our goal is to award discretionary bonuses to 10% of GitLabbers in the Engineering function every month.
  target: 10%
  org: Engineering Function
  is_key: false
  health:
    level: 0
    reasons:
      - We currently track bonuses at the department level, but not at the Engineering-function level.
  urls:
    -

- name: Support Discretionary Bonus Rate
  base_path: /handbook/support/performance-indicators/index.html#customer-support-discretionary-bonuses
  definition:  Discretionary bonuses offer a highly motivating way to reward individual GitLab team members who really shine as they live our values. Our goal is to award discretionary bonuses to 10% of GitLabbers in the Customer Support department every month.
  target: 10%
  org: Support Department
  is_key: false
  health:
    level: 0
    reasons:
      - We currently track bonus percentages in aggregate, but there is no easy way to see the percentage for each individual department.
  urls:
    -

- name: Development Discretionary Bonus Rate
  base_path: /handbook/engineering/development/performance-indicators/index.html#development-discretionary-bonuses
  definition:  Discretionary bonuses offer a highly motivating way to reward individual GitLab team members who really shine as they live our values. Our goal is to award discretionary bonuses to 10% of GitLabbers in the Development department every month.
  target: 10%
  org: Development Department
  is_key: false
  health:
    level: 0
    reasons:
      - We currently track bonus percentages in aggregate, but there is no easy way to see the percentage for each individual department.
  urls:
    -

- name: Infrastructure Discretionary Bonus Rate
  base_path: /handbook/engineering/infrastructure/performance-indicators/index.html#infrastructure-discretionary-bonuses
  definition:  Discretionary bonuses offer a highly motivating way to reward individual GitLab team members who really shine as they live our values. Our goal is to award discretionary bonuses to 10% of GitLabbers in the Infrastructure department every month.
  target: 10%
  org: Infrastructure Department
  is_key: false
  health:
    level: 0
    reasons:
      - We currently track bonus percentages in aggregate, but there is no easy way to see the percentage for each individual department.
  urls:
    -

- name: Quality Discretionary Bonus Rate
  base_path: /handbook/engineering/quality/performance-indicators/index.html#quality-discretionary-bonuses
  definition:  Discretionary bonuses offer a highly motivating way to reward individual GitLab team members who really shine as they live our values. Our goal is to award discretionary bonuses to 10% of GitLabbers in the Quality department every month.
  target: 10%
  org: Quality Department
  is_key: false
  health:
    level: 0
    reasons:
      - We currently track bonus percentages in aggregate, but there is no easy way to see the percentage for each individual department.
  urls:
    -

- name: Security Discretionary Bonus Rate
  base_path: /handbook/engineering/security/performance-indicators/index.html#security-discretionary-bonuses
  definition:  Discretionary bonuses offer a highly motivating way to reward individual GitLab team members who really shine as they live our values. Our goal is to award discretionary bonuses to 10% of GitLabbers in the Security department every month.
  target: 10%
  org: Security Department
  is_key: false
  health:
    level: 0
    reasons:
      - We currently track bonus percentages in aggregate, but there is no easy way to see the percentage for each individual department.
  urls:
    -

- name: UX Discretionary Bonus Rate
  base_path: /handbook/engineering/ux/performance-indicators/index.html#ux-discretionary-bonuses
  definition:  Discretionary bonuses offer a highly motivating way to reward individual GitLab team members who really shine as they live our values. Our goal is to award discretionary bonuses to 10% of GitLabbers in the UX department every month.
  target: 10%
  org: UX Department
  is_key: false
  health:
    level: 0
    reasons:
      - We currently track bonus percentages in aggregate, but there is no easy way to see the percentage for each individual department.
  urls:
    -

- name: Throughput
  base_path: /handbook/engineering/development/performance-indicators/
  definition: Throughput shows the number of Merge Requests (MRs) on a month by month basis.  It’s important because it shows the overall development teams velocity and helps ensure that we are continually making our product better. The <a href="https://gitlab.com/clefelhocz1">Senior Director of Development</a> is the DRI on <a href="https://gitlab.com/gitlab-data/analytics/blob/master/transform/snowflake-dbt/data/engineering_productivity_metrics_projects_to_include.csv">what projects are included</a>. Please note that not all MRs in GitLab will count towards Throughput.
  target: 20% increase quarter of quarter
  org: Development Department
  is_key: false
  health:
    level: 3
    reasons:
      - Move to single code base affected throughput by roughly 20%.  One time charge associated with the transition.
  sisense_data:
    chart: 6204343
    dashboard: 463858
    embed: v2
  urls:
    - https://quality-dashboard.gitlap.com/groups/gitlab-org/monthly_merged_mrs

- name: MR Rate
  base_path: /handbook/engineering/development/performance-indicators/
  definition: MR Rate (previously known as Average MRs per Development Engineer per month) is a monthly evaluation of how MRs on average an author performs. It’s important because it measures productivity. We include external contributions from the wider community. We want to be efficient at accepting community contributions, as a result, the data is analyzed on a per category/group basis and never per GitLab team or team members. The <a href="https://gitlab.com/clefelhocz1">Senior Director of Development</a> is the DRI on <a href="https://gitlab.com/gitlab-data/analytics/blob/master/transform/snowflake-dbt/data/projects_part_of_product.csv">what projects are included</a>.
  target: 11 MRs per Development Engineer per Month
  org: Development Department
  is_key: true
  health:
    level: 3
    reasons:
      - We hit 11.7 in January and 10.4 in February.  February being lower than January because of 2 less working days.
      - "We need to continue to push for iterative behaviors and incremental MRs that are smaller and faster"
  sisense_data:
    chart: 6946736
    dashboard: 504639
    embed: v2

- name: CVE issue to update
  base_path: /handbook/engineering/development/performance-indicators/
  definition: Measurement of time CVE being issued to our product being updated.
  target: 7 days (until further data is provided)
  org: Development Department
  health:
    level: 3
    reasons:
      - We are measuring in Sisense/Periscope and are currently under our targeted threshold
  urls:
    - https://gitlab.com/gitlab-com/www-gitlab-com/issues/5936
    
  sisense_data:
    chart: 7692993
    dashboard: 588449
    embed: v2

- name: Response to Community SLO
  base_path: /handbook/engineering/development/performance-indicators/
  definition: Measurement of time from Community member MR proposed till GitLab response.  It’s important because it shows our commitment to community and engagement.
  target: No Target Set
  org: Development Department
  health:
    level: 0
    reasons:
      - We haven’t started measuring it yet.
      - What we need to do next to raise maturity - start measuring.
      - What we need to do next to improve metric - unknown.
      - Import into Periscope for better tracking.
  urls:
    - https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/20165

- name: Backend Unit Test Coverage
  base_path: /handbook/engineering/development/performance-indicators/
  definition: BE Unit Test coverage shows the unit test coverage of our code base.  As an example 95% represents that 95% of the LOC in our BE software is unit tested.  It’s important as it shows how much code is tested early in the development process.
  target: 95%
  org: Development Department
  is_key: false
  health:
    level: 3
    reasons:
      - This metric's threshold for action is around 95%.
      - We could spend further time on coded tests, it’s not recommended at this point unless we are finding significant defect correlation in our non-unit-test coverage areas.
  urls:
    - https://app.periscopedata.com/app/gitlab/475029/Source-Code-KPI's

- name: Frontend Unit Test Coverage
  base_path: /handbook/engineering/development/performance-indicators/
  definition: FE Unit Test coverage shows the unit test coverage of our code base.  As an example 95% represents that 95% of the LOC in our FE software is unit tested.  It’s important as it shows how much code is tested early in the development process. We are currently converting from Karma to Jest organically, so the performance indicator needs to show total coverage of the combined coverage.
  target: 75%
  org: Development Department
  is_key: false
  health:
    level: 2
    reasons:
      - Definite room for improvement, though it needs to be caveated with legacy vs. new code.  Move from Karma to jest and lack of combination of testing has led to most recent decline.
      - What we need to do next to raise maturity - Establish a bar for this work as some legacy factors affect code coverage.
      - What we need to do next to improve metric - Provide adequate code coverage on new code and any particularly problematic areas in legacy.
  urls:
    - https://app.periscopedata.com/app/gitlab/475029/Source-Code-KPI's

- name: Mean time to merge (MTTM)
  base_path: /handbook/engineering/development/performance-indicators/
  definition: To be aligned with CycleTime from Development. Monthly mean time to merge MRs, it tells us on average how long it takes from submitting code to being merged. The <a href="https://gitlab.com/clefelhocz1">Senior Director of Development</a> is the DRI on <a href="https://gitlab.com/gitlab-data/analytics/blob/master/transform/snowflake-dbt/data/engineering_productivity_metrics_projects_to_include.csv">what projects are included</a>.
  target: On average under 14 days
  org: Development Department
  is_key: true
  health:
    level: 2
    reasons:
      - We lowered our MTTM in February to below 5, but still have additional work to do.
      - We are focused on increasing the maintainer pool to have additional reviewers in place.
      - Our new goal is set at 4.21 days
  sisense_data:
    chart: 7438019
    dashboard: 504639
    embed: v2

- name: Commit to Merge
  base_path: /handbook/engineering/development/performance-indicators/
  definition: We want to measure the lifecycle of MRs and reduce the tail of MRs.  We don't expect to ever eliminate it because there can be unique cases, but we don't the tail trending up.    
  target: 80%
  org: Development Department
  is_key: false
  health:
    level: 2
    reasons:
      - On average, 95% of MRs are merged within 30 days from when it was opened.
      - We need to make sure the tail of the distribution is longer on the left hand side than on the right hand side and investigate where MRs are taking longer than 30 days to merge.
  sisense_data:
    chart: 8283664
    dashboard: 638729
    embed: v2

- name: Product MRs by Type
  base_path: /handbook/engineering/development/performance-indicators/
  definition: We want to measure the breakdown of our development investment by MR type/label. If an MR has more than one of these labels, the highest one in the list takes precedence. 
  target: No target set
  org: Development Department
  is_key: false
  health:
    level: 0
    reasons:
      - In March, we saw an increase in the % of MRs with an undefined label
      - The Engineering Manager for each team is ultimately responsible for ensuring that these labels are set correctly.
  sisense_data:
    chart: 8261103
    dashboard: 504639
    embed: v2

- name: Say/Do Ratios
  base_path: /handbook/engineering/development/performance-indicators/
  definition: We want to measure the number of issues that were committed at the beginning of the development phase vs. the number of issues that were closed at the end of the release cycle. Additionally, we want to capture the number of issues that were committed during the develpment phase.
  target: Unknown
  org: Development Department
  is_key: false
  health:
    level: 0
    reasons:
      - Define metric.
      - We need to come up with a consistent method to calculate say/do ratios.
      - Start with measuring data on spreadsheet.


- name: GitLab.com Availability
  base_path: /handbook/engineering/infrastructure/performance-indicators/
  definition: Percentage of time during which GitLab.com is fully operational and providing service to users within SLO parameters. GitLab.com Availability is calculated as the weighted average availability of GitLab's customer-facing services, these being, with the respective weights shown in parenthesis `git` (5), `web` (5), `api` (5), `ci-runners` (3), `registry` (2), and `sidekiq` (1). The availability of each of these services is measured according to two metrics. Apdex, for latency and error rate, for errors. A service is considered available when at least 50% of users are experiencing satisfactory latency, _and_ 50% of requests are completing successfully. If either of these conditions is not met, the service is experiencing an outage.
  target: 99.95%
  org: Infrastructure Department
  is_key: true
  urls:
    - https://dashboards.gitlab.com/d/GTp20b1Zk/public-dashboard-splashscreen?orgId=1&from=now-30d&to=now
    - https://dashboards.gitlab.net/d/general-slas/general-slas
  health:
    level: 2
    reasons:
      - Today the apdex and error ratio thresholds that go into availability may change based on amount of alerts they create
      - None of the data used for these metrics is in the data warehouse yet, therefore we cannot embed Periscope charts in the handbook

- name: Apdex and Error SLO per Service
  base_path: /handbook/engineering/infrastructure/performance-indicators/
  definition: Each service at GitLab has two general metrics SLOS. "Apdex Score" is simply put, this is a measure of the percentage of requests to that service that complete within a satisfactory amount of time. The thresholds are defined per service, so for some services it will be in microseconds for others it could be seconds. "Error Ratio" is the percentage of requests to a service which end in error. For each service in the system we define an acceptable threshold for these values. For apdex we want the actual score to be above the threshold, for error ratio, we want it to be below the threshold. We don’t expect the apdex to be a perfect 100%, and we don’t expect the error rate to be a perfect 0%, but we would like these values to be within their predefined thresholds 100% of the time. The actual amount of time that they adhere to their SLO thresholds is far below this currently
  target:
  org: Infrastructure Department
  is_key: false
  urls:
    - https://dashboards.gitlab.net/d/_03KZ-ZWz/error-budget?orgId=1
  health:
    level: 0
    reasons:
      - Attribution - setup a process for attributing SLO non-conformance to specific feature changes and product stages. This will be the basis of true error budgeting. Unfortunately, one of the side effects of the monolith is that it makes this attribution hard.
      - Improvement  - start planning work within engineering teams to improve the scores

- name: Mean Time To Detection (MTTD)
  base_path: /handbook/engineering/infrastructure/performance-indicators/
  definition: Measures the elapsed time it takes us to detect the onset of an anomalous condition and its actual detection, and serves as an indicator of our ability to monitor the environment and minimize incident resolution.
  target:
  org: Infrastructure Department
  is_key: false
  urls:
    - https://gitlab.com/gitlab-com/gl-infra/infrastructure/issues/7300
  health:
    level: 0
    reasons:
      - We can’t properly evaluate the KPI.
      - Define metric

- name: Mean Time To Resolution (MTTR)
  base_path: /handbook/engineering/infrastructure/performance-indicators/
  definition: Measures the elapsed time in hours it takes us to recover when an incident occurs, and serves as an indicator of our ability to execute said recoveries. (Only includes S1 & S2 incidents)
  target: 1
  org: Infrastructure Department
  is_key: false
  urls:
    - https://about.gitlab.com/handbook/engineering/infrastructure/performance-indicators/#regular-performance-indicators
  health:
    level: 2
    reasons:
      - Data may not be 100% accurate if incident issues are not labelled correctly
  sisense_data:
      chart: 7340995
      dashboard: 564229
      embed: v2

- name: Mean Time Between Failures (MTBF)
  base_path: /handbook/engineering/infrastructure/performance-indicators/
  definition: Measures the mean amount of time in days elapsed between incidents that affect GitLab.com’s availability. (Only includes S1 & S2 incidents)
  target: 7
  org: Infrastructure Department
  is_key: false
  health:
    level: 2
    reasons:
      -  Data may not be 100% accurate if incident issues are not labelled correctly
  sisense_data:
      chart: 7340959
      dashboard: 564229
      embed: v2
  urls:
    - https://about.gitlab.com/handbook/engineering/infrastructure/performance-indicators/#regular-performance-indicators

- name: Mean Time To Production (MTTP)
  base_path: /handbook/engineering/infrastructure/performance-indicators/
  definition: Measures the elapsed time (in hours) from merging a change in <a href="https://gitlab.com/gitlab-org/gitlab">gitlab-org/gitlab projects</a> master branch, to deploying that change to gitlab.com. It serves as an indicator of our speed capabilities to deploy application changes into production.
  target: 8
  org: Infrastructure Department
  is_key: false
  urls:
    - https://gitlab.com/gitlab-com/gl-infra/infrastructure/issues/7414
  health:
    level: 2
    reasons:
      - The data is being tracked from mid November FY20
      - The data is not 100% accurate due to the way changes are picked for deployment. High priority changes will jump the deployment queue, but the change deployment will only be reported later
  sisense_data:
      chart: 7355324
      dashboard: 564229
      embed: v2

- name: Infrastructure Hosting Cost per GitLab.com Monthly Active Users
  base_path: /handbook/engineering/infrastructure/performance-indicators/
  definition: This metric reflects an estimate of the dollar cost necessary to support one user in GitLab.com. It is an important metric because it allows us to estimate infrastructure costs as our user base grows. Infrastructure Hosting Cost comes from Netsuite; it is a sum of actual amounts with the unique account name '5026 - Hosting Services COGS' or '6026 - Hosting Services'. This cost is divided by <a href="/handbook/product/metrics/#monthly-active-user-mau">MAU</a>
  target: 1.5
  public: false
  org: Infrastructure Department
  is_key: true
  urls:
    - https://app.periscopedata.com/app/gitlab/528609/WIP:-Infrastructure-KPI-Top-Level?widget=7002009&udv=836771
  health:
    level: 3
    reasons:
      - there is additional work needed to make it transparent what is driving this metric from a granular perspective

- name: GitLab.com Performance
  base_path: /handbook/engineering/infrastructure/performance-indicators/
  definition: This metric needs to reflect the performance of GitLab as experienced by users. It should capture both frontend and backend performance. Even though the Infrastructure will be responsible for this metric they will need other departments such as Development, Quality, PM, and UX to positively affect change.
  target:
  org: Infrastructure Department
  is_key: true
  urls:
    - /handbook/engineering/performance/#past-and-current-performance
  health:
    level: 2
    reasons:
      - We are experiencing occasionally slowness of both the frontend and git operations.

- name: Infrastructure Hosting Cost vs Plan
  base_path: /handbook/engineering/infrastructure/performance-indicators/
  definition: Tracks our actual infrastructure hosting costs against our planned infrastructure hosting costs for GitLab.com. We need this metric to manage our financial position.
  target:
  org: Infrastructure Department
  is_key: true
  urls:
    - https://app.periscopedata.com/app/gitlab/528609/WIP:-Infrastructure-KPI-Top-Level?widget=6990885&udv=836771
  health:
    level: 3
    reasons:
      - There was no locked plan for hosting services, so we are using the latest forecast until next plan lock

- name: Disaster Recovery (DR) Time-to-Recover
  base_path: /handbook/engineering/infrastructure/performance-indicators/
  definition: Tracks time to recover full operational status in case of a catastrophic incident in our primary production environment.
  target: 60m
  org: Infrastructure Department
  is_key: false
  health:
    level: 0
    reasons:
      - DR environment is not operational.
      - Complete DR rollout with Geo and implement fire drills to track the metric.
      - Implement fire drills to track the metric.

- name: Review App deployment success rate for GitLab
  base_path: /handbook/engineering/quality/performance-indicators/
  definition: Measures the stability of our test tooling to enable engineering efficiency.
  target: 99%
  org: Quality Department
  is_key: true
  health:
    level: 1
    reasons:
      - Our builds are passing however the app deployment in review-deploy job is unstable.
      - Our usage is going up and we hit GCP Firewall rule quota.
      - We are investigating an issue with upstream nginx-ingress with the Distribution team.
      - We are going to limit review apps to automatically deploy when frontend changes are present.
  urls:
    - https://gitlab.com/gitlab-org/gitlab/-/issues/208670
    - https://gitlab.com/gitlab-org/gitlab/-/issues/208834
    - https://gitlab.com/gitlab-org/charts/gitlab/issues/1780
  sisense_data:
    chart: 6721558
    dashboard: 516343
    embed: v2

- name: Review App deployment success rate for GitLab FOSS
  base_path: /handbook/engineering/quality/performance-indicators/
  definition: Measures the stability of our test tooling to enable engineering efficiency. See <a href="https://gitlab.com/groups/gitlab-org/-/epics/605">this epic</a> for specific items.
  target: 99%
  org: Quality Department
  is_key: false
  health:
    level: 3
    reasons:
      - Rate is now stabilizing, we hit 100% in March 2020.
      - Our improvements seems to be working in the FOSS project which has a smaller scale of activity.
  sisense_data:
    chart: 6773708
    dashboard: 516343
    embed: v2

- name: Scheduled pipeline success rate for master branch in GitLab project
  base_path: /handbook/engineering/quality/performance-indicators/
  definition: Measures the stability of our <code>master</code> scheduled pipelines to accelerate cycle time of merge requests, continuous deployments and GitLab EE releases.
  target: 95%
  org: Quality Department
  is_key: true
  health:
    level: 2
    reasons:
      - Rate is 80% as of March 2020, 10 day moving average increased from 81% to 85%.
      - Our master broken triage process is effective.
      - Our defensive measure with rebasing master with pipeline results seems to be improving the stability.
  urls:
    - https://gitlab.com/groups/gitlab-org/-/epics/2529
    - https://gitlab.com/gitlab-org/gitlab/issues/200037
  sisense_data:
    chart: 6782832
    dashboard: 516343
    embed: v2

- name: Scheduled pipeline success rate for master branch in GitLab FOSS project
  base_path: /handbook/engineering/quality/performance-indicators/
  definition: Measures the stability of our <code>master</code> scheduled pipelines to accelerate GitLab CE releases.
  target: 95%
  org: Quality Department
  is_key: false
  health:
    level: 2
    reasons:
      - Rate is above 78% as of December 2019 but we need to make sure it continues to go up.
  sisense_data:
    chart: 6782949
    dashboard: 516343
    embed: v2

- name: Average merge request pipeline duration for GitLab
  base_path: /handbook/engineering/quality/performance-indicators/
  definition: Measures the average duration of our merge request pipelines to accelerate our development cycle time, and continuous deployments. See epics <a href="https://gitlab.com/groups/gitlab-org/-/epics/1853">1853</a> and <a href="https://gitlab.com/groups/gitlab-org/-/epics/25">25</a> for individual work items.
  target: 30 minutes
  org: Quality Department
  is_key: true
  health:
    level: 2
    reasons:
      - Average duration continues to trend slightly lower, we are at 65 mins as of March 2020.
      - We optimized jest frontend unit test jobs.
      - We are working on more improvements with caching and reducing unneeded test jobs.
  urls:
    - https://gitlab.com/groups/gitlab-org/-/epics/2530
    - https://gitlab.com/gitlab-org/gitlab/issues/34322
    - https://gitlab.com/gitlab-org/gitlab/-/merge_requests/26008
  sisense_data:
      chart: 6782964
      dashboard: 516343
      embed: v2

- name: Average duration of end-to-end test suite execution on CE/EE master branch
  base_path: /handbook/engineering/quality/performance-indicators/
  definition: Measures the average duration of our full QA/end-to-end test suite in the <code>master</code> branch to accelerate cycle time of merge requests, and continuous deployments.
  target:
  org: Quality Department
  is_key: false
  health:
    level: 0
    reasons:
      - We haven't started measuring it yet.
      - Define an automated mechanism to collect data in Periscope.
      - Define threshold.
  urls:
    - https://gitlab.com/gitlab-org/quality/team-tasks/issues/198

- name: Ratio of quarantine vs total end-to-end tests in CE/EE master branch
  base_path: /handbook/engineering/quality/performance-indicators/
  definition: Measures the stability and effectiveness of our QA/end-to-end tests running in the <code>master</code> branch.
  target:
  org: Quality Department
  is_key: false
  health:
    level: 0
    reasons:
      - We haven’t started measuring it yet.
      - Define an automated mechanism to collect data in Periscope.
      - Define threshold.
  urls:
    - https://gitlab.com/gitlab-org/quality/team-tasks/issues/199

- name: New issue first triage SLO
  base_path: /handbook/engineering/quality/performance-indicators/
  definition: Measure our speed to triage new issues. We currently have ~400 new issues every week in CE/EE. We need to go through all of them and identify valid issues and high severity bugs.
  target: 5 days
  org: Quality Department
  is_key: true
  health:
    level: 0
    reasons:
      - We haven’t started measuring it yet. We have made progress on fanning out first triage to Engineers in the Quality Department.
      - Define an automated mechanism to collect data in Periscope.
      - Define threshold.
      - Fan out triaging to all of Engineering and not just the Quality Department.
  urls:
    - https://gitlab.com/gitlab-org/quality/team-tasks/issues/136
    - https://gitlab.com/groups/gitlab-data/-/epics/50

- name: Monthly new bugs per stage group
  base_path: /handbook/engineering/quality/performance-indicators/
  definition: Tells us the hit rate of defects per each stage group on a monthly basis
  target:
  org: Quality Department
  is_key: false
  health:
    level: 1
    reasons:
      - Defect trends on a high level is increasing for mature areas of the product, but also due to double counting from duplicate issues. We need to raise more awareness and encourage teams to look at this metric and evaluate themselves regularly.
      - Add this metric into every stage groups' dashboard to raise awareness.
      - Define threshold and migrate into Periscope. https://gitlab.com/gitlab-data/analytics/issues/1792
      - Define a mechanism to filter duplicate issues.
  urls:
    - https://quality-dashboard.gitlap.com/groups/gitlab-org/bugs_by_team

- name: Mean time to resolve S1-S2 functional defects
  base_path: /handbook/engineering/quality/performance-indicators/
  definition: Tells us the monthly average time to resolve high severity defects.
  target:
  org: Quality Department
  is_key: false
  health:
    level: 1
    reasons:
      - We have prioritized efforts and trend is stabilizing. We have equiped engineering groups with better weeky triage reports. We will likely not trend downwards until the backlog of older bugs are closed.
      - Migrate to GitLab Insights dashboard https://gitlab.com/groups/gitlab-org/-/insights.
      - Add integration into Periscope as a GitLab feature.
      - Add this metric into every stage groups' dashboard to raise awareness.
      - Define a mechanism to filter duplicate issues.
  urls:
    - https://quality-dashboard.gitlap.com/groups/gitlab-org/time_to_close_bugs

- name: P1/P2 open bugs past target SLO
  base_path: /handbook/engineering/quality/performance-indicators/
  definition: Measure the number of bugs past the priority SLO timeline.
  target: 0 P1, 10 P2 for customer labelled bugs.
  org: Quality Department
  is_key: true
  health:
    level: 2
    reasons:
      - We have very little P1 but a large number of P2
      - We have prioritized efforts. We will likely not trend downwards until the backlog of older bugs are closed.
      - Improve the chart by changing time series to bug age not creation month.
      - Define threshold and migrate into periscope.
  urls:
    - https://gitlab.com/groups/gitlab-org/-/insights#/bugsPastSLO

- name: Ratio of bugs triaged with Severity (and priority)
  base_path: /handbook/engineering/quality/performance-indicators/
  definition: Measure our ability to differentiate high severity defects from the pool so we can prioritize fixing them above trivial bugs.
  target:
  org: Quality Department
  is_key: false
  health:
    level: 2
    reasons:
      - The number of untriaged bugs have been stable but we can still do better. We need to establish an actionable threshold for each team.
      - Convert chart to time series data and define threshold.
      - Migrate into Native GitLab Insights dashboard https://gitlab.com/groups/gitlab-org/-/insights.
      - Add integration into Periscope as a GitLab feature.
      - Providing a weekly bug report with a distribution matrix of priority and severity. - https://gitlab.com/gitlab-org/quality/triage-ops/issues/186
      - Provide training for product/engineering groups on how to effectively use Priority and Severity. - https://gitlab.com/gitlab-org/quality/team-tasks/issues/148
      - Enforce triaging escalations (based on stage group labels) for bugs with no severity/priority labels.
  urls:
    - https://quality-dashboard.gitlap.com/groups/gitlab-org/bug_classification

- name: The ratio of closed (not merged MRs) vs merged MRs over time.
  base_path: /handbook/engineering/quality/performance-indicators/
  definition: Measure amount of throw away work vs merged.
  target:
  org: Quality Department
  is_key: false
  health:
    level: 2
    reasons:
      - From experimental charts we don’t have that much throw away work. Not giving a passing grade because we don’t have a threshold to grade against.
      - Define threshold.
      - Migrate into Native GitLab Insights dashboard https://gitlab.com/groups/gitlab-org/-/insights.
      - Add integration into Periscope as a GitLab feature.
      - Analyze throw away work and root cause the reason. Improve planning and collaboration.
  urls:
    - https://quality-dashboard.gitlap.com/groups/gitlab-org/mrs_by_state

- name: MTTM (Mean-Time-To-Mitigation) for S1-S2-S3 security vulnerabilities
  base_path: /handbook/engineering/security/performance-indicators/
  definition: The MTTM metric is an indicator of our efficiency in mitigating security vulnerabilities, whether they are reported through HackerOne bug bounty program (or other external means, such as security@gitlab.com emails) or internally-reported. The average days to close issues in the GitLab CE project (project_id = '278964') that are have the label `security` and S1, S2, or S3; this excludes issues with variation of the security label (e.g. `security review`) and S4 issues. Issues that are not yet closed are excluded from this analysis. This means historical data can change as older issues are closed and are introduced to the analysis. The average age in days threshold is set at the daily level.
  target:
  org: Security Department
  is_key: true
  health:
    level: 3
    reasons:
      - MTTM metrics continue to show the effectiveness of S1/S2/S3 labelling and follow-up in GitLab project
  urls:
    - https://app.periscopedata.com/app/gitlab/592612/Security-KPIs?widget=7864145&udv=0

- name: Blocked Abuse Activity
  base_path: /handbook/engineering/security/performance-indicators/
  definition: This metric is focused around the efficacy of our Abuse Handling and Abuse Operations. The Abuse Team is responsible for tracking, automating, and reporting on blocked abusive accounts on GitLab.com, and tracking reduction in cloud spend where the activities are due to abuse.
  target:
  org: Security Department
  is_key: true
  health:
    level: 2
    reasons:
      - Median time between account creation and mitigation has gone from 687 hrs (11/2019, 1644 accounts blocked) to 0.19 hrs (12/2019, 5819 accounts blocked) with the introduction of additional abuse detection automation. The dramatic improvement in time to mitigation is partially skewed by the manual clean up of old/dormant spam accounts.
      - Abuse Operations is working with Defend to ensure that existing and upcoming tooling ends up being part of the product with no duplication of efforts among the teams.
      - Reporting is available, but reporting is not in Periscope.
  urls:
    - https://placeholder.com/

- name: HackerOne budget vs actual (with forecast of 'unknowns')
  base_path: /handbook/engineering/security/performance-indicators/
  definition: We currently run a public bug bounty program through HackerOne, and this program has been largely successful - we get a lot of hacker engagement, and since the program went public, we have been able to resolve nearly 100 reported security vulnerabilities. The bounty spend is however, a budgeting forecast concern because of the unpredictability factor from month to month.
  target:
  org: Security Department
  is_key: true
  health:
    level: 2
    reasons:
      - H1 spend has been decreasing, even after the bump to "critical" and "high" findings. Projected spend for Q1 20 is $80k, compared to Q1 19's $180k.

- name: HackerOne outreach and engagement
  base_path: /handbook/engineering/security/performance-indicators/
  definition: The true mark of a successful public bug bounty program is partially tied to hacker outreach and engagement. We’ve already implemented quite a bit of security automation to engage hackers. For example, when findings are submitted by hackers, an automated dynamic message is generated by our automation scripts and they receive a response with expected ETA on a reply (this ETA is dependent on how many findings are in our ‘to be triaged’ bucket at that time, so the ETA changes). This ensures the hacker knows 1) we received the report, 2) a human will be reading the report within a certain ETA, and 3) a human will be replying within an ETA. Our program went public in mid-December 2018, and we are now focusing on outreach and incentive programs to retain the top hackers to our program - about 90%+ of the most impactful reports are currently submitted by our Top 5-10 hackers, so it is imperative we retain those individuals.
  target:
  org: Security Department
  is_key: false
  health:
    level: 2
    reasons:
      - We are getting applications for roles in the Security Department from long time H1 researchers.
      - We marked the $1 million bug bounty mark by publishing a blog post that received acclaim within the global security community.

- name: Security Response Times
  base_path: /handbook/engineering/security/performance-indicators/
  definition: Although the Security Department is always working towards minimizing friction to day-to-day company operations, it is never possible to be 100% frictionless when adding an additional step into an existing process. As cumbersome as this may feel (despite our best efforts), this is usually a necessary step to maturing our security posture and meeting customer requirements (especially large enterprise customers). We plan to measure Security response times to new processes such as access request approval issues and security reviews for 3rd party vendor requests to highlight where bottlenecks are to the current process, and use a data-driven approach to iterate on better processes.
  target:
  org: Security Department
  is_key: false
  health:
    level: 0
    reasons:
      - Note that this is a newly proposed KPI, and is not ready for today's meeting, but we will plan to show metrics around response times for future metrics/KPIs meeting.

- name: Perception of system usability
  base_path: /handbook/engineering/ux/performance-indicators/
  definition: The System Usability Scale (SUS) is an industry-standard survey that measures overall system usability based on 10 questions. Moving a SUS score upward even a couple of points on a large system is a significant change. The goal of this KPI is to understand how usability of the GitLab product rates against industry standards and then track trends over time. Even though UX will be responsible for this metric, they will need other departments such as PM and Development to positively affect change. See <a href="https://measuringu.com/interpret-sus-score/">Table 1</a> for grading details.
  target: B+
  sisense_data:
    chart: 5976554
    dashboard: 462325
    embed: v2
  org: UX Department
  is_key: true
  health:
    level: 2
    reasons:
      - Perceived usability rates as a B- to a low B.
      - Continue to action on UX Scorecards for every stage group.
  urls:
    - https://docs.google.com/spreadsheets/d/1RzoYgjIH8RYiUxEJmUb7f_hTy83vTxpRtJS4AL0Ekrk/edit?usp=sharing

- name: Ratio of proactive vs reactive UX work
  base_path: /handbook/engineering/ux/performance-indicators/
  definition: Use customer research to validate solutions. This includes feedback from the wider GitLab community gathered via multiple comments, a survey, usability study, card sort/tree test, and/or user interviews. Hypothesis that there is a connection between this KPI and SUS KPI.
  target: 2 validation issues per Product Designer per quarter
  sisense_data:
    chart: 7004937
    dashboard: 462325
    embed: v2
  org: UX Department
  is_key: true
  health:
    level: 3
    reasons:
      - In Q4 FY21, we had 28 product Designers on staff and 58 total validation issues. This is two higher than the target of 56.

- name: UX debt
  base_path: /handbook/engineering/ux/performance-indicators/
  definition: UX Debt means that for a given issue, we failed to meet defined standards for our Design system or for usability and feature viability standards as defined in agreed-upon design assets. When we fail to ship something according to defined standards, we track the resulting issues with a "UX debt" label. Even though UX will be responsible for this metric, they will need other departments such as PM and Development to positively affect change.
  target: Under 50 open "ux debt" issues
  sisense_data:
    chart: 6599301
    dashboard: 462325
    embed: v2
  org: UX Department
  is_key: false
  health:
    level: 2
    reasons:
      - Open "UX debt" issues are growing over time. Average days to close a "UX debt" issue is unacceptable.
      - Quality Engineering helped us add UX Debt to the weekly triage issue. Since then, we've seen a slight decrease in total UX debt, but not enough to change the health score of this metric.

- name: Throughput of Technical Writing team documentation MRs
  base_path: /handbook/engineering/ux/performance-indicators/
  definition: This KPI tracks the number of ~documentation MRs merged every month across all GitLab projects which have involvement (review, collaboration, or authoring) from the ~"Technical Writing" team. The goal is to increase velocity over time as the team grows.
  target: 25 MRs per technical writer per month
  org: UX Department
  is_key: false
  health:
    level: 3
    reasons:
      - Technical Writer throughput has remained high, even as we've added more Technical Writers who require onboarding. In February 2020, we had 10 active writers and 339 MRs for an average of 34 MRs per writer.
  sisense_data:
    chart: 6223816
    dashboard: 462325
    embed: v2

- name: Distribution of Technical Writing team documentation effort
  base_path: /handbook/engineering/ux/performance-indicators/
  definition: Tracks the type of documentation changes involving the ~"Technical Writing" team, based on `docs::` scoped label applied. Labels include feature, new, improvement, fix, revamp, or housekeeping. Our goal is to increase the proportion of efforts where Technical Writers proactively improve content, instead of just responding to a new feature or fixing a bug (improvement, new, and revamp).
  target: 50% of MRs are focused on proactively making our docs better ([improvement, revamp, new](https://gitlab.com/gitlab-org/gitlab/-/labels?utf8=%E2%9C%93&subscribed=&search=docs%3A%3A))
  org: UX Department
  is_key: false
  health:
    level: 2
    reasons:
      - Proportion was consistently around 50% from October through December 2019, but decreased in January and February of 2020.
      - Not all documentation issues have the correct labels. We need to add automation to prompt contributors to consistently add the scoped labels.
  sisense_data:
    chart: 6324830
    dashboard: 462325
    embed: v2

- name: Support Satisfaction (SSAT)
  base_path: /handbook/support/performance-indicators/
  definition: A measure of how satisfied our customers' are with their interaction with the GitLab Support team. This is based on survey responses from customers after each ticket is solved by the Support team using a Good or Bad rating.
  target: 95%
  org: Support Department
  is_key: true
  health:
    level: 2
    reasons:
      - SSAT is good (above 91%) but target is 95%.
      - Collecting feedback from dissatisfied customers to identify trends.
      - Support Managers review trends to create changes to workflows and/or training.
  sisense_data:
    chart: 5992548
    dashboard: 463858
    embed: v2
    border: off

- name: Service Level Agreement (SLA)
  base_path: /handbook/support/performance-indicators/
  definition: GitLab Support commits to an initial substantive response in a specified amount of time from the time the customer submits a ticket. The SLA for this first reply is based on each customer's Support Plan.
  target: 95% to Priority Support SLAs
  org: Support Department
  is_key: true
  health:
    level: 2
    reasons:
      - Inconsistent performance to a 95% target achievement.
      - Focused staffing to key time gaps with higher level of ticket SLA breaches.
      - Adjusting workflow to enable working with customers in their preferred timezone.
      - Working with the data team on understanding the inconsistent we see between our ZenDesk SLA data and Periscope via 2857
  urls:
  - https://about.gitlab.com/support/#service-level-agreement-sla-details
  - https://gitlab.com/gitlab-data/analytics/-/issues/2857

  sisense_data:
    chart: 6892851
    dashboard: 421422
    embed: v2
    border: off

- name: Customer Support Margin
  base_path: /handbook/support/performance-indicators/
  definition: Total Support headcount and non-headcount expenses as a percent of ARR.
  target: Headcount and non-headcount expenses to be 10% of ARR
  org: Support Department
  is_key: true
  health:
    level: 3
    reasons:
      - Tracked and reported monthly, and for the year we are under our margin target for spend.
      - Maintain focus on spend while iterating on needs for non-headcount expense requirements.
  sisense_data:
    chart: 6032346
    dashboard: 421422
    embed: v2
    border: off

- name: ARR per support team member
  base_path: /handbook/support/performance-indicators/
  definition: This is a function of modeling for staffing to a ratio of ARR and not directly influenced by Support staff performance but more to our hiring which is managed through other performance indicators.
  target: Greater than $1.175M
  public: false
  org: Support Department
  is_key: true
  health:
    level: 3
    reasons:
      - Determine the need to continue to track this as a KPI versus a Support Gearing Ratio to ARR for modelling hiring plans.
  urls: 
    - https://app.periscopedata.com/app/gitlab/421422/Support-KPIs?widget=6032352&udv=0
    - https://about.gitlab.com/handbook/sales/#annual-recurring-revenue-arr
    - https://about.gitlab.com/handbook/support/
    

- name: Average daily tickets closed per Support team member
  base_path: /handbook/support/performance-indicators/
  definition: The Gitlab support team aims to staff the team based on weighted average of both self-managed and GitLab.com tickets closed in a given month by an individual support team member involved in customer tickets. Total number of tickets closed / Total number of support staff.
  target: 65 tickets closed per support staff per month
  org: Support Department
  is_key: true
  health:
    level: 2
    reasons:
      - We are continuing to onboard new support agents and engineers so this average will be relatively dynamic as new people onboard.  Still, we are in a healthy place for solving tickets and keeping pace.
      - Determine appropriate team metrics to continue to drive individual contribution to solving tickets.
      - Identify ways to match complexity to time to solve to differentiate expectations per support role.
  sisense_data:
    chart: 6133962
    dashboard: 421422
    embed: v2
    border: off

- name: Manager to customer support rep ratio
  base_path: /handbook/support/performance-indicators/
  definition: The Manager to IC Ratio is the ratio of individual contributors to one manager. This data comes from Bamboo HR.
  target: The long term target for this metric is 10:1
  org: Support Department
  is_key: true
  health:
    level: 3
    reasons:
      - While we have an overall ratio of less than 10:1 as a department at time of this evaluation, we have re-balanced the larger imbalance in EMEA with new management in place, and have plans for 3 additional managers to hire to accommodate growth in other teams.
      - Hire to plan for new managers.
      - Re-align ICs to new managers to restore balance.
  sisense_data:
    chart: 6119434
    dashboard: 421422
    embed: v2
    border: off


- name: Capital Efficiency Ratio
  base_path: /handbook/finance/corporate-finance-performance-indicators/
  definition: IACV per Capital Consumed by calendar month. Capital Efficiency Ratio = IACV/Capital Consumed. IACV is sourced from SFDC and Capital Consumed is sourced from Netsuite.
  target: GitLab's target is to be > 2. The target will change in the future when GitLab is no longer in the capital consumption phase.
  org: Corporate Finance
  is_key: true
  health:
    level: unknown
    reasons:
      - tbd
  sisense_data:
    chart: 6383816
    dashboard: 483606
    embed: v2
    border: off

- name: Gross margin
  base_path: /handbook/finance/corporate-finance-performance-indicators/
  definition: Gross margin is defined as total revenue less cost of revenues as defined by GAAP and reported in the Company's financial statements.
  target: Our long term gross margin target is 85% but is dependent on the revenue mix between products - self managed and gitlab.com and professional services.
  org: Corporate Finance
  public: false
  is_key: true
  health:
    level: unknown
    reasons:
      - tbd
  urls:
    - https://app.periscopedata.com/app/gitlab/483606/Finance-KPIs?widget=6282089&udv=0

- name: Average Days Sales Outstanding (DSO)
  base_path: /handbook/finance/corporate-finance-performance-indicators/
  definition: Average Accounts Receivable balance over prior 3 months divided by Total Contract Value (TCV) bookings over the same period multipied by 90 that provides an average number of days that customers pay their invoices. The accounts receivable data is sourced from Netsuite and the TCV data is sourced from SFDC.
  target: the median DSO for SAAS companies is 76 days. Our target at GitLab is 45 days.
  org: Corporate Finance
  is_key: true
  health:
    level: unknown
    reasons:
      - tbd
  sisense_data:
    chart: 6880901
    dashboard: 483606
    embed: v2
    border: off

- name: Runway
  base_path: /handbook/finance/corporate-finance-performance-indicators/
  definition: Runway is defined as the number of months based on cash balance plus available credit divided by average cash burn. The analysis can be found on the Finance Dashboard. Cash data is sourced from Netsuite.
  target: Our target is that this metric is always greater than 12 months.
  org: Corporate Finance
  public: false
  is_key: true
  health:
    level: unknown
    reasons:
      - tbd
  urls:
    - https://app.periscopedata.com/app/gitlab/483606/Finance-KPIs?widget=6880820&udv=0

- name: ARR by Annual Cohort
  base_path: /handbook/finance/corporate-finance-performance-indicators/
  definition: ARR can be sliced many different ways for analysis. In the ARR by Cohort analyses, we look at ARR by the Fiscal Year Cohort. That analysis can be found on the Finance Dashboard. The data for ARR by Annual Cohort is sourced from SFDC and Zuora.
  org: Corporate Finance
  public: false
  is_key: true
  health:
    level: unknown
    reasons:
      - tbd
  urls:
    - https://app.periscopedata.com/app/gitlab/483606/Finance-KPIs?widget=6256724&udv=0

- name: Capital Consumption vs Plan
  base_path: /handbook/finance/corporate-finance-performance-indicators/
  definition: TCV less Total Operating Expenses. This metric tracks net cash consumed excluding changes in working capital (i.e. burn due to balance sheet growth). Since the growth in receivables can be financed using cheap debt instead of equity this is a better measure of capital efficiency than cash burn. Capital Consumed is sourced from Netsuite.
  public: false
  org: Corporate Finance
  is_key: true
  health:
    level: unknown
    reasons:
      - tbd
  urls:
    - https://app.periscopedata.com/app/gitlab/483606/Finance-KPIs?widget=6279480&udv=0

- name: Hires vs. Plan
  base_path: /handbook/hiring/performance_indicators/
  definition: The number of hires based on start date divided by the number of planned hires in a given month.  This KPI is tracked and reported on a monthly basis but year to date is also measured.
  org: Recruiting
  is_key: true
  health:
    level: unknown
    reasons:
      - tbd
  sisense_data:
    chart: 6888845
    dashboard: 482006
    embed: v2
    border: off

- name: Time to Offer Accept (Days)
  base_path: /handbook/hiring/performance_indicators/
  definition: The median number of days from when a candidate is active in Greenhouse (applied, referred, or sourced) to accepting an offer in a given month.
  target: The Time to Offer Accept (Days) target is < 45.
  org: Recruiting
  is_key: true
  health:
    level: unknown
    reasons:
      - tbd
  sisense_data:
    chart: 6235296
    dashboard: 482006
    embed: v2
    border: off

- name: Offer Acceptance Rate
  base_path: /handbook/hiring/performance_indicators/
  definition: The number of offers accepted divided by the number of offers extended in a given month. In other words, if 50 offers were extended in June, the offer acceptance rate is the total number of those offers accepted divided by fifty. If an offer is extended June 30 but accepted July 1, it is presented in June's offer acceptance rate. This means that last month's numbers may change slightly as offers are accepted in the beginning of the next calendar month.
  target: The offer acceptance rate target is > 0.9.
  org: Recruiting
  is_key: true
  health:
    level: unknown
    reasons:
      - tbd
  sisense_data:
    chart: 6235279
    dashboard: 482006
    embed: v2
    border: off

- name: Interviewee Satisfaction (ISAT)
  base_path: /handbook/hiring/performance_indicators/
  definition: The answer to the ‘Interviewee Satisfaction (ISAT) Score’ question, “Overall, my interviewing experience was a positive one,” is greater than 4.1 across all departments in a given month (1 - 5 response scale).
  target: greater than 4.1
  org: Recruiting
  is_key: true
  health:
    level: unknown
    reasons:
      - tbd
  sisense_data:
    chart: 6858936
    dashboard: 482006
    embed: v2
    border: off

- name: Candidates Sourced by Recruiting Department vs. Candidates Hired
  base_path: /handbook/hiring/performance_indicators/
  definition: How many candidates were sourced by the Recruiting Department out of those who we hired in a given month.
  target: The candidates sourced versus candidates hired target is greater than 0.28.
  org: Recruiting
  is_key: true
  health:
    level: unknown
    reasons:
      - tbd

- name: Outbound Candidates versus Candidates Hired
  base_path: /handbook/hiring/performance_indicators/
  definition: Outbound candidates are both sourced candidates and candidates referred by team members.
  target: The goal is that outbound candidates are greater than 50 percent of all hired candidates.
  org: Recruiting
  is_key: true
  health:
    level: unknown
    reasons:
      - tbd

- name: Cost Per Hire
  base_path: /handbook/hiring/performance_indicators/
  definition: Cost per hire is calculated by taking the total monthly expenses incurred in the Recruiting department and other monthly expenses related to the hiring process and dividing by the total number of hires in that month. Besides the expenses incurred in the Recruiting department (i.e. salaries, travel expenses, recruiting software etc.) other expenses related to recruiting are agency fees and referral bonuses. These expenses are incurred in departments outside of Recruiting but hit their own GL accounts. These GL accounts will be what is included in Cost Per Hire, along with the total Recruiting Department expenses. This is calculated on a rolling three month average.
  target: The cap is less than $6,500.
  org: Recruiting
  public: false
  is_key: true
  health:
    level: unknown
    reasons:
      - tbd
  urls:
    - https://app.periscopedata.com/app/gitlab/482006/People-KPIs?widget=6946649&udv=841419

- name: Team member referrals
  base_path: /handbook/hiring/performance_indicators/
  definition: The percentage of Offer Accepts whose source was “Referral” in a given calendar month. This is calculated by taking the number of “Referral” Offer Accepts and dividing that by the total number of Offer Accepts for a given calendar month. “Referrals” are tracked in Greenhouse.
  target:
  org: Recruiting
  is_key: false
  public: true
  health:
    level: unknown
    reasons:
      - tbd
  urls:


- name: Talent Ops Average Time to Project Completion
  base_path: /handbook/hiring/performance_indicators/
  definition: On average, the time it takes to complete one Recruiting Team project.
  target:
  org: Recruiting
  is_key: false
  public: true
  health:
    level: unknown
    reasons:
      - tbd
  urls:


- name: Talent Ops Project Completion Rate
  base_path: /handbook/hiring/performance_indicators/
  definition: How many Recruiting Team projects have been completed versus projects that are currently open in a given period of time (e.g. per quarter)
  target:
  org: Recruiting
  is_key: false
  public: true
  health:
    level: unknown
    reasons:
      - tbd
  urls:
  sisense_data:
    chart: 6858936
    dashboard: 482006
    embed: v2
    border: off

- name: Talent Ops Service Desk Vendor Support Tickets
  base_path: /handbook/hiring/performance_indicators/
  definition: Analysis of the number of submitted internal support tickets, the number of resolved tickets, and the average time to resolution.
  target:
  org: Recruiting
  is_key: false
  public: true
  health:
    level: unknown
    reasons:
      - tbd
  urls:


- name: Sourced Offers
  base_path: /handbook/hiring/performance_indicators/
  definition: The number of Offers sourced by a Sourcer.
  target:
  org: Recruiting
  is_key: false
  public: true
  health:
    level: unknown
    reasons:
      - tbd
  urls:


- name: Sourced candidates moved to the Reference Check
  base_path: /handbook/hiring/performance_indicators/
  definition: The number of sourced candidates moved to the Reference Check stage.
  target:
  org: Recruiting
  is_key: false
  public: true
  health:
    level: unknown
    reasons:
      - tbd
  urls:


- name: Sourcer Hires Conversion Rate
  base_path: /handbook/hiring/performance_indicators/
  definition: The number of candidates submitted by Sourcer that were Hired.
  target:
  org: Recruiting
  is_key: false
  public: true
  health:
    level: unknown
    reasons:
      - tbd
  urls:


- name: Sourcer Offer Conversion rate
  base_path: /handbook/hiring/performance_indicators/
  definition: The number of candidates submitted by Sourcer that received an Offer.
  target:
  org: Recruiting
  is_key: false
  public: true
  health:
    level: unknown
    reasons:
      - tbd
  urls:


- name: Sourcer Interview Conversion rate
  base_path: /handbook/hiring/performance_indicators/
  definition: The number of candidates submitted by Sourcer that successfully passed the screening call.
  target:
  org: Recruiting
  is_key: false
  public: true
  health:
    level: unknown
    reasons:
      - tbd
  urls:


- name: Phone Screens Scheduled by a Sourcer
  base_path: /handbook/hiring/performance_indicators/
  definition: The number of candidates scheduled to speak with a Recruiter on a screening call.
  target:
  org: Recruiting
  is_key: false
  public: true
  health:
    level: unknown
    reasons:
      - tbd
  urls:


- name: Sourced Prospects Submitted
  base_path: /handbook/hiring/performance_indicators/
  definition: The number of Prospects submitted to a Recruiter and/or a Hiring Manager by one Sourcer.
  target:
  org: Recruiting
  is_key: false
  public: true
  health:
    level: unknown
    reasons:
      - tbd
  urls:


- name: Social Referrals
  base_path: /handbook/hiring/performance_indicators/
  definition: The percentage of Offer Accepts whose source was “SocialReferral” in a given calendar month. These candidates applied via links shared on social media sites (e.g. LinkedIn, Twitter, and the like). This is calculated by taking the number of “SocialReferral” Offer Accepts and dividing that by the total number of Offer Accepts for a given calendar month. “SocialReferrals” are tracked in Greenhouse.
  target:
  org: Recruiting
  is_key: false
  public: true
  health:
    level: unknown
    reasons:
      - tbd
  urls:


- name: Recruiting or Hiring Manager LinkedIn Seat
  base_path: /handbook/hiring/performance_indicators/
  definition: The percentage of the company that has a recruiting or hiring manager seat on LinkedIn. This is calculated by taking the total number of recruiting and hiring manager seats divided by total employees on a calendar month basis.
  target:
  org: Recruiting
  is_key: false
  public: true
  health:
    level: unknown
    reasons:
      - tbd
  urls:


- name: Candidate Time per Stage
  base_path: /handbook/hiring/performance_indicators/
  definition: Average number of days a Candidate spends per stages in the [interview plan](/handbook/hiring/recruiting-framework/coordinator/#step-14c-schedule-team-interviews).
  target:
  org: Recruiting
  is_key: false
  public: true
  health:
    level: unknown
    reasons:
      - tbd
  urls:


- name: Applied vs Sourced Candidates
  base_path: /handbook/hiring/performance_indicators/
  definition: This tracks the number of candidates who were Applied (Inbound) at the Hiring stage versus those that were Sourced (Outbound) each calendar month, by division. There is no target for this PI as GitLab wants a mixture of both Sourced- and Applied candidates. As we intentionally strengthen other channels (Sourcing, Referrals, SocialReferrals, etc), we expect the percentage of hires from inbound applications to decrease. To ensure that we don’t create an unintentional bias against inbound applicants, we are not assigning a target to this channel, but expect that it will account for less than 50% of our overall hires over time.
  target:
  org: Recruiting
  is_key: false
  public: true
  health:
    level: unknown
    reasons:
      - tbd
  urls:


- name: Active Users with a Recruiting or Hiring Manager LinkedIn Seat
  base_path: /handbook/hiring/performance_indicators/
  definition: The percentage of team members that have a *Recruiter* or *Hiring Manager* seat and at least 1 active day of use per month. This is calculated by taking the total number of team members with at least 1 active day of use and dividing it by the total number of team members that have a seat.
  target:
  org: Recruiting
  is_key: false
  public: true
  health:
    level: unknown
    reasons:
      - tbd
  urls:

