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 mentoring, architecture work, and team contribution—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 fixes this by providing contextual benchmarking that recognizes mentoring, architecture work, and team contributions—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
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.
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 review participation, issue resolution, mentoring indicators (PR guidance, pair programming patterns), architecture work (design docs, RFCs), cross-team coordination (external PR reviews, dependency management), and on-call/incident response. Compare her contribution mix to the team's needs and her role expectations.
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) across our engineering organization over the last quarter. Segment by: primary responsibilities (feature development, infrastructure, tooling), team composition (ratio of senior to junior members), and work complexity (legacy refactoring vs greenfield development). 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, quantify time spent on activities that don't produce direct git commits: code review thoroughness and frequency, mentoring patterns (pair programming sessions, PR guidance to juniors), architecture contributions (design doc authorship, RFC participation), incident response (on-call participation, debugging time), documentation (README updates, technical writing), and cross-team coordination (external reviews, dependency management). Compare individual patterns to team needs.
What you discover:
Conclusion: Traditional metrics capture only 55% of actual team contribution. The other 45% is essential but invisible.
Measure trajectory, not snapshots:
Individual Growth Trajectory Analysis
Analyze Emily's (junior engineer, hired 9 months ago) growth trajectory across: PR complexity (lines changed, files touched, system areas), code quality (review feedback trends, rework rates), independence level (questions asked, mentoring sessions needed), review participation (reviews given, review quality), and expanded scope (new repositories contributed to, cross-team work). Compare her 9-month journey to team expectations and typical junior engineer growth curves.
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 (same work types consistently estimated higher), low-hanging fruit bias (avoiding complex issues after metrics tracking began), review quality degradation (review time vs PR complexity), and coordination avoidance (reduced pair programming, fewer cross-team reviews). Flag statistical anomalies and 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 effectiveness (junior engineers' growth curves, pairing hours), architecture leadership (RFC authorship, design influence, technical decision quality), code review quality (thoroughness, bug detection, knowledge sharing), incident heroics (on-call response time, problem resolution, post-mortem quality), and culture building (team health contributions, cross-team collaboration, onboarding support). Quantify impact where possible.
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, complexity, scope), review participation (quantity, quality), mentoring activities (pairing, guidance, onboarding support), architecture contributions (RFCs, design input), incident work, and coordination. How does this align with my role expectations and 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 to role expectations, 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:
Gaming Behavior Early Detection
Monitor for statistical anomalies that suggest gaming: sudden shifts in PR size distribution, story point inflation patterns, reduced review quality, decreased pair programming, avoidance of complex issues, and coordination reduction. Alert when patterns cross thresholds. Flag 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.
Keypup MCP is available now for GitHub Copilot, Claude, and other AI assistants supporting the Model Context Protocol. Connect your Jira, Trello, and Git repositories in under an hour and start asking better questions.
Get Started: Keypup MCP Documentation
More About the Keypup MCP server: MCP Server page
Questions?: Talk to our PM team
Join teams already using AI to make data-driven decisions faster than ever.
Discover how to overcome the most painful project management challenges in software development. Learn how Keypup's MCP Server harmonizes data across Jira, Trello, and Git repositories to provide actionable insights, predictive analytics, and real-time visibility—transforming chaos into clarity and helping teams deliver on time, every time.
Learn how to achieve and maintain ISO27001 and SOC2 Type II certifications for your software development organization. Discover the specific SDLC requirements, audit processes, and how Keypup's MCP Server provides continuous compliance monitoring, automated evidence collection, and real-time audit trails—saving months of preparation time and reducing certification costs by up to 60%.
AI coding assistants promise productivity gains, but are they delivering? Learn how to measure the real impact of AI tools on your SDLC—from code quality to cycle time to developer satisfaction. Discover which metrics matter for ROI analysis and how Keypup's MCP Server correlates AI adoption with engineering outcomes and financial performance.