Why We Don't Measure Developer Productivity (And What We Measure Instead)

The Rebellion Is Here

In January 2024, France's data protection authority fined Amazon €32 million for "excessively intrusive" employee surveillance¹. The company had been tracking keyboard strokes, scanner activity, and every moment of "inactivity" in its warehouses.

Amazon isn't alone. A recent study found that 50% of workers being monitored would rather quit than endure constant surveillance². Meanwhile, "mouse jigglers"—devices that simulate activity to fool monitoring software—are now Amazon bestsellers. The irony writes itself.

This isn't just happening in warehouses. It's happening in engineering.

A growing ecosystem of "developer productivity" tools promises to help engineering leaders understand what their teams are doing. They track lines of code, commits per day, hours at the keyboard, and increasingly—with AI—even the content of what developers write.

Here's the uncomfortable truth: these tools are surveillance dressed up as management. And they're making engineering teams worse, not better.

The Problem: Why Productivity Metrics Are Toxic

Let's examine what these tools actually measure:

Lines of Code

As the saying goes, measuring programming productivity by lines of code is like measuring aircraft progress by weight. Bill Gates reportedly put it bluntly: "Measuring programming progress by lines of code is like measuring aircraft building progress by weight."

A Stack Overflow discussion captured it perfectly: "Measuring developer output by lines of code is like measuring a power plant's effectiveness by the waste it produces."

More lines often means worse code. Refactoring that reduces 500 lines to 50 is progress. Automation that eliminates a manual process is progress. A well-designed abstraction that prevents future work is progress. None of these show up positively in LOC metrics.

Commits Per Day

Trivially easy to game. Want to boost your commit count? Split a single logical change into fifteen tiny commits. Add whitespace changes. Commit your lunch break.

More importantly, commits measure activity, not impact. A developer who spends a week designing an architecture that saves the team months of work will have fewer commits than someone furiously shipping features that create technical debt.

Hours Worked

This one is particularly insidious. Research consistently shows that working beyond 50 hours per week actually reduces total output³. Developers who stay late accomplish less, not more, because exhaustion leads to bugs, poor decisions, and code that requires rework.

One study found that developers working excessive hours literally produced negative work—they created more problems than they solved.

Yet "hours online" remains a cornerstone of surveillance tools.

The Goodhart Problem

British economist Charles Goodhart observed that "when a measure becomes a target, it ceases to be a good measure."⁴

Every metric mentioned above is trivially gameable:

• Want more commits? Split changes into fragments.
• Want more lines? Write verbose code.
• Want more hours? Keep your laptop open.
• Want more PRs? Submit smaller, more frequent changes.

The moment you start measuring these things, you're no longer measuring what you wanted to measure. You're measuring how well people game your metrics.

The AI Paradox: Why It's Getting Worse

If you thought traditional metrics were broken, AI is about to make everything worse.

The Productivity Illusion

The 2024 DORA (DevOps Research and Assessment) report—the most comprehensive annual study of software delivery performance—found something surprising: teams using AI coding assistants showed a 1.5% decrease in throughput and a 7.2% decrease in stability⁵.

Wait, what?

A 2025 study by METR went further. They found that experienced developers using AI assistants were actually 19% slower on real-world tasks. But here's the kicker: those same developers believed they were 20% faster⁶.

AI creates a perception-reality gap. Developers feel more productive while actually accomplishing less.

Individual Speed, Organizational Slowdown

AI amplifies individual productivity on certain tasks—generating boilerplate, writing tests, explaining code. But this individual speedup often translates to organizational slowdown.

Analysis of engineering data found that AI-assisted teams completed 21% more tasks, but their code reviews took 91% longer, and they introduced 9% more bugs⁷.

More output + longer reviews + more bugs = slower delivery.

What's the Difference Between Productivity and Effectiveness?

Developer productivity measures activity: commits, lines of code, hours at the keyboard. Developer effectiveness measures outcomes: whether work shipped, whether it stuck, and whether it helped the team. This is where we diverge from the surveillance-capitalism approach to engineering metrics.

"Developer productivity" is a broken concept. But developer effectiveness is measurable—if you focus on outcomes, not activity.

Our five core principles guide everything we build:

1. Outcome-driven: Measure delivered value, not activity
2. AI-neutral: Don't track tool usage, infer from outcomes
3. Developer-first: Individual profiles private by default
4. Coaching over judgment: Trends and guidance, not rankings
5. Anti-gaming: Multi-dimensional scoring resists manipulation

What This Means in Practice

We don't measure commits, lines of code, or hours worked. We measure:

• Did the work ship? (Delivery)
• Did it flow sustainably? (Flow)
• Did it stick? (Quality)
• Did it help the team? (Collaboration)

A developer achieving excellent outcomes with AI = effective. A developer achieving excellent outcomes without AI = effective. High activity + low outcomes = concern, regardless of tooling.

The 6 Dimensions of Effectiveness

We measure effectiveness across six dimensions. Each dimension has multiple components that intentionally create tension with each other.

Each dimension tells part of the story. The magic is in how they interact.

The Anti-Gaming Design (The Secret Sauce)

Here's what makes this system different: optimizing any single dimension typically hurts at least one other.

The Batch Size Sweet Spot

Consider PR sizes. We don't reward "more PRs" or "bigger PRs." We reward optimal sizing:

• 100-400 lines: Optimal. Score of 100.
• Under 50 lines: Over-fragmented. Score drops.
• Over 800 lines: Too large for effective review. Score drops.

You can't game this by making PRs smaller OR larger. There's an optimal range, and deviations in either direction hurt you.

Bug Fix Ratio

Similarly for quality, we don't just penalize bugs. We measure net contribution:

• Fixed more bugs than you introduced: Bonus points.
• Introduced more than you fixed: Penalty.

You can't game this by avoiding code (no bugs, but also no fixes). The system rewards net positive contribution to quality.

Privacy as Architecture, Not Policy

Many tools claim to be "privacy-focused" while still enabling surveillance. They add a checkbox in settings. They promise managers won't look at individual data. They create policies.

Policies can be changed. Settings can be toggled. Promises can be broken.

Our approach is different. Privacy is built into the architecture:

1. Individual profiles are isolated — There's no endpoint to retrieve "all developer scores"
2. No leaderboards exist — The concept isn't built
3. Managers see aggregates — Team-level patterns, not individual rankings
4. Coaching insights are scoped — Only visible to the developer (and optionally, their direct manager)
5. Export limitations — Individual data can only be exported by the individual

This isn't just about respecting developers (though it is). It's about getting accurate data. The moment people know they're being ranked, Goodhart's Law kicks in. The moment surveillance starts, the data becomes unreliable.

Trust enables accuracy. Surveillance destroys both.

The Vision: From Activity to Outcomes

The industry is at an inflection point.

The old approach—surveillance metrics, activity tracking, productivity theater—is breaking down. AI is accelerating the collapse. The numbers are bigger, but they mean less.

The new approach focuses on what matters:

• From "how much code" → "does it help users?"
• From surveillance → trust
• From vanity metrics → business impact
• From productivity theater → actual improvement

The teams that figure this out will have a massive advantage. They'll retain better developers (who won't tolerate surveillance). They'll make better decisions (based on meaningful data). They'll actually improve (instead of gaming metrics).

The CTO's Dream

What engineering leaders actually want:

1. Proof that engineering is improving — Not just snapshots, but trajectories
2. Defensible metrics — Something they can show the board that can't be easily dismissed
3. No gaming — Metrics that resist manipulation
4. Trust preservation — Measurement that doesn't destroy team culture
5. AI-ready measurement — Metrics that work regardless of what tools people use

Traditional productivity metrics fail all five requirements. They're snapshots, easily gamed, trust-destroying, and completely broken by AI.

Effectiveness metrics—focused on outcomes, designed for anti-gaming, built on trust—deliver all five.

What This Means for Your Team

If you're an engineering leader considering "developer productivity" tools, ask these questions:

1. What exactly are we measuring? If the answer is activity (commits, LOC, hours), run.
2. Can it be gamed? If optimizing the metric is easier than doing good work, the metric is useless.
3. What happens to the data? If individuals can be compared and ranked, trust will erode.
4. How does it handle AI? If it tries to track tool usage, it's already obsolete.
5. Does it help developers improve? If it's just measurement without coaching, it's surveillance with extra steps.

If you're a developer being subjected to these tools, know that you're not crazy. The metrics are meaningless. The surveillance does hurt. The best teams—the ones you probably want to work for—are rejecting this approach.

Join the Rebellion

We're building something different.

Not surveillance. Not productivity theater. Not vanity metrics that look good in board presentations but drive bad behavior.

We're building proof that your team is actually getting better.

It starts with measuring what matters: outcomes, not activity. Trends, not snapshots. Effectiveness, not productivity.

If you're tired of metrics that measure the wrong things, surveillance that destroys trust, and tools that become obsolete the moment someone opens an AI assistant—we should talk.

Sources