This is what the performance of a top 5% developer looks like.
This Lead Engineer delivered 3.25x the output of a median engineer, making up 61% of the team's total output.
Beyond his exceptional coding skills, what drives his productivity?
Reviewing this Java team's time allocation showed that the Senior Engineer spent 65% of his time on management & support, allowing the Lead Engineer to dedicate 87% of his time to coding.
This highlights the risk of misinterpreting developer productivity data.
Without understanding the team dynamics, one might wrongly question the Senior's lower output compared to the Lead's exceptional performance.
In addition to understanding the context behind the data, it’s also important to use the right metrics to measure developer productivity.
Traditional metrics (Lines of Code, # of Commits/# of PRs, Story Points, and even DORA) can provide an inaccurate picture. They fall short in measuring developer productivity: they don’t analyze the actual source code, can encourage counterproductive behavior, and can be easily manipulated.
How do we measure developer productivity?
Our algorithm measures developer productivity by analyzing the functionality of code changes in Git commits. It considers 30+ codebase dimensions and has been calibrated across millions of files in 10+ languages. This approach quantifies each commit's impact and combines it with Git metadata to measure individual and team productivity.
About Our Mission
We are conducting research at Stanford focused on quantifying software engineering productivity.
Our objective is to enable engineering teams to base decisions on factual data, rather than on gut feelings and internal politics.
Our research participants use our algorithm to make decisions about their team’s performance, outsourcing, work methods (home vs office), etc.
