Developers October 21, 2020

How we vastly improved our Pull Requests by starting measuring them 🔍

Luca Rossi @luca

Hi everyone! In the past year or so, at my startup we decided to invest real effort into our Pull Request process.

We defined objectives, started tracking metrics, and rallied the team around the process.

In just a few months, we experienced an incredible transformation. The team became vastly better at doing PRs, both in term of speed and quality. Also, people got more engaged by seeing metrics actually improving, that resulted in a virtuous cycle.

PRs merged without review dropped to almost zero PRs merged within 24h I wrote in detail about our experience in this post from 🌀 Refactoring, my newsletter. I described how we decided goals, how we measured them, which tools we used, and the actual results.

Let me know your thoughts! I would be happy to have a good conversation on this 😊

And if you like the article, consider also subscribing to the newsletter! 📮 I write weekly advice on making software and leading product and engineering teams.

  1. 2

    Thanks for sharing! I'm curious on what cadence you review these metrics and how they got incorporated into your workflows? Also did you encounter any pushback from engineers who felt the numbers were too invasive or not representative of their true contributions?

    1. 2

      We reviewed them once per Sprint (two weeks) in a dedicated meeting — we called it "Engineering Review" — together with other metrics. Participants were the CTO (me) and all the tech leads.

      We didn't encounter pushback but I think it can definitely happen! When we introduced these metrics, I had 1:1s with people where I explained that the goal was to find bottlenecks in the process and improve together as a team — like an elite sports team would. The goal was not to judge single people over these numbers.

      I think it's very important to have this kind of conversation, especially at the beginning when you move from something that is not tracked to something that becomes visible to everybody. Other jobs are used to having clear performance metrics (e.g. Sales) but Engineering is not, so the initial reaction can be very subjective.

      I think good management makes all the difference here

  2. 2

    @luca, nice! What did you use to track those metrics and create the graphic?

    (Gonna give your newsletter a read too...)

    1. 1

      Thank you! We used Pluralsight Flow (but Waydev is a very good, cheaper alternative) and Pull Reminders 😊

Recommended Posts