You Measured the Wrong Thing. The System Followed.
The investment in speed. The return of slowness.
The delivery metrics are green.
Sprint velocity is up. Check-in frequency is high. Story completion rates are on target.
And the customer outcomes are not following.
Features are being built. Releases are shipping. But the capability customers actually need, stable, coherent, outcome-connected, is arriving more slowly than the delivery pace suggests. Sometimes it is not arriving at all.
When you look closely at what is happening beneath the metrics, the answer is almost never that the engineers and architects are performing poorly. It is that the system they are operating within is performing exactly as designed.
The problem is the design.
What Goodhart Knew
Goodhart’s Law is simple and reliably applicable.
When a measure becomes a target, it ceases to be a good measure.
The moment an organisation elevates a proxy metric to the status of objective, behaviour reorganises around the proxy. Not because people are dishonest. Because they are rational. They optimise for what is being measured, because that is what the system rewards.
In engineering organisations, this dynamic is so common it has become invisible.
Number of check-ins as a measure of productivity. Deployment frequency as a measure of delivery health. Velocity points as a measure of output. Each captures something real. Each distorts the moment it becomes the target.
A team measured on check-in frequency will check in more frequently. The check-ins become smaller, more frequent, less considered. The metric improves. The codebase does not.
The organisation asked for activity and received activity.
From Metric to Architecture to Quality Degradation.
The check-in metric is the visible layer of a deeper problem.
Beneath it sits a delivery culture shaped by artificial deadlines rather than sustainable target states. Engineers and architects making daily decisions about what to build, where to place it, and how to connect it, under the constraint of a date that does not move.
Those daily decisions accumulate into consequences that are subtle, durable, and compounding.
Capability duplication appears first. When teams are moving fast toward a deadline, discovery feels more expensive than building. It is faster to implement what you need, where you need it, than to find out whether it already exists elsewhere. The result is the same capability appearing in multiple places, each carrying slightly different assumptions, each creating its own maintenance surface.
Wrong architectural placement follows. Capabilities get placed where they are convenient, not where they belong. The correct placement would have required a design conversation that nobody had time for. The capability lands where the team had access and appetite, not where the domain logic dictates.
Compounding dependencies emerge from both. Each duplicated capability creates a dependency surface. Each wrongly placed component creates an unintended coupling. The system becomes a structural record of every deadline that was hit rather than a reflection of the domain it was built to serve.
Now layer in quality degradation.
Quality in this context means two things working together. Architectural quality, building on the right foundations, maintaining clean boundaries, iterating toward a coherent target state. And engineering build quality, testing that genuinely verifies behaviour, code review that engages with design intent, design conversations deep enough to catch the coupling that will cost three times as much to untangle later.
When both degrade simultaneously under deadline pressure, the effect is multiplicative.
Poor architectural foundations mean changes touch more of the system than they should. Poor engineering build quality means those changes introduce defects the test suite does not catch. Each increment of poor architectural quality creates more surface for poor engineering build quality to damage. Each increment of poor engineering build quality makes the architectural problems harder to detect and more expensive to address.
The system becomes progressively resistant to change. Not because the technology is old. Because the quality of the foundations and the practices that built on them were both sacrificed incrementally under the pressure of metrics that measured neither.
At a certain point the cost of a change becomes disconnected from the size of the change. A small feature request requires modifying three systems never designed to be changed together. A one-line fix requires a regression cycle that takes days because the boundaries are not clean enough to test in isolation.
The engineers and architects are not slow. They are navigating accumulated consequence.
For a board member or investor, this is what technical debt actually looks like. Not a list of things to rewrite. A system whose architecture encodes the delivery pressure of decisions made years ago by people who are no longer in the organisation.
The Customer Outcome Gap.
The consequence that makes this pattern commercially legible is not the complexity itself. It is what the complexity does to delivery.
High check-in volumes. Green delivery dashboards. Artificial deadlines hit. Customer outcomes arriving more slowly than the delivery pace should allow.
The teams that optimised for speed created a system that is now slower to change than a system built with more discipline would have been.
The shortcut consumed the very resource it was trying to protect.
This is a capital observation. The investment made in hitting artificial deadlines produced a negative return on the organisation’s most important long term capability. The ability to respond to customers and markets quickly. The original justification for the deadline pressure has been undermined by the decisions made in its name.
This is how deadline-driven delivery cultures purchase slowness with the investment they made in speed.
What AI Changes About This Pattern.
AI does not introduce misaligned incentives. It amplifies them along three dimensions.
The first is velocity. More code is being written faster. If the incentive structure is misaligned, duplication compounds more quickly. Wrong architectural placements accumulate in days rather than weeks. Quality compromises accumulate faster than any review process designed for human-paced delivery can catch.
The second is invisibility. AI-generated code that integrates cleanly does not announce its architectural misfit. It looks correct locally. It passes review. It ships. Wrong placement, duplicated capability, unnecessary dependency, these are systemic properties requiring a view above the code level to detect. An experienced architect can often feel when something is wrong in human-written code before articulating why. AI-generated code does not carry those signals.
The third is auditability. When AI-assisted development operates inside a misaligned incentive structure at pace, the resulting architecture is not just fragile. It is often harder to trace. The decisions embedded in AI-generated code are not always recoverable as conscious human choices. Nobody chose to duplicate that capability. The AI generated it because the incentive structure rewarded the output it was part of.
For an investor or board asking why the system was built this way, that question may not have a recoverable answer. That is a governance concern, not a technical one.
Leadership Accountability.
If the system behaves badly, examine the incentives before examining the engineers and architects.
The check-in metric was not chosen by engineers. The artificial deadline pressure was not created by architects. The absence of outcome-level observability was not an engineering decision. Each was a leadership decision, made at the level where incentive structures are designed, whether consciously or by default.
Default incentive structures are still incentive structures. The organisation that has never explicitly designed its engineering and delivery incentives has implicitly designed them through the metrics it tracks, the deadlines it sets, and the outcomes it celebrates.
Here is the capital argument stated plainly.
The organisation invested in speed and purchased slowness. That is not a metaphor. It is a return on investment calculation. Every delivery cycle that sacrificed architectural quality and engineering build quality to hit a deadline was an investment that produced a compounding liability against future delivery capacity. The organisation is now paying interest on that liability with every feature it tries to build.
AI makes this leadership responsibility more urgent. Because AI is obedient. It will execute whatever the incentive structure rewards, faster and more completely than any human team. An organisation that hands AI a misaligned incentive structure has not accelerated its delivery.
It has accelerated its misalignment.
The question is not whether your engineering and architecture teams are performing well against their metrics.
It is whether those metrics are connected to the outcomes that actually matter.
Sutra
Decisions made under pressure become the architecture everyone else inherits.