If you run a business with a development team but cannot read code yourself, measuring developer productivity feels almost impossible. You cannot look over their shoulders and judge whether the work is good. So you reach for numbers that seem objective: lines of code written, number of commits, hours logged, tickets closed. These feel like management. They are mostly a trap.
Here is the hard truth about measuring developer productivity with activity metrics. Every one of them is gameable, and the moment your team knows you are watching that number, they will optimize the number instead of the outcome. You will get more lines of code and worse software. You will get more commits and slower progress. The metric improves while the actual business result quietly gets worse.
I have managed engineering teams and I have watched good owners damage good teams with the wrong measurements. The good news is that you can meaningfully judge a development team without reading a single line of code. You just have to measure the right things, and none of them are about activity.
Why Activity Metrics Lie
The appeal of activity metrics is that they are easy to count. That is also exactly why they mislead. Software is not produced by volume of typing. It is produced by solving problems, and solving a problem well often means writing less, not more.
Consider the classics:
- Lines of code. More lines usually means more complexity, more bugs, and more to maintain. The best engineers routinely delete code and simplify. Rewarding lines of code punishes exactly the behavior you want.
- Number of commits. Trivially gamed by committing more often. It tells you nothing about whether anything valuable moved.
- Hours logged. Rewards presence, not results. A developer who solves a problem in two hours produced more value than one who struggled at it for two days, yet the metric ranks them backwards.
- Tickets closed. Encourages splitting work into many tiny tickets or picking easy ones, while the hard, important problem sits untouched.
The common failure is that each of these measures effort, and effort is not the product. Nobody is paying you for effort. They are paying for working software that solves a real problem. This is the same reasoning I use in When NOT to Automate: A Contrarian Checklist. Measure the outcome, not the motion.
What You Can Actually Observe
You do not need to understand the code to observe how a healthy team behaves. Three signals tell you almost everything, and none require technical knowledge.
1. How often value ships
The single best signal is cadence: how regularly does something useful reach your customers or your operation? A team that ships small, valuable improvements every week or two is almost always healthier than one that disappears for three months and emerges with a big risky release.
You do not need to judge the code. You need to see the result: a new feature live, a bug fixed in production, a workflow that now works better. Frequent, steady delivery is hard to fake, because it requires the whole machine to actually work.
2. How long a small change takes end to end
Pick something small and clearly valuable. Time it from "we decided to do this" to "it is live and working." This is cycle time, and it is one of the most honest measures of a team's health.
A team that can take a small, agreed change to production in days is in good shape. A team where the same small change takes many weeks has a problem somewhere: unclear process, fragile code, too much manual work, or a bottleneck. You do not need to know which. You just need to notice that small things move slowly, and ask why.
3. How the team handles incidents
Things break. That is normal. What matters is the response. When something goes wrong in production, watch:
- How fast do they notice? Did they catch it, or did a customer tell them?
- How fast do they recover? Minutes, hours, or days?
- Does the same failure keep happening, or do they fix the root cause so it does not return?
A team that detects issues early, recovers quickly, and prevents repeats is a mature team, regardless of what their code looks like. A team that is constantly firefighting the same problems is telling you something is wrong beneath the surface.
The Metrics Worth Watching, Side by Side
| Instead of this | Watch this |
|---|---|
| Lines of code | Working features shipped |
| Number of commits | How often value reaches users |
| Hours logged | Cycle time on a small change |
| Tickets closed | Whether the important problem got solved |
| Individual output | Team delivery and incident recovery |
Notice the pattern. The left column measures individual activity. The right column measures team outcomes. Software is a team sport, and rewarding individual activity tends to fracture the collaboration that actually produces results.
Trust Plus Cadence Beats Surveillance
There is a management instinct, especially when you cannot see the work directly, to compensate with monitoring. Track everything, measure everyone, watch the dashboards. It feels like control. It produces the opposite.
Developers are knowledge workers solving novel problems. Surveillance signals that you do not trust them, and distrusted teams protect themselves: they pad estimates, avoid risk, game whatever metric you chose, and stop telling you the truth about problems. You end up with worse information and worse work.
The alternative is trust anchored by cadence. Give the team autonomy over how they work, and hold them to a rhythm of visible, regular delivery. You are not watching keystrokes. You are watching results arrive on a predictable beat. When the beat slips, you have a conversation, not a spreadsheet audit. Understanding how AI tooling is reshaping this work helps too, which I cover in Coding With AI: What Actually Changes for Dev Teams.
The Practical Takeaway
Measuring developer productivity by activity is measuring the wrong thing with false precision. It rewards volume over value and erodes the trust that good teams run on.
- Stop counting lines of code, commits, and hours. They are gameable and misleading.
- Watch how often value actually ships. Steady cadence is the strongest signal.
- Time a small change end to end. Slow small changes reveal deep problems.
- Judge the team by how they handle incidents, not by how much they type.
- Choose trust plus a delivery rhythm over surveillance every time.
You can lead a development team well without reading code. You just have to measure outcomes instead of motion, and let a visible cadence do the talking. If you want a technically fluent partner to help you read what your team is actually telling you, that is a role I take on through a technical partnership.