Discover why measuring individual developer performance with raw metrics leads to gaming behavior and erodes team trust. Learn how Keypup's MCP Server provides contextual benchmarking that accounts for code review, cross-team collaboration, and the role and team context you supply—transforming metrics from surveillance tools into culture-building insights that recognize real value beyond lines of code.
TL;DR: "When a measure becomes a target, it ceases to be a good measure." Goodhart's Law perfectly describes what happens when you use git analytics for individual performance reviews: developers game the system, split PRs artificially, inflate story points, and focus on metrics over value. Keypup's MCP Server helps fix this by providing contextual benchmarking that recognizes review work, cross-team contributions and the role context you give it—transforming metrics from surveillance into culture-building insights.
You rolled out git analytics. You can finally see who's merging PRs, who's reviewing code, who's closing tickets. Data-driven performance management, right?
Three months later, your senior engineer submits 47 PRs in a sprint (last quarter's average: 8). Your junior dev's story point velocity tripled overnight. Your architect who used to mentor everyone now has zero PRs for two weeks.
Congratulations: Your team is gaming your metrics.
This isn't malice—it's survival. When metrics become performance targets, rational engineers optimize for the target, not the outcome. Welcome to Goodhart's Law in action.
"My manager started tracking 'PRs merged per sprint' after reading some productivity blog. Guess what happened? I now split every feature into 5-7 micro-PRs. Each one is technically mergeable but makes no sense in isolation. Code review became a joke because reviewers can't understand context across 6 PRs. Velocity looks great on the dashboard. Product quality tanked. But hey, my performance review was stellar because I 'increased output by 300%.'"
"We introduced story point tracking tied to bonuses. Within two sprints, every ticket mysteriously became 8 or 13 points. What used to be '2 points: add a validation field' became '8 points: implement comprehensive validation framework with full test coverage.' Same work, inflated estimates. Planning became a negotiation game instead of capacity planning. Nobody trusts the process anymore."
"I spend 60% of my time on architecture reviews, design docs, mentoring juniors, and unblocking other teams. My git stats look pathetic: 3 PRs last month, mostly documentation updates. Meanwhile, a dev who cranks out features (ignoring tech debt, skipping reviews, writing zero docs) has 5x my 'productivity metrics.' Guess who got the better performance rating? I'm looking for a new job."
"Pro tip I learned from a colleague: If your company tracks LOC (lines of code), write verbose code. Expand one-liners. Add comments for obvious things. Split imports across multiple lines. My 'productivity' doubled and management thinks I'm a rockstar. Actual value delivered? Same as before, just more noise. The game is the game."
Sound familiar? This isn't hypothetical—it's happening in thousands of engineering teams right now.
Goodhart's Law (economist Charles Goodhart, 1975): "When a measure becomes a target, it ceases to be a good measure."
Applied to software development:
When individual performance metrics become evaluation criteria, rational engineers employ these strategies:
1. PR Inflation: Death by a Thousand Micro-Commits
2. Story Point Manipulation: Anchoring Bias as Strategy
3. Low-Hanging Fruit Prioritization: Avoiding Hard Problems
4. Shadow Work Evasion: Making Invisible Work Stay Invisible
5. Quality Sacrifice: The Race to the Bottom
6. AI-Inflated Output: The Newest Way to Pad the Numbers
To tell AI-driven volume apart from real throughput, put AI usage next to delivery data. Keypup's AI Usage dataset imports GitHub Copilot usage (Claude Platform, OpenAI Platform and OpenAI Codex Enterprise are in beta): active developers, suggestions accepted, and lines suggested vs. lines added. The AI Usage & Monitoring dashboard is a ready-made starting point.
The damage extends far beyond distorted metrics:
Trust Erosion:
Quality Degradation:
Knowledge Silos:
Talent Flight:
Raw individual metrics fail for one fundamental reason: Software development is a team sport embedded in a complex system.
When you measure an individual in isolation, you lose:
1. Role Differentiation
Who's more "productive"? Isolated metrics say junior dev. Reality says architect.
2. Work Type Complexity
Not all PRs are created equal:
Counting PRs treats these as equivalent. They're not.
3. Team Contribution Patterns
High-value activities that don't show in individual git stats:
These are essential. They're also invisible to "PRs per week" metrics.
4. Career Stage and Growth Mode
Measuring everyone with the same yardstick ignores career context.
The solution isn't to abandon metrics—it's to use them contextually and collaboratively, not punitively.
Keypup MCP provides a different approach: Benchmark individuals within their team and role context, accounting for the full spectrum of contribution Keypup can see (pull requests, reviews, comments, issues) plus the context you supply.
Keypup only knows what happens in your Git hosts and work trackers. Roles, levels, mentoring pairs, on-call rotations and design docs aren't in that data, so describe them in your team's AI Instructions in Keypup: the MCP Server reads them (since September 2026) and every query below can use them.
Instead of: "Alice merged 4 PRs this sprint (team average: 9), therefore Alice is underperforming."
Use contextual analysis:
Contextual Individual Contribution Analysis
Analyze Alice's contribution to the team over the last sprint. Include: PR activity, code reviews given and review comments per reviewed PR, comments on juniors' PRs (juniors are listed in our AI Instructions), issue resolution, reviews on other teams' repositories, and issues labelled incident that she resolved. Compare her contribution mix to the team's needs and to the role expectations in our AI Instructions.
What you discover:
Conclusion: Alice's contribution profile is "senior tech lead"—high leverage, team-multiplier activities. Her value is higher than raw PR count suggests, not lower.
Don't compare:
Do compare:
Role-Adjusted Benchmarking Analysis
Compare the contribution patterns of all mid-level engineers (L3/L4 equivalent, as listed in our AI Instructions) across our engineering organization over the last quarter. Segment by: team type (feature, platform, legacy, as mapped to repositories in our AI Instructions) and team composition (ratio of senior to junior members). For each group, show PRs merged per sprint, reviews given, comments on others' PRs, reviews on other teams' repositories, and average files changed per PR. Identify patterns and outliers, accounting for role context.
What you discover:
Conclusion: Comparing a platform engineer's 6 PRs/sprint to a feature engineer's 11 PRs/sprint is meaningless. Context matters.
Make shadow work visible:
Shadow Work Quantification Analysis
For each team member over the last quarter, compare their own PRs and commits with their activity on other people's work: reviews given, review comments, comments on juniors' PRs, reviews on other teams' repositories, and documentation PRs (labelled docs). Show the share of each person's activity that went to their own PRs vs. others' work. Mentoring pairs, on-call rotations and design docs aren't in Keypup, so use the ones listed in our AI Instructions. Compare individual patterns to team needs.
What you discover:
Conclusion: PR counts capture only about half of the activity Keypup can see, and none of the mentoring, design and incident work it can't. The rest is essential but invisible.
Measure trajectory, not snapshots:
Individual Growth Trajectory Analysis
Analyze Emily's (junior engineer, hired 9 months ago) growth trajectory month by month across: PR size (lines changed, files touched), rework (review rounds and "changes requested" reviews per PR), independence (share of her PRs approved without changes requested), review participation (reviews given and review comments left), and expanded scope (new repositories contributed to, PRs in other teams' repositories). Compare her 9-month journey to the junior expectations in our AI Instructions.
What you discover:
Conclusion: Emily is developing ahead of schedule. Her current "lower" absolute output is expected and healthy. Penalizing her for not matching senior engineers would be absurd.
Use metrics to identify gaming behavior, not punish legitimate patterns:
Metric Gaming Detection Analysis
Analyze our team's PR patterns over the last two quarters for indicators of metric gaming: sudden changes in PR size distribution (many micro-PRs where larger PRs were typical), story point inflation patterns in Jira (same issue types consistently estimated higher), low-hanging fruit bias (fewer issues labelled complex or tech-debt picked up after metrics tracking began), review quality degradation (review time and review comments vs PR size), and coordination avoidance (fewer comments on others' PRs, fewer cross-team reviews). Flag statistical anomalies so we can interview team members to understand context.
What you discover:
Conclusion: These are statistical signatures of gaming behavior. This isn't individual failure—it's a systemic response to misaligned incentives.
Recognize and reward activities that don't produce commits:
Non-Coding Excellence Recognition Analysis
Identify team members who excel in high-value, low-visibility activities over the last quarter: mentoring (reviews and comments on the PRs of the juniors they mentor, as listed in our AI Instructions, and how those juniors' rework rate evolved), code review depth (reviews given, review comments per reviewed PR, reviews requesting changes), incident work (issues labelled incident they resolved and time to resolve), and cross-team collaboration (reviews and comments in other teams' repositories). Quantify impact where possible. I'll add architecture work (RFCs and design docs) myself, since it isn't in Keypup.
What you celebrate:
Conclusion: These contributions are more valuable than raw PR counts for many roles. Recognizing them explicitly prevents talent flight.
The Pledge (from leadership to teams):
"We will never use isolated git metrics (PR counts, LOC, commits) as the sole or primary basis for individual performance evaluation, promotion decisions, or bonus calculations. We recognize that software development value comes from a complex mix of coding, mentoring, architecture, coordination, and quality work. We commit to evaluating contribution holistically and contextually."
This pledge must be:
Without this pledge, any metric system will be perceived as surveillance and gamed accordingly.
Create clear expectations for different roles:
Junior Engineer (L1-L2):
Mid-Level Engineer (L3-L4):
Senior Engineer (L5-L6):
Staff+ Engineer (L7+):
Performance reviews become collaborative reflection, not top-down judgment:
Quarterly Self-Reflection (engineer-driven):
Engineer answers via MCP queries:
Self-Reflection: My Contribution Pattern
Show me my contribution breakdown over the last quarter: coding work (PRs, size, repositories), review participation (reviews given, review comments), comments on juniors' PRs, issues labelled incident I resolved, and reviews in other teams' repositories. I'll add my mentoring, RFCs and design input myself. How does this align with the role expectations in our AI Instructions and my career goals? What do I want to shift next quarter?
Manager Review (context-adding):
Manager runs comparative analysis:
Manager Context: Team Contribution Alignment
Compare [Engineer]'s contribution pattern (PRs, reviews, comments, issues) to the role expectations in our AI Instructions, team needs, and similar roles across the organization. Identify: strengths (where they excel or exceed expectations), growth areas (skills to develop), misalignments (doing too much/too little of certain activities), and opportunities (where team needs their unique strengths).
Collaborative Conversation:
Public Recognition Patterns:
Make invisible work visible by celebrating it as much as shipped features.
Use MCP to detect gaming behavior early. Keypup doesn't send alerts, so run this check yourself on a fixed cadence (for example at each sprint review), or keep the same insights on a Keypup dashboard:
Gaming Behavior Early Detection
Compare the last 4 weeks with the previous quarter and look for statistical anomalies that suggest gaming: sudden shifts in PR size distribution, story point inflation in Jira, fewer review comments per reviewed PR, fewer comments on others' PRs, avoidance of issues labelled complex, and fewer cross-team reviews. Report which patterns cross the thresholds in our AI Instructions. Frame them for investigation and team conversation, not punishment.
Response to Gaming Signals:
Quarterly retrospective on metrics and performance process:
Questions for the team:
Treat your performance system as a product that needs user feedback and iteration.
Company: MedTech SaaS (127 engineers)
Initial State: Individual metrics used for performance reviews, heavy gaming behavior
Timeline: 18-month transformation
Symptoms:
Actions:
Changes:
6-Month Progress Check: Gaming Behavior Reduction
Compare team behaviors across Month 0-3 (before intervention) vs Month 4-9 (after intervention): PR size distribution, story point inflation, review quality metrics, pair programming frequency, mentoring activity, senior engineer retention, and team health survey scores. Quantify changes and identify patterns.
Quantitative results:
Qualitative results:
CEO Quote (Month 18 all-hands):
"18 months ago, we were optimizing for metrics and losing our best people. Today, we optimize for impact and our best people are thriving. The shift from surveillance metrics to contextual contribution was the best cultural investment we've made."
Here's the paradox: Metrics are incredibly valuable—when they're not used punitively.
Metrics as surveillance → Gaming, trust erosion, talent flight
Metrics as insight → Self-awareness, growth, team optimization
The difference is intent and implementation:
Don't:
Do:
Goodhart's Law isn't a reason to abandon metrics—it's a warning about how you use them.
The lesson: Never make a metric a target without considering how rational actors will respond.
When you tie individual performance to raw git stats:
When you use metrics contextually and collaboratively:
Keypup MCP doesn't eliminate the human challenge of performance management—it gives you the context to do it well. You can:
The goal isn't to measure everything—it's to recognize the right things and create a culture where contribution is valued holistically.
Your best engineers aren't necessarily the ones with the most PRs. They're the ones making everyone around them better.
Stop counting commits. Start recognizing impact.
The Keypup MCP Server works with Claude, ChatGPT, Cursor, VS Code (GitHub Copilot) and Kiro. Connect in one click with OAuth from the MCP Setup page in Keypup, or add the Keypup app from the ChatGPT app directory. Describe your roles and teams in AI Instructions, then ask the questions in this article about your own team, without turning them into targets.
Get Started: Keypup MCP Documentation
Connect your assistant: Keypup for Claude or Keypup for ChatGPT
More About the Keypup MCP server: MCP Server page
Questions?: Contact us
Join teams already using AI to make data-driven decisions faster than ever.
Velocity looks fine, until your best engineers quit. Learn what engineering leaders on Reddit say about after-hours commits, weekend work and burnout at enterprise scale, and how Keypup MCP uses commit, review and merge timestamps to measure how much work happens outside working hours, where it concentrates, who is overloaded without naming anyone, and what it costs in skipped reviews.
Your median cycle time looks healthy, yet every release still ends in merge conflicts, rebases and big-bang reviews. Learn what engineering leaders on Reddit say about long-lived branches and the trunk-based vs GitFlow debate at enterprise scale, and how Keypup MCP uses pull request dates, target branches, commits, reviews and mergeability to measure branch lifetime, find where branches live longest and land aging work before it drifts into conflict.
Compare the 6 best engineering metrics tools for multi-team benchmarking in 2026 — Keypup, LinearB, Swarmia, Jellyfish, Faros and Appfire Flow — on cross-team benchmarking, org-level rollups, DORA Metrics, Git-to-ticketing linking, custom KPIs, AI capabilities and data security. See how to compare teams on equal terms and find where your delivery process is broken.