For engineering
Make the invisible work visible without watching anybody.
Engineering is the function most likely to reject this outright, and for good reasons. Here is what has to be true for it not to be.
Get this wrong and it backfires
The trap: merges drown out reviews
Rank on merged pull requests and reviewing becomes invisible work that costs you position. The people who do most of it are often the ones least visible on any board already, and a leaderboard that ignores it tells them exactly what the organisation counts.
Run a reviewers board where approvals cannot be drowned out by merge volume, or weight the two together so neither dominates. And keep bots off it: nobody should be competing with the release automation, and on a busy repository the bot wins every category by an order of magnitude.
The second trap is subtler and follows immediately: once reviews count, review quality drops. An approval takes eleven seconds if nobody is looking. Pair approvals with something that gets worse when reviews get shallow, such as change failure rate, or accept that the reviewers board is a visibility tool rather than a performance one, and say so out loud when you turn it on.
What a reward looks like
What has to be true for engineers to accept it
Team-level by default, with individual ranking a decision somebody makes rather than the state it arrives in. The visibility setting enforced where the data is, so it holds for an export as well as a screen. And every setting change written to a log that cannot be edited afterwards.
Beyond that: measure what was already public. A merged pull request is visible to everyone with repository access, so counting it reveals nothing new. The moment a tool starts inferring focus time from calendar gaps it has become something else, and engineers will correctly treat it as such.
What you get without configuring anything
Installing the GitHub App loads the last ninety days, so the boards have history before anyone logs in. Deploys are credited to the change they shipped rather than to the machine account that triggered them, and bots are ignored unless you say otherwise. Linking somebody’s account later re-attributes the work it already sent, so a late joiner does not start from zero.
Out of the box you get a team board, a reviewers board and an all-time board. The reviewers one is the one worth keeping: it is the only place where the person who does forty approvals a month and ships three changes appears at the top of anything.
Beyond what GitHub knows
The events that matter most to an engineering organisation are often the ones no repository records. An incident handled at 2am. A migration finished. An on-call week nobody had to be rescued from. A runbook written before it was needed.
Send those from wherever they live, such as your incident tool, your CI, or a script somebody runs on Fridays, and they rank exactly like a merge does. That is usually where the interesting rewards end up, because they are the work the organisation most wants and least sees.
Questions
The ones that come up
Will engineers hate this?
They will hate a ranked list of names with no context, and they would be right to. Team-level boards with individual visibility off by decision answer the leadership question without exposing anybody, and that is the configuration to start in.
Does it measure lines of code or commits?
No, and you should not either. Both reward volume, and both are trivially gamed by anyone who notices they are counted.
How do reviewers get credit?
Approvals are a first-class metric, and there is a board template that ranks on them alone precisely so review work is not drowned out by merge volume.
Rank what this team actually does.
Free for your first 50 people. No card, no sales call.