For engineering managers, PR lead time by team is most useful when it answers two questions: where is work moving slowly, and what changed between last week and this week? The practical approach is to compare the same metric across teams, then look for shifts in the parts of the flow that make up the total.
DeliveryCompass can help you view team-scoped PR lead time, but the method matters more than the tool. Start with a consistent baseline, compare two time windows, and review the trends with the people closest to the work.
This article covers engineering intelligence for GitHub PR delivery with a coaching-first approach that helps managers read patterns in GitHub PR metadata and guide team conversations.
What PR lead time should tell you by team
PR lead time is the time from PR creation to merge. By team, it helps you see whether one group is waiting longer than another, or whether lead time is changing inside a single team over time.
Use it to answer:
- Which team has the longest median lead time right now?
- Which team changed the most between two windows?
- Is the delay happening before review, during review, or before merge?
For a shared definition of the metric and related measures, see /docs/metrics and /docs/choosing-delivery-metrics.
Set up team-scoped views before you compare anything
Team comparisons work when the scope is clean. Map the right GitHub teams and repos first, then keep the same scope across both windows. Otherwise, you end up comparing different populations instead of different performance.
Use /docs/teams-and-repos to define which repositories belong to each team. If you need the full connection and access model, review /docs/how-it-works and /docs/setup.
- Keep team mappings stable for the period you are comparing.
- Make sure repos with shared ownership are assigned consistently.
- Check that the data reflects the same sync cadence in both windows.
Compare two windows instead of staring at one number
A single lead time number is a snapshot. A comparison shows movement. For example, compare the last 7 days with the 7 days before that, or the current month with the previous month.
When you compare windows, look for both direction and size of change:
- Median lead time up or down
- Change in spread, not just the center
- Whether the change is broad across teams or isolated to one
DeliveryCompass supports snapshots and trend views, which makes it easier to discuss changes with managers and team leads. See /docs/snapshots for the reporting model and /docs/dashboard for the overview layout.
Use the dashboard to find where the change is happening
The fastest way to move from a team-wide number to an action is to break the metric into the parts your managers can recognize. An overview dashboard with team KPIs and trend charts helps you find the team that moved, while a team performance table shows how the group compares with its peers.
Then drill into the team analytics chart grid to see whether the shift lines up with review latency, queueing, or a specific milestone in the PR flow.
- Use the overview for cross-team comparison.
- Use the team analytics grid for a deeper look.
- Use chart milestones to mark events you want to discuss later.
Read more in /docs/team-analytics and /docs/chart-milestones.
Turn lead time changes into coaching conversations
Once you see which team changed, the next step is to ask what changed in the work. Did review requests arrive later? Did the team pick up larger PRs? Did ownership shift? Did a specific repo become busier?
That is where staff meetings become useful. A weekly summary with attention callouts can help managers focus on the few items worth discussing, instead of reviewing every chart in detail.
- Highlight the team with the largest change.
- Note the window comparison you are using.
- Ask for the operational reason before suggesting a fix.
If you run a recurring review, this guide may help: /docs/guides/staff-meeting-metrics. For a broader operating view, see /docs/weekly-summary.
Use PR metadata to read the shape of the flow
PR lead time gets more useful when you understand what is inside it. Contributor coaching signals from GitHub PR metadata can help you spot patterns such as repeated late reviews, long idle periods, or PRs that sit open longer than expected.
That does not replace manager judgment. It simply helps you focus the conversation on a visible part of the workflow instead of a vague sense that delivery is slow.
For a closer look, see /docs/guides/code-review-responsiveness and /docs/guides/pr-flow-engineering-teams.
FAQ
What window should I compare PR lead time by team?
Most managers start with week-over-week or month-over-month comparisons. The right window is the one that matches your planning cadence and gives enough PR volume to avoid noise.
Should I use average or median lead time?
Median is usually easier to discuss because it is less affected by a few very long PRs. If you need to understand outliers, review the spread alongside the median.
How do I avoid misleading team comparisons?
Keep the team-to-repo mapping consistent, compare the same time windows, and make sure each team has enough data to support the comparison. See /docs/limitations for pilot and data considerations.
What if one team has very few PRs?
Low volume can make lead time swing from one window to the next. In that case, look at a longer period and pair the metric with qualitative context from the team.
How do I bring this into my existing staff meeting?
Use one team comparison, one change from the previous window, and one question for the team. That keeps the discussion focused and avoids turning the meeting into a report dump.
If you want to set up a team-scoped view and review it with your staff, start here: Get started in DeliveryCompass.