Update Create stage productivity metrics guidance

## How we track productivity

In an effort to drive further clarity and align expectations on what is expected for each role, the Create stage has expanded on Engineering performance indicators such as the [MR Rate](/handbook/engineering/development/performance-indicators/#mr-rate) (above 12 per month) and will further specify expectations for each seniority level.

### Why?

During talent assessments, Engineering Managers take a holistic approach to evaluate team members' performance. They consider a diverse set of interconnected metrics across our ecosystem, ensuring fair assessment against the expectations for each [Job Level](https://docs.google.com/spreadsheets/d/1kcDb-A2uwchPtTNSJON65BdqS9P0KQmNz0fbNMZMt_M/edit?gid=819074618#gid=819074618). These metrics include:

- Merge requests merged

- Number of interviews participated in

- Mentoring activities

- Merge Request Impact

- Multiple Others

This comprehensive approach allows for a well-rounded evaluation of an engineer's contributions and growth. For more details, refer to our [Talent Assessments](/handbook/engineering/devops/create/talent-assessments/) page.

We believe it's important to communicate expectations clearly and transparently so we can all know what is expected and what to expect. This section looks to add clarity to this topic and promote higher awareness among the entire Create stage.

- Requests for Help and generic customer support

- Cross-team collaboration and leadership

- Other contributions

### What metrics do we focus?

This approach allows for a well-rounded evaluation of an engineer's contributions and growth. For more details, refer to our [Talent Assessments](/handbook/engineering/devops/create/talent-assessments/) page.

The goal of any team performance metric is to contribute partially to the understanding of a reality. This is because each metric might be imperfect on its own but alongside others can offer a more complete picture and better insights into the contributions given by the team and/or individual.

### What metrics do we focus on?

Currently we're setting clear monthly expectations for the following metrics:

Currently we set monthly expectations for the following metrics:

- **Merge Request Rate**:

  - When applied to a **group**: The numerator is the number of merge requests merged into a set of projects (see [notes below](#metrics_notes)).  The denominator is the number of people in the group.

  - When applied to a **group**: The numerator is the number of code reviews given to merge requests that merged into a set of projects (see [notes below](#metrics_notes)) in a given period (usually a month). The denominator is the number of people in the group.

  - When applied to an **individual**: It's the number of code reviews given to merge requests that merged into a set of projects (see [notes below](#metrics_notes)) in a given period (usually a month).

### How managers should use these metrics

Managers must:

- Treat MR and review rates as diagnostic signals, not hard productivity targets or quotas. Sustained deviations should trigger a conversation, not an automatic judgment.

- Always interpret metrics in context, including:

  - type of work (complex features, refactors, experiments, infra work, tech debt, incidents);

  - non-coding responsibilities (mentoring, interviewing, maintainership, Requests for Help issues, cross-team work);

  - temporary factors (onboarding, PTO, incidents, role changes).

- Avoid coaching or incentives that lead to:

  - splitting work unnaturally just to increase MR counts;

  - superficial or rushed reviews just to increase review counts;

  - deprioritizing complex, less-visible work (for example: migrations, reliability, enabling others).

- Regularly share and review an engineer's own data with them, explain what it does and does not mean, and invite their perspective on how it reflects their work.

- Proactively document team-specific contexts (for example, heavy incident load, legacy ownership, or large refactors) on the team's handbook page when those materially affect how metrics should be interpreted.

- Use the company-wide [Talent Assessment](/handbook/people-group/talent-assessment/) guidance as the single source of truth for performance decisions, with MR and review-related data as one of multiple inputs rather than the deciding factor.

#### Dashboards

- Merge Request Rate: [tableau dashboard](https://10az.online.tableau.com/#/site/gitlab/views/MTTMAllMRs/MTTMDashboard)

### Baseline targets for each job level

In the table below, we outline the baseline numbers for each of the metric related to the Seniority level:

In the table below, we outline the baseline numbers for each of the metrics related to the Seniority level. These numbers were derived from a collaboration with  Engineering Managers in the stage. As outlined above, they are treated as _only one input_ into understanding the team health and individual workload patterns.  **They are not treated as a complete measure of productivity or performance** but are set as a directional guide.

| Metric      | Associate | Intermediate | Senior | Staff |

|-------------|-----------|--------------|--------|-------|

| MR Rate     | 5         | 5            | 8      | 13    |

| Review Rate | 3         | 10           | 16     | 16    |

### How were the targets calculated?

Note: Numbers last updated around December 2024 leveraging historical data from team members of groups: Source Code Backend, Source Code Frontend, Code Review Backend, Code Review Frontend, Code Creation, Editor Extensions, Remote Development.

By analysing the existing teams' metrics and collaborating with all Engineering Managers in the stage, targets were defined to accurately reflect the expectations set during a normal calibration session for talent assessments at the [Performing](/handbook/people-group/talent-assessment/#performing) level of each role.

These baselines help surface trends and outliers that Engineering Managers can discuss with team members in context of work, responsibilities, and local team conditions, and always in combination with a wider set of signals (for example: incident response, architectural work, mentoring, interviewing, Requests for Help, and cross-team collaboration).

These targets were set having adherence to our CREDIT values in mind and are both ambitious and realistic.

In alignment with our CREDIT values, we regularly review and adjust these baselines to reduce bias, avoid perverse incentives (such as MR splitting or superficial reviews), and keep the focus on meaningful outcomes for customers, and sustainable ways of working.

### What do the targets mean?

We expect team members to be **on or above target for at least 6 out of the 12 months of a given year**.

As a rule of thumb, we expect most team members to be close to or above these baselines for **at least 6 out of the 12 months of a given year**, unless there is clear contextual reason (for example, extended incident response, major architectural work, significant mentoring or leadership responsibilities, or long-term leave).

These expectations are guidelines to prompt conversation and support, not strict quotas or automatic performance outcomes. They can be used as a calibration aid to assess how a team or individual is broadly operating, but any assessment is **always in conjunction with the full talent assessment framework**.

**For Individual Contributors,** these targets can provide a health status signal in alignment with expectations for the role and seniority they're in.