Measuring Engineering Productivity with GitLab MR Rate: Definition, Challenges, and Improvement Strategies
This article explains how GitLab uses the MR Rate metric to assess engineering productivity, outlines its definition, discusses the challenges of relying on a single metric, and presents four strategies—including improving iteration, setting KPIs, aligning OKRs, and empowering teams—to boost the MR Rate over time.
Rapidly growing software engineering organizations face the challenge of measuring how productivity scales over time. GitLab, which expanded its engineering staff from 100 to 280 engineers in a year and a half, needed reliable metrics to ensure continued delivery speed and value.
GitLab defined several key performance indicators (KPIs), among which the MR Rate —the number of merge requests (MRs) per team member per month—became a focal point for engineering management.
MR Rate is calculated as monthly team MR count ÷ monthly team size , including engineering managers because it reflects a team‑wide responsibility.
The metric was chosen to encourage smaller, faster‑reviewed MRs, accelerate feature delivery, and continuously improve the codebase, while also providing insight into organizational productivity trends.
However, relying solely on MR Rate presents challenges: it can be misleading if taken out of context, may incentivize quantity over quality, and requires careful analysis of factors such as new vs. existing teams, performance blockers, individual growth, community vs. team contributions, and operational constraints.
GitLab therefore splits the measurement into two dimensions—MR Rate by label and MR Rate by author—to capture both community and internal contributions.
Additional challenges include balancing team‑level and individual metrics, avoiding per‑person performance rankings, and handling the larger impact of each MR in smaller teams.
To improve MR Rate, GitLab employs four strategies: improving iteration (encouraging smaller, more frequent MRs), setting clear KPIs, aligning OKRs to raise KPI targets, and empowering teams to enhance efficiency.
The organization tracks MR Rate through dashboards, sets KPI targets (e.g., a target of 10 in September 2020), and uses the metric alongside others such as product MR types and Say‑Do ratios to gain a holistic view.
While MR Rate is not a perfect measure, GitLab continuously iterates on it to better understand and boost engineering productivity.
Dear readers, what metrics does your company use to measure engineering productivity?
Feel free to share your thoughts in the comments.
Continuous Delivery 2.0
Tech and case studies on organizational management, team management, and engineering efficiency
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.