Complete PR's Like This To Be Successful

I just can't quit this one KPI. It's my go to, my everything, for measuring performance.

My experience working with countless software engineers and teams has taught me a simple Key Performance Indicator (KPI) that distills actionable information into a single table.

Number crunching and data analysis of engineering teams is one of my holy grails as an engineering manager. An astute manager uses data to drive action. Data absent action is useless. Action without data is inefficient.

Few, if any, standard metrics exist for analyzing an engineer or team. Ten engineers will give you ten different answers for how to measure their performance be it lines of code, production pushes, bugs created or kickback. (Lines of code is a terrible metric please don’t use that.)

I’ll beat you to the Goodhart’s Law reference - “When a measure becomes a target, it ceases to become a good measure.” which is to say that people respond to incentives. If the KPI is “tickets closed is good” then people find ways to close more tickets. The trade-off is they’ll find easy tickets to pump the numbers thereby disincentivizing tackling problems that are difficult and slower to solve be it they look bad for trying hard.

There are a few problems with all KPI’s.

First, they’re hard to track.

Second, they’re a pain to automate.

Third, they’re difficult to dashboard and share with others.

Fourth, they’re the most useful when observing organic behavior. (see Goodhart’s Law above)

Because of these reasons, managers often ignore KPI’s altogether or use the most generic KPI’s available through Jira, Azure DevOps or Power BI. The most rewarding problems are often the most difficult to solve.

There’s one KPI I just can’t quit. It’s tried and true. It’s easy to create, easy to understand and provides a detailed picture of the organization: pull requests completed per developer per week.

The Completed PR’s KPI generally aligns with our anecdotal assessment of engineers. In other words, completing multiple PR’s per week, every week, generally indicates a high performer. I’ve yet to see a developer closing 2-3 PR’s per week be a low performer. Merging a PR means they can deliver code changes in the project - squashing the bug or understanding requirements to add new functionality. It’s a beautifully simple and brutally honest assessment to see the engineers that are getting stuff done. As software engineers, our purpose on the job is to enact code change into the system.

Closing multiple PR’s per week also means that work is scoped to manageable chunks. Allowing one ticket to span multiple weeks or multiple sprints is a recipe for disaster.

As a developer - challenge yourself to track your Completed PR’s per week KPI. You will learn about yourself and your performance. After 6-12 months on your team you should know who is considered to be the existing top performers - compare your results across the group to see where you rank.

This KPI, for better or worse, only tells the truth. I just hope it doesn’t hurt.