Goodhart's Law Is a Math Problem - And We Can Prove It With 10 Lines of Python

#ai #python #startup #automation

Your dashboard is lying to you - and we can prove it mathematically.
The Pattern You've Seen Before
You've lived this story. Every engineer has.
Quarter starts. Leadership announces a new KPI: engineering velocity, measured in story points shipped per sprint. The dashboards go up. The Slack bot starts posting weekly leaderboards. Managers nod approvingly at the upward-trending graphs.
Six months later, velocity is through the roof. And the product is falling apart.
What happened? The engineers did exactly what the system incentivized: they broke large tasks into dozens of tiny tickets, inflated point estimates, shipped half-baked features, and avoided refactoring because it doesn't "ship points." The metric went up. The thing it was supposed to measure - actual engineering output - collapsed.
This is Goodhart's Law : "When a measure becomes a target, it ceases to be a good measure."
You've seen the same pattern everywhere:
Wells Fargo (2016): Employees opened 3.5 million fake bank accounts to hit cross-selling targets. The metric said the company was thriving. The company was committing fraud.
Amazon delivery drivers : Optimizing for "packages per hour" led to drivers skipping bathroom breaks, cutting safety corners, and hiding damaged packages rather than reporting them.
Standardized testing in schools : Teachers "teach to the test." Test scores go up. Actual education quality stagnates or declines.
Google's 20% time : Once managers started evaluating promotion cases partly on 20% project output, engineers stopped experimenting and started doing "safe" projects that would look good in a review.
Most writing about Goodhart's Law treats it as a management philosophy problem - something you fix with "better culture" or "more nuanced metrics." But what if it's not a culture problem at all?
What if it's a math problem - and we can prove it?
The Math Behind the Madness
Here's the core claim: certain pairs of business metrics are fundamentally incompatible for simultaneous optimization. Not because we lack the right dashboard, not because our engineers are gaming the system, but because of the mathematical structure of the metrics themselves.
This is the same math that governs quantum physics. In quantum mechanics, Werner Heisenberg proved that you cannot simultaneously know a particle's exact position and exact momentum. The act of measuring one physically disturbs the other. This isn't a limitation of our instruments - it's a property of the universe.
The same structure applies to organizations.
Let's prove it.
The Proof: 10 Lines That Change How You Think About KPIs
We'll use Python's SymPy library, which has a quantum mechanics module for working with non-commutative operators. The key idea: if two quantities are represented by operators that don't commute (i.e., the order in which you apply them matters), then they are subject to an uncertainty principle.
python
from sympy.physics.quantum import Operator, Commutator
from sympy import symbols, I
Model two business metrics as non-commutative operators
Velocity = Operator('Velocity') # e.g., sprint points shipped per week
Quality = Operator('Quality') # e.g., code quality, defect rate, tech debt
The organizational "uncertainty constant" - how much measuring
one metric disturbs the other. This is organization-specific.
hbar_org = symbols('hbar_org', real=True, positive=True)
The critical question: does measuring Velocity leave Quality untouched?
Compute the commutator [Velocity, Quality]:
comm = Commutator(Velocity, Quality)
result = comm.doit()
print(f"[Velocity, Quality] = {result}")
Output: Velocity*Quality - Quality*Velocity
This is NOT zero.
The order matters. Measuring Velocity first, then Quality,
gives a DIFFERENT result than measuring Quality first, then Velocity.
Run this code and you get:
[Velocity, Quality] = Velocity*Quality - Quality*Velocity
That output - Velocity*Quality - Quality*Velocity - is not zero. This is the mathematical signature of non-commutativity, and it carries an enormous consequence.
What This Actually Means
When two operators don't commute, the generalized uncertainty principle kicks in:
$$\Delta\text{Velocity} \cdot \Delta\text{Quality} \;\geq\; \frac{1}{2} \left| \hbar_{\text{org}} \right|$$
In plain language:
You cannot simultaneously reduce the uncertainty in both Velocity and Quality below a fixed bound. The more precisely you optimize for one, the more the other must fluctuate.
This isn't a management failure. It's not something you fix by hiring a better VP of Engineering. It's a structural property of how these two metrics interact within a human organization.
Here's the intuition for why they don't commute:

You optimize for Velocity first, then measure Quality.Engineers ship fast. They cut corners. Quality measurement reveals high defect rates. You now try to "fix quality," but the engineering habits, tech debt, and expectations set by the velocity push are already embedded. The system has been irreversibly altered.
You optimize for Quality first, then measure Velocity. Engineers write thorough tests, refactor extensively, do careful code reviews. Velocity measurement reveals "low output." Management panics and starts pushing for more shipping speed. But the careful engineering culture is already established - and now it's being disrupted. The order matters. The end state is different depending on which metric you optimize first. That's non-commutativity in action. The Uncertainty Constant: ℏ_org The symbol ℏ_org (we might call it the "organizational Planck constant") represents how tightly coupled two metrics are in a specific organization. It's not a universal constant - it depends on your team, your product, your culture. High ℏ_org: The metrics are deeply entangled. Optimizing one severely disrupts the other. (Example: "move fast and break things" vs. "enterprise reliability SLAs" - these are almost maximally non-commutative.) Low ℏ_org: The metrics are weakly coupled. You can optimize one without much disturbance to the other. (Example: "documentation coverage" and "deployment frequency" - these are roughly commutative.) Zero ℏ_org: The metrics fully commute. Measuring one has zero effect on the other. They can be independently optimized. (This is rare in practice for any metrics that involve human behavior.) Which of Your Metrics Are Non-Commutative? Here's a practical framework. Ask yourself: "If I aggressively optimize metric A for 6 months, then try to optimize metric B - would I get a different outcome than if I'd done them in reverse order?" If yes, they don't commute. Here are common non-commutative pairs: | Metric A | Metric B | Why They Don't Commute | | Sprint velocity | Code quality / defect rate | Shipping fast creates tech debt that degrades quality measurement | | Feature output | System reliability (SLA) | Feature churn introduces instability; stability-first limits feature throughput | | Hiring speed | Team cohesion | Rapid hiring dilutes culture; culture-first slows hiring | | Revenue growth | Customer satisfaction | Aggressive monetization erodes trust; trust-first slows revenue | | Individual performance | Team collaboration | Individual KPIs create competition that undermines collaboration | | Short-term profit | Long-term R&D investment | Profit pressure cannibalizes R&D budgets | And some (roughly) commutative pairs - metrics you can track simultaneously: | Metric A | Metric B | Why They Commute| | Test coverage | Documentation coverage | Both are "completeness" measures that don't interfere | | Uptime | Response time | Both align in the same direction for the same work | | Security audit score | Compliance score | Both are checklist-style measures with minimal behavioral distortion | So What Do You Actually Do? If simultaneous optimization is mathematically impossible for non-commutative metrics, how do you manage a company?
Rotate Your Observation Basis In quantum mechanics, physicists deal with non-commuting observables by choosing which basis to measure in - and accepting uncertainty in the other. Apply the same principle: Quarter 1: Optimize for quality. Measure defect rates, tech debt ratios, code review thoroughness. Accept that velocity metrics will look bad. Quarter 2: Optimize for velocity. Measure throughput, cycle time, deployment frequency. Accept that some quality metrics will regress. This isn't "giving up on quality" in Q2 - it's acknowledging the mathematical reality that you can't have perfect information about both simultaneously.
Measure the Commutator, Not Just the Metrics Before deploying a new KPI, estimate its ℏ_org with existing metrics. Ask: "If we aggressively optimize this new metric, which existing metrics will it disturb?" If the commutator is large, you need a conscious tradeoff strategy - not a dashboard with both metrics side by side pretending they're independent.
Use Conjugate Metrics Instead of Individual Metrics In physics, instead of tracking position and momentum separately, physicists often track phase space- a combined representation that respects the uncertainty bound. The organizational equivalent: composite metrics that encode the tradeoff. Instead of tracking velocity and quality independently, track something like: Effective Output = (Features Shipped) × (1 - Defect Rate) × (1 - Rollback Rate) This single metric respects the non-commutativity by building the tradeoff directly into the measurement.
Accept Irreducible Uncertainty This is the hardest one. Some aspects of your organization are fundamentally unknowable if you're optimizing for others. That's not a failure of your management system - it's a mathematical property of the system you're managing. The most important things in your company are the things you cannot continuously measure. The Uncomfortable Conclusion Goodhart's Law isn't a bug in human nature. It's not about gaming, or laziness, or misaligned incentives. Those are symptoms. The root cause is mathematical: certain pairs of organizational metrics are non-commutative operators on the state of your organization. Optimizing for one irreversibly alters the other. The act of measuring one disturbs the measurement of the other. No dashboard, no OKR framework, no "north star metric" strategy can violate this bound. The uncertainty principle doesn't care about your management philosophy.