The engineering manager has 14 direct reports, a review deadline on Friday, and a GitHub org with eleven thousand pull requests in it. She knows who ships. She can't remember who unblocked whom in March. So she opens a blank review form and writes from memory, the same way she did last year.
That's the gap a GitHub integration is supposed to close. This post covers what it should actually do, what it shouldn't try to measure, and what to ask vendors before you sign anything. It's written for companies of 50 to 300 people where nobody owns HR ops and the review process lives in whatever the managers have time for.
What a GitHub Integration Should Do for Reviews
A useful integration treats GitHub as a source of evidence. It doesn't produce a score. The point is that when a manager sits down to write about an engineer, the pull requests, code reviews and activity from the whole period are already in front of them, next to the feedback and recognition from teammates.
Pull it into the same record as everything else. If GitHub activity sits in one tool and peer feedback sits in another, the manager has to stitch them together by hand, which is exactly the work they skip. The activity should land in the same place as feedback, goals and recognition.
Show work, not totals. A merged pull request with a title and a link tells a manager something. "47 PRs" tells them nothing. Look for an integration that surfaces the actual items, so the manager can click through and judge them.
Cover the whole review period. Recency bias is the whole problem. An integration that only shows the last 30 days rebuilds it.
Respect permissions. Not every manager should see every repo. The integration should only surface activity a person is already authorized to see.
What It Shouldn't Try to Measure
Commit counts, lines of code and PR volume are easy to collect and nearly useless as a measure of performance. The engineer who spent two weeks deleting a fragile subsystem has a negative line count and a better quarter than anyone. The one who reviewed everyone else's work and answered questions all day looks idle on a commit graph.
Be wary of any tool that turns GitHub data into a ranking or a single productivity number. Your engineers will notice within a week, and they'll start optimizing for the number. Activity data works as a prompt for a conversation. It doesn't settle one.
If you want a longer take on this, see how to use GitHub activity in engineering performance reviews.
Questions to Ask Before You Buy
What exactly gets pulled in? Pull requests authored, reviews given, issues, comments? Ask to see a real example, not a feature list.
Can the manager see the underlying items? A summary with no way to click into the source is hard to trust and easy to dispute.
Where does it show up? If managers have to log into a separate dashboard to see it, most won't. The best case is that it appears where they already write reviews.
Does it handle people who don't write much code? Designers, QA, data and engineering managers contribute in other ways. A tool built only around commits will undervalue all of them.
Does the integration feed the review draft? Collected activity is more useful if it can feed a first draft the manager edits. For where that should stop, read AI drafts performance reviews, a human still makes the call.
Where WorkStory Fits
WorkStory is adding a GitHub integration so pull requests and development activity can sit in the same performance record as feedback, recognition and goals, and feed into review drafts. Managers still write the review and own every rating. The activity gives them something specific to work from.
If you're comparing tools, how to choose review software for 100 people with no HR covers the wider checklist, and performance review software shows what else is in the platform. Using Jira too? See performance management software that integrates with Jira.
Want to see how it would work with your team? Book a demo.
FAQ
Can performance review software integrate with GitHub?
Yes. The useful ones pull pull requests, code reviews and related activity into the employee's performance record so managers can see real work alongside feedback. Check what's pulled in and whether managers can open the source items.
Should you measure engineers by commits or lines of code?
No. Both are easy to game and say little about the quality or impact of the work. Use GitHub activity as evidence for a conversation, not as a score.
Does GitHub data work for non-engineers on the team?
Only for people who work in GitHub. For everyone else you need feedback and goals from other sources, which is why the integration should sit alongside them rather than replace them.
Who should be able to see GitHub activity in a review?
The employee's manager and anyone else already authorized to see that person's performance data. A good integration respects repo and role permissions instead of exposing everything.
