Why Measure Work at All?

Managers have always been interested in finding a universal and reliable way to measure how effectively someone works. That is understandable. Clear indicators make it easier to assess a team, plan growth, explain decisions, build reports, and avoid keeping everything in your head as a vague feeling that “this person seems to be doing fine, while something feels off about that one.”

In an ideal situation, employees benefit from this too. If someone is engaged in their work, measurements can make it easier to understand where to go next: which weaknesses to address, which strengths to develop, and where they already provide clear value to the team. Career growth also becomes less vague because there is a chance to discuss it through observable evidence instead of simply saying, “I am doing a great job.”

I will use the term “KPI” throughout this article, but I will not always mean key performance indicators in the strict sense. I am talking more broadly about any way of evaluating someone’s work: formal metrics, 360° reviews, code quality, estimation accuracy, feedback from colleagues, and similar things.

One caveat from the start: all of this only works with an engaged employee. If someone has no interest in improving, learning, or growing and is simply trying not to get fired, metrics become a completely different tool. I will return to this later because it is an important part of the discussion.

One more caveat: “seeing performance” does not mean “valuing performance fairly.” A company and its managers can use this information in very different ways. Sometimes pragmatically and honestly, sometimes strangely, sometimes emotionally, and sometimes in ways that are actively harmful. Measuring something does not guarantee a reasonable management decision.

Where the Problem Starts

KPIs can simplify many parts of running a company. You could even say they make employees’ lives easier if we lived in an ideal world.

But we do not live in an ideal world, so performance indicators almost always have an unpleasant side. A metric needs to be interpreted. A human interprets it. That person may not have the full context, may have personal biases, or may want to justify a decision they have already made. Almost any metric important enough to matter can also be gamed.

If people are evaluated by the number of completed tasks, they may start splitting tasks into smaller pieces or choosing only easy ones. If the company counts commits, people can commit more often. If it counts discovered bugs, every defect classification may turn into an argument. If it looks only at speed, quality will almost inevitably become the sacrifice.

This does not mean metrics are useless. A metric is simply not reality. It is a way of looking at one part of reality from a particular angle. Problems begin when that angle is declared an objective picture of someone’s entire contribution.

Why Developers Are Harder to Measure

There are many ways to evaluate performance, and many of them apply only to specific professions. A sales department can look at the number of signed contracts. Support can measure response time, answer quality, or the percentage of satisfied users. None of these metrics are perfect either, but at least it is reasonably clear where to look for direct indicators.

Developers are harder to evaluate. I am a developer myself, so the rest of this article will focus specifically on software engineers.

The result of a developer’s work is often indirect. A good developer may remove code instead of adding it. They may stop a bad architectural decision before it is implemented. They may spend a day investigating a strange bug that ultimately turns out to be outside their area of responsibility, even though the team would have spent another week going in circles without their help. They may leave a review that turns someone else’s task into a solid solution while receiving almost no credit in their own statistics.

The opposite is also possible. Someone can complete many tasks, write a lot of code, and respond enthusiastically in chats while leaving behind a fragile system that other people will have to repair. Formally, the person is busy and productive. In practice, the team receives debt that may not become visible immediately.

Code quality also depends on the standards accepted by the project. The higher the standards, the more time a task requires: tests, types, reviews, agreeing on an approach, migrations, and backward compatibility. If you compare only task completion speed, it is easy to punish someone for doing the work more carefully.

That is why KPIs for developers should be treated cautiously: more as a collection of signals that helps ask the right questions than as a scoreboard with a final result.

What Counts as an Objective Metric?

There is no need to start a philosophical discussion about what can truly be called objective. A more practical definition is enough for this article.

By relatively objective criteria, I mean those that either depend only weakly on the opinion of one particular person or combine information from several sources so that one person’s bias has less influence on the result. This does not make the criteria perfectly fair. It simply makes them harder to reduce entirely to sympathy, resentment, or a random impression.

For example, one manager’s personal opinion is a weak signal. The opinions of a manager and several colleagues, the history of code reviews, the number of tasks returned for changes, behavior during incidents, and the ability to estimate work reasonably are already better. The resulting picture can still be wrong, but it is less arbitrary.

Which Metrics Are Worth Looking At?

Work Predictability

One useful indicator is how accurately a developer estimates tasks and how they behave when an estimate starts slipping.

Missing an estimate should not be a problem by itself. New context constantly appears during software development: someone else’s code turns out to be worse than expected, requirements change, an integration behaves strangely, or tests uncover an old bug. The real problem does not begin when someone makes a mistake. It begins when they stay silent until the last moment, pretend everything is going according to plan, and reveal one day before the deadline that the task is nowhere near completion.

It is useful to look at more than estimation accuracy:

• does the person communicate risks in advance;
• can they break a large task into understandable stages;
• do they systematically inflate estimates simply so that people bother them less;
• do they underestimate tasks to create a better-looking picture;
• do they participate reasonably in team estimation, such as planning poker.

This is closer to actual effectiveness. The goal is not “this person always guesses the deadline correctly.” The goal is “we can plan work with this person without feeling as though the ground keeps turning into a swamp beneath us.”

Quality and Reliability

Code quality and the number of defects look like obvious metrics, but it is easy to do something stupid with them too.

It is not always clear who actually introduced a bug. One developer wrote the code, another changed a contract, a third reviewed it, a fourth modified a neighboring module, and the problem appeared only in production. If you simply assign the defect to the last person who touched the file, you can produce neat but largely meaningless statistics.

This does not mean quality cannot be evaluated. You can look for recurring patterns:

• tasks are repeatedly returned from review because of the same problems;
• changes made by the person regularly introduce regressions;
• they ignore agreements about style, tests, or architecture;
• they handle feedback badly and argue without addressing the substance;
• or, conversely, they consistently leave behind code that does not need to be rewritten a week later.

Code-quality metrics can also be integrated into CI: complexity, duplication, test coverage, linters, and static analysis. They are useful, but I would not turn any of them into a direct KPI on their own. High complexity can be a symptom of a bad solution, or it can honestly reflect a complicated domain. Low test coverage can be a problem, or it can be the result of a project only beginning to recover from a very old state.

These metrics work better as a reason to start a conversation: Why is this implemented this way? Can it be simpler? Why are there no tests? Why has the same review comment appeared for the third time?

360° Performance Reviews

A 360° review is not exactly a metric. It is a way of collecting information that is difficult to formalize. A developer is evaluated by several colleagues in different roles rather than by one person. Yes, this is subjective. But you cannot simply say that an opinion should be ignored because it is subjective.

Just as witness testimony can be valid evidence in court, feedback from colleagues can be a useful indicator here. It is not perfect or magical, but it can still be valuable.

The more people involved in the evaluation, the less the result depends on one conflict or one person’s sympathy. If most colleagues independently say that someone is difficult to work with, does not listen to arguments, damages communication, or regularly shifts responsibility, this is no longer just “someone did not like them.” It is a signal.

A 360° review works well for evaluating things such as:

• teamwork;
• leadership skills;
• communication;
• organizational skills;
• the ability to help others;
• attitude toward the project and the team.

A 360° review can also reveal technical patterns indirectly. Colleagues often know who regularly leaves behind problematic code, who systematically inflates estimates, who takes tasks and then disappears, and who helps resolve difficult situations. They may see this better than a manager, especially when that manager is far from the code.

A 360° review can also be ruined. Without anonymity, people will be cautious. Without a healthy feedback culture, the review becomes a popularity contest or a way to take revenge. If a manager has already chosen someone to blame, they can extract only the convenient fragments from the feedback. The tool itself may be reasonable while the result still depends on how honestly it is used.

Subjective Assessments

I would not put subjective metrics at the center of the system. One person’s opinion without statistics or context can be influenced too easily by maintaining a good relationship with that person. An employee’s self-assessment is also more useful as material for discussion than as a performance indicator.

A self-assessment can show how someone views their work: where they believe they are strong, where they have doubts, and what they consider their contribution. But turning this into a KPI creates a strange game. Some people will honestly underrate themselves, others will confidently overrate themselves, and some will simply write what they think management wants to hear.

What Definitely Should Not Be the Primary KPI

Some metrics look particularly satisfying in reports and work particularly badly as the main indicator.

The number of commits. This is easy to inflate. One person creates one reasonable commit, while another splits the same work into ten. The second person looks more active according to the number, even though the number says nothing useful.

Lines of code. This is even worse. A good solution may reduce the size of the codebase. A bad solution may add a thousand lines that will get in everyone’s way. Rewarding lines of code can accidentally reward bloating the project.

The number of completed tasks. This only works when tasks are roughly equal, and software-development tasks are almost never equal. A tiny UI text change and a migration of an old module can both count as “one completed task.” People will quickly understand which tasks are more profitable to take.

Story points. They are meant for planning, not for measuring individual performance. Turning them into a personal KPI makes the team start gaming estimates. At that point, normal planning can be buried because it stops being a team tool and becomes a tool for personal protection.

The number of bugs. This is also dangerous on its own. If you count only discovered bugs, people may start arguing about classification. If you count only bugs attributed to each developer, people will avoid risky parts of the system. Sometimes the most valuable person is precisely the one who works in the most unpleasant areas, where bugs are almost unavoidable.

All of these indicators can be used as additional signals. The problem begins when one of them becomes the primary metric and starts controlling people’s behavior.

What to Do With an Unengaged Employee

At the beginning, I deliberately focused on an engaged employee. For them, KPIs can work like a mirror: here is where you are strong, here is where you are falling behind, here is what the team notices, and here is where you can grow.

Things are different with an unengaged employee. KPIs do not make someone care. They can reveal symptoms: tasks are completed slowly, quality is poor, colleagues complain, and estimates constantly slip. But a spreadsheet does not turn indifference into motivation.

If someone only wants to avoid being fired, they will optimize for the metrics. They will not optimize for the project, quality, or the team. They will optimize for whatever is written in the rules. The simpler the metrics, the easier they are to game.

At that point, the issue is management rather than KPIs. Perhaps the project is a bad fit for the person. Perhaps they are burned out. Perhaps nobody explained the expectations properly. Perhaps they genuinely cannot handle the role. Perhaps the manager does not understand what they expect from the person either. KPIs can help record the problem, but they cannot replace a conversation and a decision.

How I Would Use KPIs

I would not try to find one primary performance indicator for a developer. I would look at several groups of signals and search for contradictions between them.

For example, someone completes tasks quickly but receives many review returns and introduces regressions. That requires one conversation.

Someone completes tasks more slowly than others but works in difficult parts of the system, fixes old problems, and leaves the code more stable. That requires a different conversation.

Someone writes code well, but the team constantly complains about their communication. That is a third conversation.

Someone is not the strongest developer technically, but they estimate risks well, help newcomers, and stabilize processes. This contribution also needs to be visible, or it is easy to underestimate them.

A good evaluation system should help ask questions instead of immediately issuing a verdict. If a metric looks strange, the first step is understanding why. If an indicator declines, you need to look at the context. If someone systematically games the rules, then the rules have become part of the game instead of a way to work better.

I would also carefully separate metrics used for development from metrics used for punishment or compensation. As soon as an indicator is tied directly to a bonus, promotion, or risk of dismissal, people begin to protect themselves. That is normal. Every incentive system works this way. The more serious the consequences, the more carefully the metric needs to be interpreted.

Conclusion

KPIs are not useless. It would be strange to deny the value of measurement simply because measurements can be used badly. Without metrics, a manager can easily fall back on personal impressions, while employees do not always understand what is expected of them.

But KPIs for developers work poorly as a universal truth. There is too much context: task complexity, code quality, support for the team, architectural decisions, reviews, incidents, communication, and the ability to raise a problem before it becomes critical.

That is why I would treat KPIs as a diagnostic tool. They can help identify an imbalance, start a conversation, notice a long-term trend, and compare expectations with reality. But when a manager decides that KPIs mean they no longer need to understand the team’s work, it starts to look like an attempt to replace management with a spreadsheet.

And that attempt, it seems, is what usually breaks everything.