If you manage multiple GitHub teams, the cleanest way to track PR lead time is to compare the same metric by team, over the same time window, with the same repo scope. That gives you a view that is useful for coaching without getting lost in one-off pull requests.
For most managers, the goal is not just to see a number. It is to answer a few practical questions: Which team’s PR lead time changed between two windows? Is the change steady or volatile? Are the longer waits happening before review, during review, or near merge?
DeliveryCompass is built around that workflow: engineering intelligence for GitHub PR delivery, scoped team metrics, trend charts, and drill-down views that make it easier to compare team performance without rebuilding reports in spreadsheets. If you are still deciding which delivery metric to anchor on, start with Choosing delivery metrics and Metrics.
What PR lead time should answer for a manager
PR lead time engineering managers usually want a measure that reflects how long work sits in the pull request phase before it is merged. Used well, it helps you spot where a team is waiting, not just where it is busy.
A useful team-level readout should help you compare:
- one team against its own previous window
- one team against another team with similar work
- repo-scoped performance where team ownership differs
That is why the setup matters. If team and repo scope are off, the comparison becomes noisy. The Teams and repos guide explains how scoped KPIs keep the metric tied to actual ownership.
Set the team scope before you compare windows
Before you look at trend changes, make sure each team is mapped to the right repos. A team metric that spans unrelated repositories usually hides the real pattern you are trying to see.
A simple approach is:
- confirm team ownership in Setup
- map teams and repos with Teams and repos
- verify the metric definition in Metrics
- check whether the current view matches what you expect in Dashboard
Once scope is stable, the same team can be compared across weekly or monthly windows with much less debate about data quality.
Compare two windows instead of staring at one number
One of the most useful habits for PR lead time is to compare two windows side by side. For example: this week vs. last week, or this month vs. the prior month. That gives you an observed change, not a guess.
When you compare windows, look for patterns like these:
- median lead time moved up while the tail stayed flat
- lead time improved, but only for one repo in the team’s scope
- one team’s trend is stable while another team shows spikes around release days
If the change appears only in a single window, treat it as a signal to inspect the underlying PRs, not as a lasting trend. The Snapshots view is useful when you want a fixed reference point for a conversation.
Use trend charts and drill-downs to explain the change
Managers usually do not need more charts. They need the right chart in the right moment. A team trend chart shows whether PR lead time is drifting, improving, or bouncing around. A drill-down shows which pull requests contribute to that pattern.
The Team analytics view is where this becomes practical. You can move from the team trend to the chart details, then to the specific PRs behind the shift. If you want a consistent review rhythm, Chart milestones can help you anchor the conversation around notable changes instead of raw noise.
For example, a manager might notice that Team A’s PR lead time rose in the last two weeks while Team B stayed level. That is enough to ask a better follow-up question: Did review start later, did approval slow down, or did the team take on more complex changes?
Look for patterns in the workflow, not just the average
Team averages are helpful, but they do not tell the full story. A team can have a reasonable median and still struggle with a long tail of PRs that wait too long to move.
When you review PR lead time by team, check for:
- long gaps before the first review
- large PRs that sit open across multiple days
- handoffs between teams or repos
- bursts around meetings, releases, or on-call load
Those patterns are easier to discuss when you have a weekly view. The Weekly summary can help you prepare for staff meetings, especially when you want to call out where attention is needed and where the trend is holding steady.
Turn the metric into a coaching conversation
PR lead time should support a team conversation, not a blame exercise. For engineering managers, the best use is to ask what is slowing the handoff from opened PR to merge and what part of the workflow the team can improve together.
Useful coaching prompts include:
- Which PRs took the longest, and why?
- Do we see delays before review or after review?
- Are we comparing the right team and repo scope?
- Did the latest window include a known event, such as holidays or release freeze?
If you want to connect the trend to staff meeting planning, see Staff meeting metrics. If you are also reviewing PR behavior in more detail, Code review responsiveness is a useful companion topic.
FAQ
What is the right window for tracking PR lead time by team?
Most managers start with weekly or monthly windows. Weekly is better for staff meeting rhythms and quick course correction. Monthly is better when you need a steadier signal and the team ships at a slower pace.
Should I compare teams directly or compare each team to itself?
Start with each team against its own prior window. That makes the change easier to interpret. Direct team-to-team comparison is useful only when the repo scope, work type, and team size are reasonably similar.
How do I know if a PR lead time change is meaningful?
Look for repeated movement across consecutive windows, not just a single spike. A one-week change can reflect a release, holiday, or unusual incident. A trend over multiple windows is usually more useful for coaching.
What should I check if one team’s lead time looks much worse than the others?
First confirm the team and repo mapping, then inspect the drill-down for long-waiting PRs, large changes, and review delays. If the scope is wrong, the comparison will not be reliable.
Where should I start if I am new to delivery metrics on GitHub?
Start with GitHub metrics for managers and PR flow for engineering teams. Those guides help you frame the metric before you build a regular review habit.
If you want to set up scoped team views and compare PR lead time in a single place, get started at /app/onboarding.
For scope boundaries and metric definitions, review /docs/limitations before you compare teams.