I have a confession: For years, I was obsessed with developer activity metrics.
Commits per week. Lines of code. Tickets closed. Pull requests opened. I had dashboards. I tracked trends. I compared team members. I thought I was being data-driven.
I was wrong.
The Wake-Up Call
Last year, one of my best engineers - let’s call her Priya - had a terrible quarter by traditional activity metrics. Her commit count was way down. She closed fewer tickets than usual. In our old world, this would have triggered a performance conversation.
But here’s what actually happened:
Priya spent 8 weeks refactoring our payment processing system. She reduced our payment failure rate from 2.3% to 0.4%. This saved the company approximately $180,000 per quarter in lost revenue and reduced customer support tickets by 40%.
Her git activity? 47 commits over 8 weeks. About 6 commits per week. Bottom quartile of the team.
Her business impact? Probably the highest of anyone that quarter.
If I’d been managing by activity metrics, I would have completely missed - or worse, punished - the most valuable work happening on my team.
That’s when I realized: Activity metrics don’t measure what actually matters.
What’s Wrong With Activity Metrics
The research backs this up. Remote work thrives on measuring outcomes instead of monitoring inputs. Performance-driven cultures far outperform time-driven ones.
But beyond the research, here’s what I’ve learned from experience:
-
Activity metrics reward the wrong behaviors. They incentivize quick fixes over root cause solutions. They favor visible work over deep technical work. They push engineers to close tickets fast rather than solve problems well.
-
Activity metrics are gamed easily. Smart engineers figure out the metrics and optimize for them. More commits? Okay, I’ll make 10 small commits instead of 1 thoughtful one. More PRs? I’ll split my work into tiny pieces.
-
Activity metrics create surveillance culture. When you measure activity, you signal that you don’t trust your team. This destroys psychological safety and autonomy - the very things that make high-performing teams work.
-
Activity metrics miss the most valuable work. The engineer who prevents a major outage with careful code review. The senior dev who mentors junior teammates. The architect who designs a system that avoids technical debt. None of this shows up in commit counts.
The New Framework: Measuring Impact
After the Priya wake-up call, I spent months researching how other engineering leaders think about performance. I read the GitLab handbook cover to cover. I talked to VPs and Directors at companies I respect.
Here’s the framework I landed on. We now measure engineers across four dimensions:
1. Customer Impact
- Features shipped that users actually adopt
- Bugs fixed that were affecting customers
- Performance improvements (page load time, API latency, etc.)
- Reliability improvements (uptime, error rates, incident reduction)
Key question: Did this engineer make our product better for customers?
2. Code Quality
- Test coverage of their code
- Incident reduction in their areas of ownership
- Documentation quality (can others understand and maintain their work?)
- Technical debt addressed vs. created
Key question: Did this engineer make our codebase healthier?
3. Collaboration
- Quality of code reviews (catching bugs, teaching others, improving designs)
- Knowledge sharing (documentation, tech talks, mentoring)
- Cross-team collaboration (helping other teams succeed)
- Unblocking others (answering questions, pair programming)
Key question: Did this engineer make the whole team better?
4. Innovation
- Technical debt reduction initiatives
- Process improvements (CI/CD, tooling, developer experience)
- New capabilities that enable the business
- Proactive problem identification and solutions
Key question: Did this engineer move us forward strategically?
How We Actually Measure This
The honest truth: This is harder to measure than counting commits. It requires judgment. It’s not automated.
But that’s the point. Managing humans requires human judgment.
Here’s our process:
-
Quarterly Impact Reviews: Each engineer writes a self-assessment documenting their impact across the four dimensions. They include specific examples, metrics where available, and testimonials from collaborators.
-
Peer Feedback: We collect 360 feedback from teammates. Focused on collaboration and impact, not popularity.
-
Manager Assessment: I review their work through the lens of business outcomes. I look at what shipped, what broke, what improved.
-
Calibration: Engineering managers meet to calibrate ratings and ensure consistency across teams.
Yes, this takes more time than looking at a dashboard. But it results in fairer, more accurate assessments that actually correlate with what we care about.
The Cultural Shift
Moving from activity to impact required a cultural change, not just a process change.
We had to shift from:
- Surveillance to trust: We trust engineers to manage their time and work. We evaluate outcomes, not hours or apparent busyness.
- Inputs to outputs: We care what you delivered, not how many times you committed code.
- Individual to team: We recognize that making your teammates better is as valuable as shipping code yourself.
- Short-term to long-term: We reward engineers who pay down technical debt and improve our foundation, even if it doesn’t ship customer features this quarter.
This shift was uncomfortable for some managers (including me at first). It’s easier to point to a chart showing commits per week than to articulate why someone’s work had strategic impact.
But that discomfort is the work of leadership. If management were just about reading dashboards, we wouldn’t need managers.
The Results
Six months into this framework:
- Higher morale: Our engineering engagement scores went from 7.2 to 8.4 (out of 10)
- Better retention: We’ve lost zero senior engineers in 6 months (previous year we lost 4)
- More ownership: Engineers proactively tackle important problems without being asked
- Better technical decisions: Less pressure to ship fast means better architecture
The Hard Part: Low Performers
One valid pushback I get: “How do you identify low performers without activity data?”
Honest answer: Low performers are usually obvious.
If someone is genuinely underperforming, you see it in outcomes:
- Their features ship late or buggy
- Their code review feedback is consistently about basic issues
- They don’t help teammates or contribute to team health
- They don’t grow in skills or take on more responsibility
You don’t need a commit count to see this. In fact, activity metrics often hide low performance - someone can be very busy while delivering little value.
The real performance conversations happen based on impact, not activity. And those conversations are more productive because they’re grounded in what actually matters to the business.
Remote Work Is Incompatible With Activity Monitoring
Here’s my strongest belief: If you’re managing remote teams with activity metrics, you’re set up for failure.
Remote work requires trust and autonomy. Activity monitoring signals distrust. These are fundamentally incompatible.
The beauty of remote work is that people can work when they’re most productive, take breaks when they need them, and integrate work with life in healthy ways. But this only works if you measure outcomes, not activity.
If you’re tracking commits, keyboard activity, or online time, you’re recreating the worst parts of office culture (surveillance and presence theater) without the benefits (spontaneous collaboration and connection).
My Challenge to Other Leaders
If you’re currently using activity metrics to evaluate your engineers, I challenge you:
Pick your highest performer. Now look at their activity metrics. Do the numbers reflect their actual value?
Pick your most frustrating underperformer. Do their activity metrics show the problem clearly?
I bet the answer to both is no.
Activity metrics are a crutch. They give us the illusion of objectivity while actually obscuring what matters.
Measuring impact is harder. It requires knowing your business, understanding your product, and actually managing your people. But that’s the job.
What are you measuring? How do you think about performance for remote engineers?