Productivity Metrics Are Turning PRs Into Theater

TL;DR: Developers are not angry about measurement. They are angry about fake measurement. When managers turn pull request counts, story points, and tool usage into individual productivity dashboards, teams start optimizing for the dashboard instead of the work. The result is more tiny PRs, noisier Jira rituals, weaker trust, and engineering theater that looks busy while making delivery worse.

A recent r/ExperiencedDevs thread hit a nerve because it described something many software teams recognize immediately: management starts tracking pull requests, story points, website usage, and AI tool activity, then calls it productivity. The post was not anti-accountability. It was anti-metric cosplay. Developers know the difference because they are the ones who have to live inside the incentives.

Why are developers pushing back on productivity metrics?

Developers are pushing back because many productivity dashboards measure visible motion instead of useful engineering outcomes. A pull request count can rise while architecture quality, review depth, and delivery confidence fall. Once individual metrics become a performance signal, people adapt their behavior to survive the dashboard, even when that means worse software.

The complaint is not that managers should fly blind. Healthy teams absolutely need signals. Cycle time, deploy frequency, incident recovery, customer impact, and review bottlenecks can all help a team see where work gets stuck. The problem starts when those signals get flattened into personal scoreboards.

A senior engineer can spend two days deleting dead complexity, pairing with a teammate, preventing a production incident, or reviewing a risky migration. None of that necessarily creates a neat stack of PRs. Meanwhile, someone else can split one small task into five branches and look more productive to a dashboard that only counts artifacts.

That is why this trend travels fast in developer communities. Engineers have seen how measurement systems mutate behavior. The moment a metric becomes a target, it stops being a clean measurement. It becomes a game surface.

What goes wrong when teams track pull request counts?

Pull request counts go wrong when they reward fragmentation instead of judgment. Small PRs are good when they reduce review risk, but forced PR quotas encourage developers to open premature branches, split logical work unnaturally, and compete for visible authorship. The metric starts as a proxy for flow and becomes a machine for performative busyness.

The r/ExperiencedDevs post described a familiar failure mode: if two engineers collaborate on one branch, only the person who opens or merges the PR gets credit. That turns pairing, mentoring, and shared ownership into a liability. People start asking not “what is the cleanest way to ship this?” but “how do I make sure the dashboard sees me?”

There is a real engineering reason to prefer smaller PRs. They are easier to review, easier to revert, and less likely to hide subtle bugs. But small is not the same as many. A thoughtful four-file PR can be healthier than six artificial PRs that exist because someone needs a number by Friday.

This is where developer humor gets painfully literal. The team starts writing code for the dashboard. The dashboard reports that productivity is up. Then the codebase gets noisier, review queues get worse, and everyone pretends the system is working because the chart has a pleasing slope. That is prime Works on My Machine T-shirt energy, just with more Jira.

Why do story point targets create bad incentives?

Story point targets create bad incentives because estimates are not production units. Points are supposed to help teams discuss uncertainty, complexity, and capacity. When leadership demands a fixed percentage increase every sprint or quarter, teams learn to inflate, reclassify, or argue over points instead of improving the system that delivers work.

Story points are already fuzzy. Some teams use them as complexity, some as effort, some as risk, and some as a polite way to say “we have no idea yet.” That ambiguity can be useful inside a team conversation. It becomes toxic when the number is exported upward as a clean productivity ratio.

The predictable result is ritual overhead. Engineers spend more time grooming Jira to match leadership expectations. Product managers negotiate point totals. Sprint planning becomes accounting. Retrospectives become explanations for why a target did not rise by exactly the desired percentage. None of that ships a better product.

The weirdest part is that pressure to increase velocity can make velocity less real. A team that doubles its points by changing how it estimates has not doubled output. It has changed the unit. Engineers know this, which is why point mandates feel less like management science and more like spreadsheet fan fiction.

How should engineering teams measure productivity instead?

Engineering teams should measure productivity with a balanced set of team-level signals, not individual activity counters. Useful metrics include lead time, deployment health, incident recovery, review latency, escaped defects, customer impact, and developer experience. The goal is to find friction in the system, not rank humans by how many artifacts they produce.

A better dashboard asks different questions. Where do PRs wait too long? Which services create repeat incidents? Which work gets reopened because requirements were unclear? Which teams are overloaded with interrupts? These questions help the team improve the system instead of making individuals defend their existence.

The best engineering leaders also combine numbers with narrative. A weekly update can include the messy context that dashboards miss: a risky migration, a painful refactor, a difficult customer bug, or a quiet reliability improvement that prevented future drama. Numbers are useful. Numbers without context are how you accidentally reward the wrong thing.

If leadership wants a lightweight rule, use metrics as smoke alarms, not scoreboards. A spike in review time might mean too much work in progress. A drop in deploy frequency might reveal release friction. A low PR count from a senior engineer might mean they spent the week unblocking half the team. Context is not optional.

What does this say about developer culture right now?

This trend shows how tired developers are of being measured by proxies that ignore craft. Software work has become easier to instrument, especially with AI tools, code hosting, and project management systems. That does not mean every tracked event deserves managerial weight. Developer culture is pushing back against surveillance dressed up as optimization.

There is also an AI layer here. As more teams adopt coding assistants, raw output gets even easier to inflate. A developer can produce more code, more PRs, and more review load without producing more value. In that world, judgment matters more, not less. Counting artifacts gets even weaker.

Senior engineers are especially sensitive to this because their highest value work often looks invisible. They reduce blast radius. They say no to bad abstractions. They review the scary diff carefully. They mentor someone through a design decision. They delete future work by making today’s system simpler. Most dashboards undercount that because most dashboards are bad at wisdom.

That is why this story fits Code Culture so cleanly. The joke is not “management bad.” The joke is that everyone in the room knows the metric is fake, but the chart still gets a meeting invite. Wear the Sudo Shirt if you have ever needed root access to common sense.

Code Culture’s take

Code Culture’s take is simple: measure the work, but do not confuse measurement with trust. Good teams deserve visibility into bottlenecks and outcomes. Bad systems turn developers into dashboard actors. If your metrics make engineers open fake PRs, argue over story points, or optimize for being seen, the metric is the bug.

The healthiest engineering cultures keep the feedback loop close to the team. They let developers inspect their own flow data, improve their own review process, and explain tradeoffs in plain language. They do not treat every GitHub event as a little employee heartbeat.

Accountability should make teams calmer and clearer. If it makes everyone more performative, it is not accountability. It is theater with a CSV export. Developers do not need fewer metrics. They need metrics that respect the actual shape of the job.

So yes, track delivery. Track quality. Track reliability. Track whether customers are getting the thing they were promised. Just be careful with any metric that makes a developer think, “I should open a PR so the dashboard knows I was alive today.” That is not productivity. That is a smoke test for trust.

Frequently Asked Questions

Are pull request counts a good productivity metric?

Pull request counts can show activity, but they are weak as a standalone productivity metric. They ignore review quality, task complexity, collaboration, mentoring, architecture work, and incident prevention. PR counts are useful for spotting process bottlenecks at a team level, not for ranking individual engineers.

Why are story points controversial?

Story points are controversial because they mix estimation, uncertainty, and team calibration into one number. Inside a team, that can support planning. When management turns points into output targets, the number becomes easy to game and stops representing real delivery progress.

What metrics should engineering leaders use instead?

Better engineering metrics include lead time, review latency, deployment frequency, change failure rate, incident recovery time, customer impact, and developer experience. These should be interpreted together with context. The best use is improving team systems, not judging individuals by isolated activity.

How can developers respond to bad productivity dashboards?

Developers can respond by calmly explaining the incentive problem, offering better team-level alternatives, and documenting examples where the metric rewards harmful behavior. The strongest argument is not “do not measure us.” It is “measure the outcomes that actually improve delivery and quality.”

Does AI make productivity metrics less reliable?

AI can make simple productivity metrics less reliable because it increases the volume of code, drafts, and pull requests without guaranteeing better outcomes. As generated output rises, teams need stronger review culture, clearer ownership, and quality-focused metrics rather than raw artifact counts.