No metrics is better than vanity metrics

In software, we are addicted to determinism. It takes minutes to integrate tools like DataDog or NewRelic and gain total visibility into the health of our machines. Many managers believe it is just as easy and effective to apply this same approach to human beings. They are wrong. If you treat engineers as gears in a deterministic system, you will only produce fake data and slow processes.

I have seen too many organizations fall into the "measurement theater" trap for two reasons:

1. Metrics as a shield: When things go wrong, metrics are implemented before solving the actual problem. It is a way to buy time, delegating the solution to a "magic oracle" that doesn't exist.
2. Metrics as justification: When leadership lacks a clear direction, they introduce aggressive KPIs to justify budgets, bonuses, or tech spend to the board.

In both cases, the effect is identical: you are adding decision latency to an already congested system.

The Illusion of the Magic Oracle

Implementing serious metrics takes time—and even more time to generate a statistically relevant dataset. If you have a fire and decide to install a thermometer before using the extinguisher, you aren't doing engineering; you are doing bureaucracy.

The paradox is that teams in crisis often report "green" metrics in surveys. In low-transparency cultures where failure is punished, engineers will rate everything a "4.5" just to be left alone. If your dashboards are perfect but your delivery is stagnant, your data is fake.

The AI Surveillance Drift

Today, many big tech companies are making a fatal mistake: measuring AI adoption by asking developers to manually fill out Jira fields or by imposing arbitrary quotas of machine-generated code.

This is managerial witchcraft. Instead of linking the tool to value, you are measuring the tool itself. The result is Goodhart’s Law in action: "When a measure becomes a target, it ceases to be a good measure." Engineers will game the system: they will produce mediocre code just to meet the quota. You get your metric, but you destroy the business. You have decoupled behavior from value.

Team Topologies and Business KPIs: The Key to Scale

The only way out of this trap is to stop seeing engineering as an isolated silo. Engineering is an arm of the business.

True scalability is not achieved by tracking commits, but by aligning team topologies with business KPIs.

• If a team has a clear business objective (e.g., "reduce churn by 5%" or "increase checkout conversion by 2%"), they will naturally become autonomous and productive.
• When a team has Skin in the Game regarding the final outcome, you no longer need to measure how many hours they spend on Jira or how much AI they use. They will use whatever tool is necessary to win, because their success is tied to the company's success.

The Economic Cost of Metrics (No Free Lunch)

Every metric you add has a cost:

• Implementation: Time stolen from value creation.
• Cognitive Load: Bureaucracy that kills the creativity of your seniors.
• Analysis: Someone has to read that data, often generating more useless meetings.

In a context where no one truly knows how long it takes to build a complex feature, measuring the "means" (lines of code, time spent) is pure velocity sabotage.

From Top-Down to Bottom-Up (DX)

If you must measure, use lightweight approaches like the Developer Experience (DX) framework. Don't ask "how happy are you?"; ask "what technical blockers are stopping you from producing value?".

Shift the focus from top-down management "crushing" the teams to a bottom-up system where the builders surface the bottlenecks. Asking the people who touch the code where the system is broken works infinitely better than imposing processes to measure their alleged speed.

What's next?

If your goal is to reclaim real control—the kind needed to scale an organization by 250% without watching it implode—you need to move from managing people to architecting autonomy.

Read about Orchestrating Mitosis here.