Someone on LinkedIn this week posted a dashboard showing lines of code per developer per sprint. Color-coded. Red for the “underperformers.” Green for the heroes. I wanted to throw my laptop out the window.
We’re in 2020. Half the industry just went remote overnight and managers are panicking. I get it. You can’t see people at their desks anymore. So now there’s this desperate scramble to measure something to prove people are working. And the tools are happy to sell you that something.
Lines of code is the worst offender but it’s far from the only one. Commits per day. Tickets closed. Story points completed. Velocity. All garbage when used to evaluate individual developer performance. Every single one.
Why these metrics are garbage
Here’s the thing. I once mass-deleted 12,000 lines of dead code from a Rails monolith in a single afternoon. Most productive day I’d had in months. By a lines-of-code metric, I went negative. Fire me, I guess.
Commits per day? I know devs who commit every time they save. I know devs who work on a complex problem for three days and push one beautiful, well-tested commit. The second developer is almost always doing better work.
Story points are the sneakiest one. They were invented as a planning tool. A way for teams to forecast how much they could take on. Somewhere along the way, managers started treating velocity as a performance metric. “Your velocity dropped this sprint, what happened?” What happened is Goodhart’s Law. The moment you use velocity to judge people, teams inflate their estimates. Suddenly a two-pointer becomes a five-pointer. Velocity goes up. Actual output stays the same. Everyone pretends not to notice.
I’ve watched this play out at three different companies now. Same story every time.
The only metrics I actually care about
DORA metrics. That’s it. Four numbers. Boring, validated by actual research, and extremely hard to game.
Deployment frequency. How often are you shipping to production? Not “how often are you merging PRs.” Actually shipping. If your team deploys once a month, you have a delivery problem. Fix it before you measure anything else.
Lead time for changes. From commit to production. This tells you how much friction is in your pipeline. Long lead times mean slow code review, flaky CI, painful deployments, or all three. Every one of those is worth fixing.
Change failure rate. What percentage of deployments cause a failure? This is the quality counterweight. You can’t just deploy fast and break everything. Well, you can. But this number will catch you.
Time to restore service. When something breaks, how fast do you fix it? This is the one that actually matters at 3am. And it tells you more about your team’s operational maturity than any sprint dashboard ever will.
These four together give you a real picture. Speed and stability. You can’t game them easily because they pull in opposite directions. Ship faster but break things? Your failure rate goes up. Over-index on stability? Your deployment frequency drops.
What I actually do
At my teams, I track DORA metrics at the team level. Not individual. Never individual. I don’t care which developer deployed what. I care whether the system is getting better or worse.
We look at the numbers monthly. Trend lines, not snapshots. If lead time is creeping up, we dig into why. Usually it’s a CI problem or a review bottleneck. Fix the system, not the people.
I also ask one question in retros: “What slowed you down this week?” The answers are always more useful than any dashboard. Flaky tests. Unclear requirements. Waiting two days for a review. That’s where the real productivity wins are hiding.
Stop measuring people, fix the system
The entire premise of individual developer productivity metrics is broken. Software is collaborative. The best developer on your team might spend half their time unblocking others, reviewing code, and mentoring juniors. By any activity metric, they look “less productive” than the person grinding out solo features. But remove them and watch the whole team slow down.
If your response to remote work is to install monitoring software or build LOC dashboards, you don’t have a productivity problem. You have a trust problem. And no metric is going to fix that.
Measure the system. Use DORA. Fix the bottlenecks. Talk to your team. Everything else is theater.