Engineering managers track PR lead time by team to see where work slows down, which teams are improving, and what to bring into weekly reviews. The useful version is scoped, repeatable, and tied to GitHub PR metadata—not a one-off spreadsheet export.
DeliveryCompass supports engineering intelligence for GitHub PR delivery with team-scoped PR lead time KPIs, trend charts, a team performance table, and drill-downs so you can compare teams without losing context. If you want the metric to work in staff meetings, set it up with clear team-to-repo mapping and review the same definition every week. See /docs/guides/pr-lead-time-teams for the metric approach, and /docs/teams-and-repos for how scoped KPIs are assigned.
What PR lead time tells you when you scope it by team
PR lead time shows how long pull requests take from opened to merged. By team, it helps answer practical questions: which team ships quickly, which team has review bottlenecks, and whether a recent process change is actually helping.
The main value is not the raw number alone. It is the ability to compare one team’s current lead time with its own past trend and with other teams that do similar work. That makes it easier to separate normal variation from a real delivery issue.
- Use it to spot drift, not to rank people.
- Use it with team context, not across unrelated work.
- Use trends and milestones to review changes over time.
For a broader framing on delivery metrics, see /docs/choosing-delivery-metrics and /docs/metrics.
Set up team-scoped PR lead time so comparisons hold up
To track PR lead time by team, each repo needs a clear team mapping. That way, the metric reflects the work owned by a team instead of mixing unrelated repos together.
Start by mapping teams and repos, then confirm the data source is your GitHub organization. DeliveryCompass uses a read-only GitHub App install and OAuth, with a daily sync, so the setup stays lightweight while keeping the metric current.
- Define the teams you want to report on.
- Map the repos each team owns or meaningfully contributes to.
- Check that the PR lead time definition matches how your group works.
- Confirm the first data sync and review the baseline.
If you are still deciding how the data is organized, review /docs/how-it-works and /docs/setup. If team scoping is the key question, /docs/teams-and-repos is the place to start.
Use the dashboard to compare teams without spreadsheet work
The overview dashboard is the fastest way to track PR lead time engineering managers care about. It brings together team KPIs, trend charts, and a team performance table in one place, so you can move from high-level status to a specific team quickly.
In practice, that means you can scan for teams with rising lead time, then open the relevant chart and check whether the change is broad or isolated to a few repos. The team analytics chart grid adds another layer, with drill-down views that make the trend easier to explain.
- Review the overview dashboard for team-level status.
- Use the team performance table to compare teams side by side.
- Open drill-down charts when you need the reason behind a change.
See /docs/dashboard, /docs/team-analytics, and /docs/chart-milestones for how these views work together.
Read trends the way an engineering manager actually uses them
A single PR lead time number is easy to overread. A trend is more useful because it shows whether the team is getting faster, slower, or flat after a change in review habits, release timing, or repo ownership.
Look for the shape of the trend first. Is the line stable with one spike, or is it climbing for several weeks? Then check whether the chart milestone lines line up with a process change, a staffing change, or a new repo in scope.
- Stable trend: usually means the team’s flow is predictable.
- Upward trend: worth checking review delays, handoffs, or batch size.
- Downward trend: confirm it is sustained before treating it as a win.
If you review these charts in a staff meeting, the weekly summary can surface the teams that need attention. See /docs/weekly-summary and /docs/guides/staff-meeting-metrics.
Use coaching signals without turning the metric into a blame tool
PR lead time is most useful when it leads to a coaching conversation, not a ranking exercise. Contributor coaching signals from GitHub PR metadata can help you understand what is happening inside the lead time, such as slow review starts or long gaps before merge.
That gives managers a better next step. Instead of asking why a team is “slow,” you can ask whether the issue is review responsiveness, PR size, or coordination across repos.
- Use the team view to identify where the delay appears.
- Use PR metadata signals to guide the question.
- Keep the conversation focused on process and flow.
For related reading, see /docs/guides/code-review-responsiveness and /docs/guides/pr-flow-engineering-teams.
Make PR lead time part of a weekly operating rhythm
Engineering managers get the most value from PR lead time when they review it on a fixed cadence. Weekly is usually enough to spot movement without reacting to every short-term wobble.
A simple weekly flow works well:
- Check the overview dashboard for the current team picture.
- Open the weekly summary and look for attention callouts.
- Review the team with the biggest change in lead time.
- Use a chart drill-down or milestone marker to explain the shift.
- Capture one follow-up action for the team owner.
If you want a guide built around this workflow, see /docs/guides/github-metrics-for-managers and the limitations note at /docs/limitations#pilot.
FAQ
What is the PR lead time definition for team reporting?
Use one definition consistently across teams, then keep the scope aligned to repo ownership. Consistency matters more than trying to create a different definition for every team.
Should I compare PR lead time across all engineering teams?
Compare teams when the work type is similar enough to make the result meaningful. Otherwise, compare each team against its own trend and recent baseline.
How often should managers review PR lead time?
Weekly is a practical cadence for most teams. It is frequent enough to catch a problem early and slow enough to avoid chasing noise.
What should I do if a team’s lead time spikes?
Check whether the spike came from review delay, a larger-than-usual change, or a repo mapping issue. Then use the drill-down view to confirm the pattern before changing anything.
Does PR lead time work without a lot of manual tracking?
Yes. With GitHub connected and team-to-repo mapping in place, the dashboard and weekly summary remove the need to update spreadsheets by hand.
Ready to track PR lead time by team in a way your staff meetings can actually use? Start your setup in DeliveryCompass.