If you manage multiple engineering teams, the useful question is not just “What is our PR lead time?” It is “Which team’s PR lead time changed, by how much, and what should we look at next?” A team-level view turns a single average into something you can actually use in weekly reviews, planning, and coaching.
This guide walks through a simple way to track PR lead time engineering managers care about: define the metric, scope it by team, compare two time windows, and read the trend without overreacting to a one-week spike.
What PR lead time tells you at the team level
PR lead time is the time from pull request open to merge. At the team level, it helps you see whether a team is moving changes through review and integration steadily or getting slowed down by review wait, rework, or queueing.
For managers, the value is in comparing teams consistently. A team with a lower median lead time is not automatically “better,” but a change in the same team’s trend is usually worth a closer look.
- Shorter lead time can indicate smoother handoffs and quicker review decisions.
- Longer lead time can signal blocked reviews, large PRs, unclear ownership, or merge bottlenecks.
- Wide variation often means the average is hiding very different PR experiences.
If you want a deeper definition before you compare teams, start with /docs/metrics and /docs/choosing-delivery-metrics.
Use a team scope, not a repo guess
One common mistake is assigning PRs to teams only by repository and assuming the result is accurate enough. In practice, managers get better team-level numbers when the metric is scoped from an explicit team-to-repo mapping.
That matters when:
- multiple teams work in the same repo
- a team spans several repos
- shared platform work mixes with product work
A clean team scope helps you compare like with like. If you are setting up scopes, see /docs/teams-and-repos. If you are just getting started, the broader setup path is documented at /docs/setup.
Compare two windows instead of staring at one number
A single window gives you a snapshot. Two windows give you a change story. For example, compare the last 7 days with the previous 7 days, or this month with last month. That makes the review conversation much more concrete.
Look for three things in each team:
- Direction — is lead time up or down?
- Magnitude — is the change small or meaningful?
- Consistency — did every day move, or was it a few outliers?
If a team’s median lead time moved from 3.2 days to 4.1 days, that is a signal. If another team moved from 5.8 days to 5.6 days, that may simply be noise. The point is to report the change, then decide whether it needs follow-up.
For a practical view of recent changes, the weekly summary can be useful for staff meetings: /docs/weekly-summary.
Read team trends with charts, not just tables
Tables are good for ranking. Charts are better for understanding whether a change is persistent. A dashboard that combines team KPI tables with trend charts helps you answer both questions quickly.
When you review charts, ask:
- Did the team’s lead time move gradually or abruptly?
- Did the change happen alongside a spike in PR volume?
- Is the pattern stable enough to discuss with the team?
If you use a chart grid with drill-downs, you can move from the team summary into the PR details that sit behind the trend. That makes it easier to separate a real process shift from a short-lived outlier. See /docs/dashboard and /docs/team-analytics.
Use supporting signals before you coach
PR lead time is a manager-level metric, but it should not be the only thing you look at before coaching a team. A longer lead time can come from larger PRs, slower review responsiveness, or extra iteration after review. Those are different problems.
Before you bring the topic to a team meeting, check for supporting signals such as:
- review wait time and code review responsiveness
- PR size and complexity
- merge patterns across the week
- recent changes in team load or staffing
For a related read on review timing, see /docs/guides/code-review-responsiveness. For staff meeting framing, /docs/guides/staff-meeting-metrics is a useful companion.
What to report between two windows
When you share team metrics, keep the format consistent. A simple report should say what changed, by how much, and what you want to inspect next.
A good update sounds like this:
- Team A PR lead time moved from 2.8 days to 3.6 days over the last two weeks.
- Team B stayed steady at around 4 days, with less day-to-day variation.
- Team C improved, but most of the change came from smaller PRs rather than fewer reviews.
That kind of report is more actionable than saying a team is “slow” or “fast.” It also keeps the conversation focused on the observed change, not on assumptions about why it happened.
If you are documenting trends over time, snapshots can help preserve the comparison: /docs/snapshots.
FAQ
What is the best time window for PR lead time by team?
For most managers, weekly or biweekly comparisons work well. Weekly windows are good for staff meetings and quick trend checks. Biweekly or monthly windows help reduce noise when teams ship unevenly. If your teams have very low PR volume, a longer window can help you avoid drawing conclusions from too few pull requests. The best choice is the shortest window that still gives you a stable read on team changes.
Should I use average or median PR lead time?
Median is usually easier to interpret because it is less affected by a few unusually large or blocked PRs. If you need more context, pair it with a trend chart and a look at the distribution or outliers. Average can still be useful as a supporting view, especially when you want to see the effect of a small number of very long PRs on the overall team picture. Many managers review both, then use the median for the main conversation.
How do I avoid misleading comparisons between teams?
Use a consistent team-to-repo mapping, compare similar time windows, and note changes in workload or staffing. A team with many small PRs should not be judged against a team doing fewer but much larger changes without context. It also helps to compare the same team against itself over time before comparing teams to each other. That keeps the conversation grounded in trends, not in assumptions about how two teams should behave.
What should I review before sharing PR lead time in a staff meeting?
Check the direction of change, the size of the change, and any supporting signals like review wait time, PR volume, or unusually large PRs. Then keep the conversation on patterns and next steps rather than one-off incidents. If the change is small, call it out as a watch item instead of a problem. If the trend is clear, bring one or two likely contributing factors so the team discussion stays practical and focused.
Where can I check product limits and pilot guidance?
Review the current limits and pilot notes here: /docs/limitations#pilot. If you are still validating the workflow, the product tour at /docs/product-tour can help. The limits page is also the best place to confirm what is included in GitHub PR metadata and what is not, so you can set expectations correctly before you start comparing teams.
Bring team-level PR lead time into your weekly rhythm
If you want a consistent way to track PR lead time by team, start with a scoped team view, compare two windows, and review the trend before you coach. That gives you a practical read on where delivery is changing and which team needs attention first.
DeliveryCompass supports engineering intelligence for GitHub PR delivery by helping you review GitHub PR metadata in a team context, so you can coach with evidence and consistency rather than guesswork. If you are ready to set up team-level delivery reporting in GitHub, you can get started here: /app/onboarding.