7 Strategies to Get More From GitHub Analytics for Managers

GitHub holds a detailed record of how your team works: who opened what, who reviewed it, how long it waited, what shipped, and what had to be reverted. Most engineering managers either never look at it or open a dashboard full of charts that change no decision. Both outcomes waste a useful asset.

The seven strategies below are ordered from foundation to synthesis. They show how to turn GitHub analytics for managers into signals you can act on, while keeping the focus on teams and systems rather than building a leaderboard of individuals.

1. Start with the decisions you need to make

Most analytics efforts begin with the tool: connect GitHub, accept the default dashboard, and see what is there. The result is dozens of charts, none tied to a choice you actually make. Working backward from decisions reverses this. A metric earns its place only if a number moving up or down would change what you do this week.

Consider an illustration. A startup engineering manager writes down three questions she asks every Monday: what is blocked, is this week's release safe to ship, and are we on pace for the milestone. She then tracks only the GitHub data that answers those: PRs waiting on review or stuck in draft, the volume and concentration of merges heading into the release, and merged work against planned scope. Everything else on the default dashboard gets ignored.

To put this into practice:

1. List the five management decisions you make most often, such as reassigning work, delaying a release, adding reviewers, or escalating a slipping project.
2. Map each decision to one or two GitHub signals that would inform it.
3. Drop every metric that does not map to a decision.
4. Review the list each quarter, since the decisions change as the team grows.

The common mistake is adopting every available chart because it is easy to add. A dashboard with thirty panels is a dashboard nobody checks, and the one panel that matters gets lost. If you cannot name the decision a metric supports, remove it.

To know it is working, track two things: the share of your weekly planning decisions that referenced the data, and the time you spend preparing for those decisions. The first should rise and the second should fall. If you still prepare by asking people in chat, the metrics are not yet answering your real questions.

2. Track flow metrics: cycle time and PR wait stages

Cycle time is the elapsed time from when work starts to when it is merged or delivered. In GitHub terms, the most practical version runs from PR opened to PR merged. The useful insight comes from splitting that span into stages, because a PR spends most of its life waiting, not being worked on.

Here is an illustration. A team measures its PRs and finds the median time to first review is 26 hours, while the review itself, from first comment to approval, takes about 2 hours. The problem is not slow reviewers or large diffs. It is that PRs sit unnoticed. The team sets up a daily review rotation with one named person responsible for picking up new PRs, and the first-review wait drops without anyone working harder.

To build the measurement:

1. Pull four timestamps per PR from GitHub: opened (or marked ready for review), first review, approval, and merge.
2. Compute the duration of each stage: waiting for first review, in review, waiting to merge after approval.
3. Report the median and the 85th percentile for each stage, weekly.
4. Exclude drafts and bot PRs, or the numbers will be noisy.

The common mistake is reporting average cycle time. Averages are dragged around by a few very long PRs, and they blend all stages together so the bottleneck disappears. Medians show the typical experience, and the 85th percentile shows how bad the slow tail gets, which is usually where developers feel the pain.

Measure median and 85th percentile time to first review and time to merge. If the rotation or a new review norm is working, the first-review median falls first, and the 85th percentile follows a few weeks later.

3. Use DORA metrics as a baseline

The DORA measures come from Google Cloud's DevOps Research and Assessment program and were popularized by the book Accelerate (Forsgren, Humble, and Kim, 2018). They capture two things together: how fast a team delivers and how stable that delivery is. The classic set covers lead time for changes, deployment frequency, change failure rate, and time to restore service. The program has refined its metric set and naming over the years, so check the current definitions on the DORA site before you publish or benchmark anything as of 2026.

The strength of DORA is that it pairs speed with stability, so you cannot look good by shipping fast and breaking things. The weakness is that none of it comes straight out of GitHub. You have to decide what the terms mean for your team.

Suppose a team without a formal release process approximates deployment frequency by counting merges to main, or tagged releases if they use them. It approximates failures by counting PRs labelled hotfix or titled as reverts. Neither is perfect, but both are consistent, and consistency is what makes a trend meaningful.

To implement it:

1. Write down what counts as a deployment and what counts as a failure for your team.
2. Derive the data from GitHub releases, Actions workflow runs, and a revert or hotfix label.
3. Measure lead time as first commit or PR open to production, using the closest proxy you have.
4. Trend the numbers quarterly, not daily.

The common mistake is turning DORA numbers into targets or comparing teams against each other. Under Goodhart's law, once a measure becomes a target it stops being a good measure: teams split deployments into trivial ones or stop labelling failures. Use DORA as a diagnostic conversation starter. Track the direction of lead time, deployment frequency, and failure rate over a quarter, and ask why they moved.

4. Watch change pressure and deployment risk

Change pressure describes how much change is landing in a short window, and where. Code churn, meaning code that is rewritten or deleted soon after being written, or files edited repeatedly, adds a second angle. High pressure on a sensitive area raises the odds that something slips through review and breaks in production.

Imagine 40 merges land in the billing module in three days, from five different authors, with several files touched again and again. The raw PR count for the week looks normal, but the concentration is not. The manager decides to split the release, ship the lower-risk changes first, and require a second reviewer on the billing changes.

To apply this:

1. Track merges per window (daily or per release) and note where they cluster by directory or service.
2. Flag files with repeated edits and high churn, since they are the hotspots.
3. Add a pre-release check: review the pressure and hotspot summary before cutting a release.
4. Agree a team rule for high-pressure releases, such as extra review, a smaller batch, or a staged rollout.

The common mistake is judging risk by PR count alone. Twenty small copy changes spread across the app are safer than eight changes to payments logic. Location and repetition matter as much as volume. Progress assesses deployment risk and change pressure from merge volume and churn automatically, so you see the concentration without assembling it by hand.

To check it works, compare change failure rate and rollbacks for releases you flagged as high pressure against low pressure ones. If flagged releases fail more often, your thresholds are meaningful. If not, tune them.

5. Spot stalled work with aging signals

Missed deadlines rarely arrive suddenly. They start as a PR that nobody picked up, an issue that quietly stopped moving, or a branch waiting on an answer. Aging signals flag items whose time since last activity exceeds what is normal for that kind of work, so you can intervene while the fix is still cheap.

Take an illustration. A PR linked to a Linear issue sits idle for four days: no commits, no comments, no review. The weekly stall flag surfaces it, the manager asks in standup, and it turns out the author is waiting on a design question. A quick reassignment of the question gets it moving the same day.

Setting this up:

1. Choose idle thresholds per work type. A small bug fix might be stale after two days, a large refactor after seven.
2. Link GitHub to Linear so a stalled PR carries its issue context, priority, and owner.
3. Label intentional long-running work, such as migrations or spikes, so it is excluded or given a longer threshold.
4. Review the stall list in standup or in a weekly check, and ask one question per item: what is needed to move this?

The common mistake is using a single threshold for everything. It either floods you with false alarms on legitimately slow work or misses fast-moving items that went quiet. Once people learn the alerts are mostly noise, they ignore them all. Progress pre-computes stalled-work signals across GitHub and Linear, which saves you from maintaining the queries yourself.

Measure the number of items idle beyond their threshold and the median time to unblock them. Both should fall as the habit takes hold.

6. Read team momentum and morale, not individual output

Momentum asks whether the team's work is accelerating, steady, or slowing. Morale and workload signals show whether that pace is sustainable. Both are visible in GitHub at the team level if you look at trends and distribution instead of personal totals.

Here is an illustration. A manager notices that review requests are concentrating on one senior engineer, who now handles most of the team's reviews, while weekend commits from the same group are creeping up. Throughput looks fine, which is exactly why the problem is easy to miss. The manager rebalances review assignments, widens the pool of approved reviewers, and raises workload in the next retro.

What to track, at team level:

• Throughput trend over four to six weeks, so one slow week does not trigger alarm.
• Review distribution: how evenly review work is spread across people.
• After-hours and weekend activity as a share of total activity.

Bring these into 1:1s and retros as questions, not verdicts. A rising after-hours share is a prompt to ask what is driving it, not proof of a problem on its own.

The common mistake is using commit counts or lines of code to evaluate people. Both reward noise: big diffs, many tiny commits, and avoiding hard work that produces little code. They also damage trust, and engineers will game what is measured. Progress reads momentum and morale as team-level signals, giving you an early view of health before it shows up in delivery.

Measure throughput trend, review load distribution, after-hours activity share, and qualitative feedback from retros. The qualitative piece matters most, since it tells you whether the numbers match how people feel.

7. Roll up activity into initiative health and summaries

Leadership rarely wants to know about PRs. They want to know whether the onboarding revamp will ship when promised. Rolling GitHub activity up to the initiative level translates engineering detail into the status people outside the team can use.

Suppose a founder asks whether the onboarding revamp is on track. Instead of a list of 60 merged PRs, she gets a short summary: the core flow and email changes have merged, the analytics events are at risk because the owner was pulled onto an incident, and one dependency on a design decision is blocking the final step. It ends with a recommended action: confirm the design decision by Wednesday.

To build the habit:

1. Group repos, issues, and PRs into initiatives, using Linear projects or labels as the key.
2. Define a fixed weekly format with three parts: shipped, at risk, blocked.
3. Add one line per initiative with a judgment and a next step.
4. Automate the draft, or query it on demand through Progress, which generates executive summaries and answers plain-language questions about initiative status from real activity data.

The common mistake is sending leadership raw activity lists: counts of PRs, commits, or tickets closed. They look thorough but push the interpretation onto readers who lack the context. A good status makes a call and recommends what to do about it.

Measure the time you spend on status reporting, which should fall, and the number of surprises leadership discovers late, which should approach zero. If a founder still learns about a slip from a customer or a missed date, the roll-up is not catching risk early enough.

Where to start and how to build trust in the data

Begin with strategies 1, 2, and 5. They need little setup, rely on data you already have, and produce quick wins: a clear set of decisions, a visible wait-time bottleneck, and a short list of stalled items to unblock this week. Early results matter because they show the team the data is used to remove friction, not to judge them.

Once that trust is in place, layer in release risk, momentum, and initiative reporting. DORA fits in whenever you want a quarterly baseline. Share what you track and why, and keep the focus on teams and systems throughout.

If you would rather not assemble these signals by hand, Learn more about our services.