If you want a staff meeting that helps managers make decisions, keep the metric set small: show delivery flow, review bottlenecks, and bring one or two coaching signals tied to current work. The strongest engineering staff meeting metrics are the ones your team can act on the same week.
A practical default is: one trend for lead time, one for review responsiveness, one scoped team KPI view, and one weekly attention callout. Use the meeting to ask what changed, where the work is waiting, and which team needs a follow-up. If you need a refresher on metric definitions, start with /docs/metrics and /docs/choosing-delivery-metrics.
What should be in the meeting by default?
Start with metrics that answer three questions: Are we shipping? Where is flow slowing down? Who needs support?
- Lead time trend for pull requests or merged work, so you can see whether delivery is getting faster or slower.
- Review responsiveness, because waiting on review is often the easiest bottleneck to fix.
- Team-scoped KPI view, so each team sees its own numbers instead of a blended org average.
- Weekly attention callouts, so the meeting surfaces what changed since last week.
For most staff meetings, that is enough. If a metric does not change a decision, move it out of the meeting and into a readout. The goal is not coverage; it is focus. For team scoping, see /docs/teams-and-repos.
Which delivery metrics are most useful in a staff meeting?
The most useful delivery metrics are the ones that show the path from opened PR to merged work. In practice, that usually means:
- PR lead time as the main trend line.
- Time in review or review wait time to expose bottlenecks.
- Merge volume only when you need a sanity check on throughput.
- Milestone progress when you are managing work against a shared target.
These metrics help the group discuss process, not individual performance. If you need a staff-meeting-oriented framing for delivery, the guide at /docs/guides/staff-meeting-metrics is a good companion. For a broader view of delivery flow, /docs/guides/pr-flow-engineering-teams is also useful.
What should you avoid putting on the agenda?
A staff meeting is the wrong place for a long dashboard tour. Avoid metrics that are hard to act on in the room or that invite side conversations with no decision.
- Too many charts: if you need ten minutes just to explain the view, it is too much.
- Raw counts without context: a higher PR count is not automatically better.
- Org-wide averages only: they hide team-level variation.
- Vanity metrics: anything that sounds impressive but does not change behavior.
Instead, keep the meeting centered on changes since last week. One chart grid can help when you need to compare teams quickly, but the discussion should always end in a next step. For a structured view of charts and drill-downs, see /docs/team-analytics and /docs/chart-milestones.
How many metrics is the right number?
For most engineering staff meetings, three to five metrics is the right range. That gives you enough signal to notice trends without turning the meeting into a reporting session.
A simple structure is:
- One headline delivery metric, usually PR lead time.
- One bottleneck metric, often review responsiveness.
- One scoped team view, to compare teams without flattening them.
- One or two attention callouts, to flag unusual movement.
If your meeting is larger or spans multiple teams, use a summary first and reserve drill-down for the teams that need follow-up. The /docs/weekly-summary page is helpful when you want a repeatable weekly readout instead of ad hoc slides.
How do you turn metrics into a good staff meeting discussion?
The metric matters less than the question it prompts. A good staff meeting discussion usually follows the same pattern:
- State the trend.
- Ask what changed.
- Identify where work is waiting.
- Decide whether a team needs support or a process adjustment.
For example, if review time has risen, the discussion should focus on queueing, reviewer load, or handoff timing. If a team’s lead time improved, ask which change helped and whether it should be repeated elsewhere. This is where weekly callouts are useful: they direct attention to the few items worth discussing. For more on what gets surfaced in the weekly view, see /docs/weekly-summary.
How should staff meetings differ by team or org size?
The bigger the org, the more important scoping becomes. A small group can discuss a single shared dashboard, but a multi-team staff meeting needs a way to separate one team’s bottleneck from another team’s healthy trend.
That is why scoped KPIs matter. A manager should be able to see the same metric family across teams, then drill into the team that needs attention. If a team is new, if its work is repo-specific, or if it owns a unique release path, the meeting should reflect that reality instead of averaging it away. The setup details are covered in /docs/teams-and-repos and the overview flow at /docs/dashboard.
FAQ
What is the single metric to start with for an engineering staff meeting?
PR lead time is usually the starting point because it reflects the full delivery path and gives the room a shared baseline. Pair it with one bottleneck metric so the meeting can move from observation to action.
Should we include individual contributor metrics in staff meetings?
Only if the metric is being used to support coaching and not to rank people. Staff meetings work best when the focus stays on team flow, blockers, and process changes rather than individual scorekeeping.
Do weekly summaries replace staff meeting metrics?
No. Weekly summaries are a good input, but the meeting still needs a short list of metrics and a conversation about what changed. The summary helps you arrive prepared; the meeting turns that information into decisions.
How do we keep the meeting from becoming a dashboard review?
Limit the agenda to the metrics that changed, then ask what the team should do next. If a chart does not lead to a decision, it does not belong in the live discussion.
Where can I read more about the metric definitions used in GitHub delivery reporting?
Start with /docs/metrics, then review /docs/choosing-delivery-metrics and /docs/guides/github-metrics-for-managers for a manager-friendly overview.
If you want a cleaner way to prepare engineering staff meeting metrics from GitHub PR data, start a guided setup in /app/onboarding.
For product notes and current constraints, see /docs/limitations and the pilot details at /docs/limitations#pilot.
engineering intelligence for GitHub PR delivery