Metrics are supposed to bring clarity.
They help teams decide what to prioritize, what to improve, what to cut. They translate behavior into numbers. They promise objectivity.
But metrics don’t just measure products — they shape them.
Over time, the wrong metrics can quietly distort incentives, architecture, and even ethics without anyone explicitly deciding to compromise anything.
What gets measured gets optimized
In most modern software teams, a small set of numbers dominates internal conversations:
- Daily Active Users
- Retention
- Session duration
- Engagement rate
- Conversion percentages
These figures aren’t inherently harmful — they are useful signals. The problem begins when they become the primary definition of success.
Once a team aligns itself around increasing engagement, the product starts to reorganize itself around that goal. Notifications become more frequent. Feeds become infinite. Defaults become stickier. Friction is removed — but only where it increases measurable activity.
The system begins optimizing behavior rather than serving intention.
Engagement over trust
Metric optimization rarely feels disruptive in isolation. One experiment improves click-through rate. Another redesign lifts session length. An algorithm tweak boosts watch time.
Each change seems justified. Each improvement, statistically validated.
But over time, the cumulative effect can shift the moral center of a product. The incentive moves from helping users complete tasks to keeping users engaged. That shift is structural, not cosmetic.
A similar tension can be found when persuasive design aligns with growth metrics — something explored in persuasion-based UX design failure. When persuasion strategies are rewarded numerically, the product reinforces itself around attention.
Trust, by comparison, is difficult to quantify.
When stability outcompetes stimulation
It’s far simpler to track session time than to measure long-term confidence. Easier to optimize for immediate clicks than to optimize for stability across years.
And yet, stability compounds in ways that spikes never do.
Consistent behavior builds durable mental models. Users learn what to expect. Designers learn what remains constant. That long-term trust and continuity are themes covered in predictable software trust.
Metrics reward spikes.
Resilience rewards continuity.
Software designed to chase immediate numbers tends to age unevenly.
Metrics and architecture
Metrics can also distort system design itself.
If uptime or deployment frequency is the dominant KPI, teams may prioritize quick patching over structural redesign. If release velocity is rewarded, review discipline may lag.
Optimization becomes local. Architecture becomes reactive.
This dynamic echoes the broader idea behind foundational engineering in what secure-by-design software means. When system safety isn’t just measured by outputs but embedded structurally, it may slow short-term metrics — but it reduces long-term exposure.
Invisible constraints rarely get rewarded on dashboards.
The case of unintended consequences
History provides enough cautionary examples.
When platforms optimized for watch time, more extreme content often performed better. When ride-sharing platforms optimized driver utilization, working conditions became unstable. When growth teams pursued increasingly aggressive retention targets, data collection expanded and privacy faded.
In each case, no one needed to declare an unethical objective.
The metric did the steering.
Once incentives are encoded numerically, they shape decision-making far beyond their original scope.
What metrics fail to see
Metrics measure outputs.
They rarely capture:
- Cognitive fatigue
- Loss of user agency
- Long-term trust erosion
- Dependency risk
- Architectural fragility
These are slower variables, harder to graph and harder to justify in quarterly reports.
But they often determine whether software remains respected years later.
A product can show strong engagement and still accumulate invisible debt — ethical, architectural, or relational. And when that debt surfaces, it tends to happen suddenly.
Choosing what not to optimize
The solution isn’t to abandon measurement.
It’s to recognize that every metric is a value statement.
If you optimize for engagement, you will design for attention.
If you optimize for retention, you will design for stickiness.
If you optimize for growth, you will design for expansion.
The question becomes: what are you willing to sacrifice?
Good software is often destroyed not by bad intentions, but by narrow optimization.
Metrics don’t merely reflect priorities —
they create them.
And once they drift too far from durable values, reversing that drift becomes as difficult as rebuilding trust itself — a dynamic explored in trust cannot be rebuilt.