GitHub Activity Is a Bad Proxy for Engineering Output

Investors ask about GitHub activity because they don't know what else to ask. That's not a criticism — it's a structural problem nobody has solved cleanly, and pretending otherwise is how bad proxy metrics become gospel.

The PR Count Problem

A pull request is a unit of intent, not a unit of value. A developer can open 30 PRs in a week by splitting a single refactor into 30 single-file diffs. Another developer can ship one PR that rewrites the billing engine and adds 4,000 lines of tested code. The contributor graph doesn't distinguish between them. Both show up as "active."

This isn't a hypothetical. Teams under reporting pressure — where a founder is counting PRs before an investor call — learn quickly that the unit is gameable. Nobody announces it. Nobody has to. The incentive is loud enough on its own.

PR count as an engineering output metric has one thing going for it: it's countable. That's it. Countability is the weakest possible argument for a metric.

Refactor PRs Are Not Feature PRs

Some of the most important engineering work your team will ever do produces zero user-visible change. Migrating from a monolith to services, paying down a three-year technical debt on the authentication layer, replacing a flaky third-party SDK — all of this shows up in GitHub as merged PRs, but none of it moves the product forward in a way an investor can see.

The inverse is also true. A single PR that ships the onboarding flow investors asked about last quarter matters more than fifteen PRs that clean up type annotations. Raw GitHub activity flattens that distinction entirely.

The problem isn't that refactors don't matter — they matter enormously. The problem is that a metric built on PR count can't hold the difference. Your engineering team knows the difference. Your investor doesn't, unless you tell them.

The Metric Is a Vibe, and Everyone Knows It

Ask an experienced engineering leader what they look for when evaluating a team's output and they'll pause. Not because they don't know — because the real answer is complicated. Cycle time. Deployment frequency. The ratio of planned work to unplanned work. Whether the team is shipping features or constantly firefighting incidents. Whether the codebase is getting easier or harder to change.

None of that fits in an investor email. So GitHub activity — commits, PRs, the green squares — becomes a rough gesture toward "the team is doing things." It's a vibe check dressed up as a productivity metric.

Sophisticated investors know this. They're not looking at PR count and thinking it measures engineering output precisely. They're using it the way you might use someone's posture in a meeting — as a weak signal that requires context to interpret. The problem comes when founders start optimizing for the signal instead of providing the context.

What Investors Actually Want to Know

Strip away the surface question and the real ask is simpler: is the team executing? Are the things you said you'd build getting built? Is the velocity accelerating, holding, or declining? Are there blockers you're not talking about?

Those questions can be answered without a single GitHub metric. What they require is translation — someone who understands what the engineering team did and can render it in terms that connect to roadmap, to revenue, to risk. That's not a dashboard problem. It's a communication problem.

• What shipped and who will notice it (users, sales, support)?
• What was supposed to ship and didn't, and why?
• What slowed the team down this week that isn't obvious from the outside?
• What's next, and is the team set up to get there?

An investor who gets those four answers weekly doesn't need to ask about PR counts. They already know more than the GitHub graph would tell them.

The Translation Layer Nobody Wants to Write

Most engineering updates fail because the person writing them is either too close to the work or too far from it. The developer who merged the PRs writes in technical shorthand. The founder who forwards the update to investors writes in startup marketing language. Neither version actually answers the investor's real question.

A good stakeholder update translates without dumbing down. It names the work, explains the stakes, flags the tradeoffs, and keeps moving. A refactor PR becomes "we rebuilt the part of the system that was causing 30% of customer support tickets — no new features, but that debt is gone." A feature PR becomes "users can now do X, which removes the main blocker our sales team has been flagging for two months."

That kind of framing takes judgment. It also takes time — which is exactly why most teams default to sending a GitHub link and calling it a status update. Tools like RepoDigest exist to close that gap, pulling in merged PRs and closed issues and producing a plain-English summary a non-technical reader can actually use. But whether you automate it or write it by hand, the work is the same: stop reporting activity and start reporting meaning.

A Better Conversation to Have

If an investor is asking you about GitHub activity, the right move isn't to optimize your metrics — it's to reframe the question. Offer them what they're actually after: evidence of execution, honest about pace, clear about what's next.

You can acknowledge the proxy openly. "PR count is a rough signal, so here's the context behind ours this week." Most investors respect that. What they don't respect is getting a raw metric with no interpretation, or worse, a raw metric that was quietly gamed to look good.

GitHub activity isn't useless. The green squares are real. But the engineering metrics that actually tell you whether a team is healthy — cycle time, defect rates, the ratio of feature work to rework — aren't visible in a contributor graph. They live in the context your team has and your investor doesn't. The only way that context travels is if someone writes it down.

Connect a repo, add stakeholder emails, get a plain-English summary delivered every week. Free to try.