For years, engineering teams have tried to measure developer productivity.
The result?
A never-ending debate around commits, pull requests, lines of code, story points, and deployment frequency.
The problem is simple:
Most metrics are easy to collect.
Very few are actually useful.
The "Commits" Trap
Imagine two developers.
Developer A pushes 150 commits this week.
Developer B pushes only 25.
Who is more productive?
You simply can't know.
Developer A may be splitting every change into tiny commits.
Developer B may have solved the most critical architectural problem of the sprint.
The number alone tells you nothing.
The Problem Isn't Data
Modern engineering teams already have plenty of information.
GitHub
GitLab
Azure DevOps
Jira
SonarQube
CI/CD pipelines
Security scanners
The issue isn't collecting more metrics.
The issue is transforming thousands of events into actionable insights.
Metrics That Actually Matter
Instead of counting activity, I prefer looking at engineering health.
For example:
Pull Requests waiting too long for review
Contributors becoming isolated from the team
Repositories with increasing technical debt
Review workload imbalance
Security vulnerabilities left unresolved
Long-lived branches
Stale repositories
Release bottlenecks
None of these metrics evaluate a developer.
They evaluate how healthy your engineering system is.
The Goal Is Better Decisions
Metrics should never become a ranking system.
They should help Engineering Managers answer questions like:
Where should I focus today?
Which repositories are becoming risky?
Which teams need support?
Where is collaboration breaking down?
Good metrics create conversations.
Bad metrics create fear.
Building Devlyticks
While working as a Lead Engineer, I realized I was spending too much time navigating between GitHub, CI dashboards, security reports and spreadsheets.
I wanted one place capable of highlighting the few engineering signals that actually require attention.
That idea eventually became Devlyticks.
The objective isn't to monitor developers.
It's to help engineering leaders make better technical decisions with less effort.
I'm curious:
What engineering metric has been the most valuable for your team?
Top comments (0)