ยท 7 min read
Reading six months of pull requests: what it tells you and what it does not.
Six months of pull requests is the most honest record an engineering organisation keeps, but only two things in it are worth reading: how long a change waits for review, and how many people can touch each part of the system. Those two signals, review latency and ownership spread, will tell you where delivery is stuck and where the business is one resignation away from trouble. Commit counts, lines changed, and who closed the most pull requests tell you almost nothing, and ranking people by them makes the real problems harder to see.
What you have probably been handed
When I start a diagnosis, someone usually offers me a dashboard first. It counts commits per engineer, plots lines added and removed, and ranks people by pull requests merged. It looks like insight because it is made of real events. It is not insight. It measures how much text moved, not whether the right change was made, and it quietly rewards the behaviour you least want: large batches, noisy refactors, and activity for its own sake. I have watched a team whose busiest name on that dashboard was the one person most of the others were working around.
The pull request history underneath that dashboard is a different thing, and it is genuinely useful. Every change the team made is there, with a timestamp for when it was opened, who reviewed it, how long it waited, and what it touched. Read directly, in the right order, it answers two questions that matter more than any productivity number: why does delivery feel slow, and where would it hurt most if one person left. The dashboard hides both of those behind a leaderboard.
What the pull requests actually tell you
The first real signal is review latency: the time between a change being ready and being merged. This is where delivery leaks without anyone deciding it should. A team can write code fast and still ship slowly because every change sits for three days waiting on a review, and that wait never appears on a roadmap or in a standup. When latency is high and concentrated on one or two reviewers, you have found a bottleneck that no amount of hiring will fix, because the constraint is a person who has become the only gate, not a shortage of hands. Sometimes it is trust: senior people do not believe the rest can be allowed to merge. Sometimes it is simply overload. The history tells you which by showing you whose queue the changes are waiting in.
The second real signal is ownership spread: how many distinct people author and review changes in each part of the system. Point the history at directories rather than people and the key-person risk draws itself. One service touched by one name for six months is a bus factor of one, written down in advance of the day that person hands in notice. The same pattern on the review side is quieter and just as dangerous: an area where every change is approved by the same reviewer has a single point of judgement, and when that person leaves, nobody left can say whether a change to it is safe. This is the same ownership vacuum I describe in one lead developer, two agencies, no CTO, visible here as data instead of as a feeling.
What to read, in order
A useful reading takes an afternoon and goes in this sequence.
- Latency distribution, not the average. Look at the time from ready-for-review to merge across all pull requests, then look at the slowest tenth. The average hides the problem; the tail is the problem. A median of a few hours with a long tail of changes that waited a week tells you some work is first-class and some is quietly stuck, and you want to know which kind.
- Who the reviews wait on. Group the slow pull requests by who eventually reviewed them. If one or two names sit under most of the wait, the constraint is reviewer capacity, not author capacity. That is a different fix: spread the mandate to approve, do not hire another author to wait in the same queue.
- Ownership by area. Map authors and reviewers to directories or services. Flag anything touched or approved by a single person over the whole window. Each flag is a named risk to raise now, while the person is still there to write down what only they know.
- Pull request size and timing. A history of large changes merged in a rush at the end of each sprint is a team batching work because integrating often feels unsafe. Small, steady changes are a team that trusts its pipeline. The shape of the changes tells you how the team actually feels about its own system.
- Rework after merge. Changes that are reverted or immediately patched point at a place where the team cannot tell whether a change is correct before it ships. That is usually a testing or an ownership gap, and it is worth more attention than any individual's volume.
None of these steps ranks a person. Each one names a place in the system where delivery is slow, knowledge is thin, or confidence is missing, and each one turns into a specific thing to change next week.
What to ignore, and why it misleads
Commit counts measure a habit, not output. A team that squashes every branch into one commit and a team that merges forty tiny commits look wildly different on this number while doing identical work. Lines changed are worse, because they actively reward the wrong things: generated code, a formatting sweep, and a copy-paste all score high, while the one-line change that fixes the incident scores near zero. Pull requests merged per person is a leaderboard, and the moment people know you are counting it, it stops measuring anything except who is willing to split their work to game it. The engineers quietly holding the system together, reviewing carefully, mentoring, keeping the risky parts stable, score modestly on all three and are usually the ones you can least afford to lose. Rank by these numbers and you will aim your attention at exactly the wrong people.
When the pull requests are not the place to look
The history is one input, not a verdict. It is blind to everything that never became a pull request: the good idea killed in a meeting, the production incident fixed by hand at midnight, the architecture decided in a direct message and never written down. It cannot tell you whether the work was the right work, whether the design is sound, or whether an individual is good at the job, and anyone who tells you it can is selling you the dashboard again. If the question is whether the team is building the right thing, the pull requests will not answer it. If the question is whether a specific person should stay, do not try to settle it from their commit history; that is a conversation, and the data will only give you false confidence. Read the pull requests to find where change is slow and where ownership is thin, then cross-check what you found against incidents, delivery, and the people themselves. That triangulation, not any single source, is what a structured diagnosis is for, and it is the same discipline a buyer's technical team applies when it reads a target's repositories during technical due diligence.
Frequently asked
What can you learn from reading a team's pull request history?
Two things, reliably. First, review latency: how long a change waits between being ready and being merged, and whether that wait sits on one or two reviewers. A slow, concentrated review queue is the single clearest sign that the team is bottlenecked on a person rather than on the work. Second, ownership spread: how many distinct people author and review changes in each part of the system. If one area is touched by one name, that is key-person risk you can see in the data before anyone tells you about it. Everything else in the history is context, not signal.
Are commit counts and lines of code a good measure of engineering productivity?
No, and reading them as one makes things worse. Commit counts depend on squash and rebase habits, not output; lines changed reward generated code, deletions, and noisy refactors over the hard, small change that fixes the actual problem. Both are trivial to move on purpose once people know you are watching them, and the engineers who optimise for them are rarely the ones holding the system together. Use the history to find where change is slow and where ownership is thin, not to rank people by volume.
What is review latency and why does it matter?
Review latency is the time between a pull request being ready for review and being merged. It matters because it is where delivery quietly leaks: a team that writes code quickly but waits days for review ships slowly, and the wait is usually invisible on a roadmap. High latency concentrated on one or two reviewers points to a bottleneck, a trust problem, or a senior person who has become the only gate. Measuring it tells you where to intervene far more precisely than asking the team why releases feel slow.
What does pull request history not tell you?
It does not tell you whether the work was the right work, whether the architecture is sound, or whether an individual is good at the job. The history records how changes moved through the system, not whether they should have been made. It is blind to everything that never became a pull request: the meeting that killed a good idea, the production incident handled by hand, the design decision made in a direct message. Read it as one input into a diagnosis, cross-checked against incidents and the people, never as a verdict on a person or a team on its own.
Written from patterns I've seen across engagements. If any of it sounds too specific to be general, that's why.