Measuring engineering productivity without turning it into surveillance
The reason these tools get thrown out is rarely the maths. It is that the answer arrived in a shape nobody wanted to be on the wrong end of.
Every engineering measurement project starts from a reasonable question. A leader is accountable for whether the team is delivering and has no instrument for it beyond anecdote and the mood in a stand-up. That is a genuinely bad position to be in, and wanting a number is not a character flaw.
What happens next is almost always the same. Somebody buys a tool. The tool produces a ranked list of people. Within a month the list is being discussed in rooms the people on it are not in. Within a quarter the engineers have worked out what it counts and have started producing more of that. Within a year it is switched off, and the organization has learned the wrong lesson, that engineering cannot be measured, when what actually happened is narrower and more fixable.
The mistake is structural, not statistical. The question that was asked, is this team delivering, was answered with an artefact that ranks individuals. Those are different questions, and the first does not require the second.
Two questions that keep getting conflated
Is this team shipping, and is that changing? This is the question a leader is actually accountable for. It is answered entirely by aggregates. A team’s throughput this month against last month, its review latency, how often a release goes backwards. Nobody needs to be named for any of it, and naming people adds nothing to the answer.
Is this person doing well? This is a management question, and it is answered by a manager who has context: what the person was assigned, what they were blocked on, what they were quietly holding together. A dashboard cannot answer it and gets it wrong in a specific, predictable direction: it undervalues the reviewer, the mentor, the person who spent three weeks deleting code, and the person whose contribution was noticing early that a project should stop.
Almost every failure of this category of tool comes from using an instrument built for the first question to answer the second. Once you see them as separate, most of the design falls out.
What follows if you take that seriously
These are not sentiments. Each one is a thing you can check a tool for before you buy it.
- The default scope is the team. Not because individual data is forbidden, but because the default is what most organizations will still be running in a year. A tool whose out-of-the-box state is a ranked list of names has decided something on your behalf.
- Individual visibility is a decision somebody makes, and it is recorded. Whether people appear on a shared board is a setting. Who changed it, and when, is in a log that the application cannot rewrite. If the only record of a policy change is somebody remembering they made it, there is no policy.
- The rule is enforced where the data is, not where it is drawn. This is the one that separates products that mean it from products that gesture at it. If visibility is applied by the interface, the first person to call the API gets everything. It has to be in the query.
- A person can always see their own work. Hiding somebody’s own contribution from them is not privacy. It is a broken page, and it teaches people the system is being run against them.
- It measures what was already public. A merged pull request is visible to everyone with repository access. Counting it reveals nothing new. Reading somebody’s messages, tracking keystrokes, or inferring focus time from calendar gaps is a different activity wearing the same word.
The reason this is a commercial argument, not an ethical one
It would be easy to write the paragraph where measuring people is wrong and leave it there. The stronger argument is that surveillance-shaped measurement does not work, on its own terms, for the person who bought it.
A metric that determines how somebody is perceived stops describing reality within about two months. This is not cynicism about engineers; it is what any group of intelligent people does when told what counts. Pull requests get smaller. Reviews get shallower and faster. Refactors get deferred because they score badly. Nobody volunteers for the six-week integration nobody can see. The number goes up and the organization gets worse, which is the most expensive possible outcome because it is invisible for two more quarters.
Aggregate measurement degrades far more slowly, because a team gaming its own throughput number requires coordination, and coordinated gaming tends to surface as an obvious anomaly rather than a quiet drift.
A measure that changes how someone is treated will be optimized. A measure that only describes how a group is doing usually just gets looked at.
What to put in front of people instead
The half of this that most tools skip: the people doing the work need something out of it too, or the whole apparatus reads as extraction. Not a rank, since a rank is the thing we just spent this post avoiding, but acknowledgement.
A collection works where a score does not. Something a person accumulates and owns, made of items that say what they did rather than how they place. No ranking of who has the most: the moment there is one, you are back where you started. The same week’s work can answer a leader’s question in aggregate and leave the person who did it with something of their own, and the second half is what buys you permission for the first.
Whether the mechanism is cards or something else is a detail. The principle is not: if measurement flows in exactly one direction, from the people doing the work to the people evaluating them, it will be resented and eventually removed, regardless of how good the numbers are.
A short checklist
Before you roll anything out, four questions:
- If the ranked-list view were deleted tomorrow, could I still answer the question I bought this for? If yes, consider deleting it.
- Can an engineer see exactly what is recorded about them, without asking anyone?
- Is the visibility policy enforced in the data layer, or only in the interface?
- What does someone doing invisible, load-bearing work get out of this?
None of these are hard to satisfy. They are just easier to skip, and skipping them is why the category has the reputation it does.
More on the mechanics: which team metrics are worth tracking, how visibility is enforced inside the board query, why most workplace gamification fails within a quarter, and how to build a leaderboard that does not create the behaviour you were trying to avoid.