Two engineers on the same team. One has 212 commits this quarter. The other has 40. Ask the team who made the quarter work and most will name the second one, the person who reviewed half the pull requests, caught a nasty bug before release and spent a week helping a new hire get unstuck.
GitHub holds a detailed record of what your engineers did. Turning it into a fair review is the hard part. This guide covers what to look at, what to ignore, and how to bring it into a review conversation without turning it into a scorecard.
Why GitHub Data Is Tempting and Risky
It's objective, timestamped and already there. For a manager who has to review a dozen people from memory, that's attractive. The risk is that the easiest numbers to pull are the least meaningful ones. Commits, lines changed and PR counts reward volume, and volume is rarely what you want.
Used well, GitHub is a memory aid. It reminds you what someone worked on in month two that you've since forgotten. Used badly, it's a leaderboard that engineers learn to game.
What's Worth Looking At
Pull requests that mattered
Skip the count and pick the three to five pull requests that changed something: a hard migration, a risky feature, a fix for a recurring problem. Read the descriptions. They show how the engineer thinks about scope and communication, which a diff alone doesn't.
Code review given
Reviewing teammates' work is real work that never shows up in a commit graph. Look at who reviews thoroughly, who gives useful comments and who unblocks others quickly. This is often the clearest signal of a senior engineer.
Quality and follow-through
Did the work come back as bugs or reverts? Did the engineer own the follow-up? One reverted PR isn't a mark against anyone. A pattern across a quarter is worth a conversation.
Collaboration
Comments on others' pull requests, shared fixes and documentation updates show how someone works with a team. Pair this with peer feedback, since GitHub only shows the visible part.
What to Leave Out
Commit counts. Small commits and big commits both count as one. A tidy history can look quieter than a messy one.
Lines of code. Deleting code is often the best work an engineer does.
PR volume compared across people. Different teams ship different kinds of work. A platform engineer and a front-end engineer don't produce comparable graphs.
Anything on weekends or late nights. It measures hours, not contribution, and it's a fast way to lose good people.
How to Bring It Into the Review Conversation
Start with the person's own account. Ask what they're proudest of from the period, then bring two or three specific pull requests to the table as examples of work worth discussing. Say what you saw in the work, good and not so good, and ask what was going on at the time.
Keep GitHub as one input next to peer feedback, goals and recognition. If a pattern in the code doesn't match what teammates say about the same person, that gap is worth a conversation, and neither source is the final word.
Collecting this by hand across a whole team is slow, which is where tooling helps. Performance review software that integrates with GitHub covers what to look for. WorkStory is adding a GitHub integration so pull requests and activity sit in the same record as feedback and recognition, and can feed into review drafts the manager edits. See AI and performance reviews: a practical guide for how drafting from evidence works, and how to use Jira tickets in performance reviews if your team tracks work there too.
Want to see it with your own team? Book a demo.
FAQ
How do you evaluate a software engineer's performance using GitHub?
Look at the substance of a few important pull requests, the code review they give others, the quality and follow-through of their work, and how they collaborate. Combine it with peer feedback and goals instead of relying on activity counts.
Are commit counts a good measure of engineering performance?
No. They reward volume and are easy to game. A smaller number of well-scoped changes is often worth more than many small commits.
How do you review engineers who do a lot of code review?
Count it as real work. Review quality, speed and the help given to teammates are often the best signals of seniority, and none of it appears in a commit graph.
Should managers show engineers their GitHub data in a review?
Yes, as examples to discuss, not as a verdict. Share two or three specific pull requests, say what you saw, and ask for the engineer's side of the story.
