My friend Jiri Knesl and his team have developed a tool that tracks developers’ time and other metrics like number of commits. He claims that he wants to sell it as a tool that helps managers with decision making – he specifically mentioned (in a private conversation) “to decide who to keep and who to fire”.
With all due respect to the effort that went into creating such a tool, I think it is a bad idea.
Measuring individual developer time and trying to reduce it to a bunch of numbers (number of commits, number of tasks, average LOC in a PR, average hours spent on this and that) obscures the real nature of product development – a collaborative effort to create something useful for the customer.
Imagine you start measuring all organisms in the forest and decide to keep only the best individuals – for example, the tallest trees. Would you have a forest after some time? Of course not. Forests are not just trees, let alone the tallest trees.
One of Jiri’s arguments is that he doesn’t want to use one metric but multiple ones. As if I would decide that I only keep the tallest or fastest moving or the greenest individuals in the forest. I claim I would still not get the forest.
But (I hear Jiri’s voice in my head) this is not what I propose. A manager doesn’t need to focus on one metric of the many, she can look at the combination of them to make her decision. But combining metrics means we again reduce them to one number (however this combination may be implicit in the manager’s head).
What happens next? Well, developers are much smarter than trees, so they will adapt. (Even when they do not care about their visibility too much, it still matters to them.) They will try to estimate the number in the manager’s head and change their behavior so that their number goes up and they get higher remuneration.
Yes, says the manager using the tool, that’s exactly what I want – I want them to change their behavior. And it might even work for a while – changing individual behavior in a certain direction may improve the company productivity for a while.
Robert Austin has written a book that answers many questions discussed in this article and gives clear guidance on how it will continue: If developers continue optimizing for their individual “productivity” (and they will), it starts harming the company instead of helping.
After some time you get what you measure – a company full of standard-conformant developers who try to fit their tasks into the limits given by their boss and do not care too much about helping others and the work that needs to be done together.
I am pretty sure that some managers will love the tool, especially if you equip it with charts, dashboards, and AI stuff. I am pretty sure that using such a tool will harm the company in the long term. And I am pretty sure I wouldn’t want to work for a company using this tool as a developer.
This article has been originally published on Linked and Jiri has reacted to it in another LinkedIn article.
Robert Batusek is a software development consultant with 20+ years of experience in the industry, a Certified LeSS Trainer, and a technical coach. He helps companies simplify product development with multiple teams and use technical excellence practices to keep their product development sustainable in the long run.
