Performance review week has a familiar shape: block off an evening, open GitHub, open Jira, and start reconstructing six months of someone's work from memory and search filters. By the third direct report, you're guessing at dates. By the fifth, you're just hoping nothing important got left out.
That reconstruction work is the actual problem — not a lack of opinions about how your reports are doing. Most EMs already have a reasonably accurate read on their team. What's missing is a fast, defensible way to back that read up with specifics, and a way to catch the things memory quietly drops: the engineer who took on an unglamorous migration nobody asked about, or the one whose review load quietly tripled after a teammate left.
Here's how that prep looks with a continuously-updated roster instead of a point-in-time export.
Start from the roster, not a blank doc
Instead of opening five different GitHub profiles, start from your direct-report roster: velocity, review load, and cycle time per engineer, already scoped to your team. The point isn't to reduce someone to three numbers — it's to have a starting point that doesn't require an hour of git log archaeology before you can even begin thinking about the actual conversation.
Two things to watch for here:
- Review load is easy to undercount from memory. If someone became the de facto reviewer for a tricky part of the codebase, that shows up as low "output" and high review time — exactly the pattern that gets misread as coasting if you're going off gut feel.
- Cycle time varies by the shape of the work, not just the person. A stretch of small, fast-moving tickets and a stretch of one gnarly refactor produce very different cycle time profiles for the same engineer. Pull up the underlying PRs before drawing a conclusion, not just the summary number.
Use trends, not snapshots
A single quarter's numbers rarely tell you much on their own — they tell you a lot next to the two quarters before it. Someone whose cycle time crept up gradually over a quarter reads very differently from someone whose cycle time spiked for two weeks and then recovered. The first might be worth a real conversation; the second might just be the sprint they were on call.
This is the actual value of having metrics update continuously instead of getting assembled once a quarter: you can see the shape of a trend, not just its endpoint.
Drill into the PRs before the meeting, not during it
Every headline number should be traceable back to the actual pull requests and issues behind it. Before a review, that means you can go from "cycle time went up in March" to the three specific PRs that were open the longest, and actually look at why — a genuinely hard problem, a slow review queue, a dependency on another team. That's the difference between a review conversation that starts with a number and one that starts with a question you can already partly answer.
Bring team and service context, not a ranking
The roster view exists next to team and service health on purpose — repo health, stuck CI, stalled PRs scoped to what your team owns. If a service had a rough quarter, that context belongs in the conversation before the individual numbers do. Nobody's cycle time looks great against a backdrop of flaky CI they didn't create.
This is also why calibration-ready comparisons exist as an opt-in, not a default: your director can bring your team's numbers into an org-wide view when it's calibration season, using the same definitions everyone else sees, but day to day, your roster is scoped to your own reports — not a leaderboard against teams you don't manage.
What this doesn't replace
None of this is meant to hand you a verdict. It's meant to save the hour of manual reconstruction so the hour you do spend goes into actually thinking about the conversation — what the data explains, what it doesn't, and what you still need to ask your report directly. The data gets you to the meeting with specifics instead of impressions. It doesn't run the meeting for you.
If you're doing this by hand today, connecting a repo and seeing your own team's roster populate is the fastest way to tell whether it actually saves the time it claims to.