How to Audit Engineering Output without Gaming Internal Metrics

Engineering Leadership & Auditing

How to Audit Engineering Output without Gaming Internal Metrics

Escaping the treadmill of artificial velocity and the “Velocity Tax” through verifiable, evidence-based delivery.

Eighteen percent. That is the number the Vice President of Engineering will present to the board on to justify the current burn rate. It is a precise number, a comforting number, and a number that everyone in the engineering organization knows is a total fabrication.

18%

The “Comforting Fabrication” presented to the board

Velocity is up, the charts are climbing at a healthy clip, and the Jira dashboard looks like a staircase to heaven, yet the two core features promised for the October release are still nowhere to be seen. The team is running faster and faster on a treadmill that has been disconnected from the gears of the actual business.

The Dulce de Leche Epiphany

A 14-inch MacBook Pro, a half-eaten Häagen-Dazs Dulce de Leche pint, and a sticky stainless steel spoon rested on the kitchen island when the realization hit like a physical weight. I had just taken a massive bite of the ice cream, seeking a moment of sugary solace between back-to-back planning sessions, when the resulting brain freeze collided with a sudden, sharp clarity: we are all participating in a mass hallucination.

We have invented a unit of measurement that nobody can audit and everyone can inflate, and we are surprised when the reality of the product doesn’t match the fiction of the spreadsheet.

The scene repeats itself every Wednesday morning across a thousand Zoom calls. Eight faces in little boxes stare at a shared screen displaying a backlog of tickets that never seems to shrink. A ticket comes up for discussion-the same authentication refactor that has appeared in three different guises over the last six months.

Sprint 1 Estimate

3 pts

Sprint 2 Re-evaluation

5 pts

Today’s “Reality”

8 pts

Two sprints ago, the team estimated it at three story points. It didn’t get finished. Last sprint, it was moved over and re-evaluated as a five. Today, a senior developer looks at the description, sighs into a Blue Yeti microphone, and says it looks like an eight. The Tech Lead nods, the Product Owner agrees, and the ticket is updated. In one click, the team has “created” five points of velocity out of thin air without writing a single line of code.

Inflation as an Economic Response

The standard critique of story points is that they are poor estimates of time. That is an observation so gentle it borders on the dishonest: story points are not estimates at all, but rather an internal currency with no central bank.

Because the teams issuing the currency are the same teams reporting on the value of that currency, inflation is the only rational economic response. If the leadership team demands a twenty percent increase in productivity, and the only tool the team has to demonstrate that productivity is a self-defined unit of “effort,” they will naturally recalibrate what “effort” looks like. It is not misconduct; it is survival in a system that rewards the movement of a needle rather than the delivery of a result.

Iris S.-J., a grief counselor I’ve known for nearly a decade, once explained to me how families in crisis develop their own coded languages. When the standard vocabulary for pain or progress becomes too heavy to carry, they invent clinical distances.

“They stop saying they are ‘hurting’ and start saying they are ‘experiencing a four-out-of-ten on the distress scale.’ It feels more manageable because it feels more objective, but eventually, the numbers lose their tether to the feeling.”

– Iris S.-J., Grief Counselor

A “four” becomes a “six” just so the doctor will listen, and soon the scale is meaningless. Engineering teams do the exact same thing with their technical debt-they quantify it to make the chaos feel like a manageable metric, but the quantification itself becomes the object of the game.

The Weight of the Soviet Nail

The problem of gamed metrics is not a modern software phenomenon; it is a fundamental flaw in human systems of measurement. During the , Soviet nail factories were often given quotas based on weight. Predictably, the factories began producing enormous, heavy nails that were entirely useless for most construction but allowed the factory managers to hit their targets with half the effort.

Quota Type

Weight

Result: Giant useless spikes

Quota Type

Count

Result: Tiny fragile pins

When the central planners caught on and changed the quota to the number of nails produced, the factories shifted to making millions of tiny, fragile pins that would snap under the pressure of a hammer. The managers weren’t trying to sabotage the state: they were simply optimizing for the metric that determined their funding and their safety.

In a modern engineering context, story points are the heavy nails. They are a proxy for value that can be manipulated without actually increasing the utility of the system.

The Reality Gap and the Velocity Tax

The damage is not just that the charts are inflated, but that the leadership team loses its last honest instrument for decision-making. When a CTO can no longer tell the difference between a team that is genuinely accelerating and a team that has simply learned to call a three-point task an eight-point task, they can no longer make informed bets on the future of the company.

A Patagonia Better Sweater, a titanium Apple Watch Series 7, and a lukewarm Nespresso Vertuo capsule sat beside the CTO’s monitor as he stared at the velocity report. He knows the features are late, but the report says they are “on track” because the point-burn is high.

One reality exists in the code repository and the customer feedback loops; the other exists in the quarterly business review. The wider the gap between these two worlds, the more likely the organization is to experience a catastrophic failure of trust.

The Pivot to External Verifiability

True delivery is not an internal sentiment; it is an external event. To escape the trap of internal currency, an organization must shift its gaze toward metrics that are verifiable by an outside observer. This is why high-performing teams have moved away from subjective “points” and toward DORA metrics:

Lead Time

for changes

Frequency

of deployment

MTTR

time to restore

Failure Rate

of changes

These are not opinions. You either deployed to production today or you did not. The code either worked or it broke. You cannot “call” a two-day lead time a four-day lead time to make yourself look better; the timestamps in the repository do not lie.

This insistence on external verifiability is the core philosophy of Limestone Digital, which prioritizes evidence-based delivery over the theater of sprint points.

By embedding delivery pods directly into a client’s repository and release pipeline, they force a confrontation with reality. You cannot inflate the velocity of a feature that hasn’t been merged. When the metrics are tied to the actual movement of code from a developer’s machine to a user’s screen, the incentive to game the system evaporates. The goal shifts from making the chart look pretty to making the software work.

The Heaviest Nail

“The heaviest nail in the bucket is often the one that holds nothing to the wall.”

Most mid-sized, private-equity-backed companies are operating in a state of measurement debt. They have inherited legacy codebases and legacy processes where the only way to get a “win” is to massage the numbers. A Head of Platform might be under immense pressure to show that the offshore team they just absorbed is performing, so they subconsciously encourage the drift.

They become the “central bank” that turns a blind eye to the printing of more points, hoping that eventually, the “wealth” of points will translate into a real-world product. But inflation doesn’t create value; it only hides the lack of it until the currency collapses.

Restoring Action to the Engineering Room

The individual contributors within these teams are usually the most frustrated. Developers, by and large, want to build things that matter. They don’t want to spend forty minutes of a planning session arguing over whether a bug fix is a “fibonacci five” or a “t-shirt size medium.”

They know that the time spent on the estimation game is time stolen from the IDE. When an organization moves to a more transparent, verifiable model of delivery, the relief in the engineering room is often palpable. The “language of loss” that Iris described is replaced by a language of action.

We have to stop treating engineering as a closed system where the inputs and outputs are defined by the same people. If a CFO were allowed to invent their own accounting standards and then audit their own books without any external verification, they would be in prison.

When the eighteen percent improvement is presented on , there will be nodding. There will be polite questions about the roadmap. But the real audit will happen from now, when the market asks where the features are.

At that point, the points won’t matter, the charts won’t matter, and the heavy nails will be seen for exactly what they are-dead weight in a bucket that was supposed to be full of progress.

The only way to win is to stop playing the game of internal currency and start measuring what actually moves the needle: the code that makes it to the user.