Long, long ago—and I promise this was not recent—I had a manager who kept telling me I needed to start my tickets earlier in the sprint.
I had no idea what they were talking about.
Unless something had carried over from the previous sprint or an emergency came up, I was already starting new work at the beginning of the sprint. My tickets were getting done on time, and we were not routinely carrying work over. Nothing about my actual workflow matched the feedback I was getting.
This went on for months.
Eventually, I realized the question I should have asked much earlier: Where were they getting this information?
It was the ticketing system.
I was starting the work. I was not always remembering to immediately move the ticket to “In Progress.” Sometimes it took me a day or two. Nobody working directly with me considered this much of a problem because the work itself was happening and getting done on time.
But somewhere along the way, the metric had stopped being treated as a representation of reality and started being treated as reality.
Measurement
“We use ticket status as an approximation of when work begins.”
Perfectly reasonable.
Metric management
“We need people to update ticket statuses consistently because stakeholders use this data for reporting.”
Also perfectly reasonable.
Metric literalism
“The ticket says you started Wednesday; therefore, you started Wednesday.”
Now we have a problem.
Because once the metric is mistaken for reality, the next step is usually optimization.
“If engineers started their tickets earlier, they would finish earlier and could take on more tickets.”
Except I was starting earlier, so they were attempting to improve a behavior that was not actually occurring.
This is where Goodhart’s Law starts lurking around the corner: When a measure becomes a target, it tends to stop being a useful measure.
And there is another wrinkle here that gets missed surprisingly often.
If a manager is being evaluated on a metric, that means someone above them wants that metric to improve. So the pressure moves downward until the team is explicitly told to change how the work is represented.
Maybe QA is told to open fewer defect tickets.
Maybe test-code-coverage reports get taken too literally.
Maybe velocity points inflate or deflate a bit.
At that point, the team is not secretly gaming the metric. They have been instructed to optimize it.
For example, today I could write an agent that automatically moves every ticket assigned to me into “In Progress” at the beginning of every sprint.
That particular statistic would improve immediately.
That is the danger.
Some dashboard may show a real change in a metric. The number may genuinely move in the desired direction. But once organizations begin optimizing the proxy instead of the outcome, they can create the appearance of improvement without producing a meaningful change.