15 Dec 2025 5 min read antifragility

Monday Myth: “We Ship Fast Now. We Fix It Later.”

There is a persistent myth in modern IT and product organisations: that rushing a delivery without proper acceptance criteria is a valid trade-off in the name of speed.

There is a persistent myth in modern IT and product organisations: that rushing a delivery without proper acceptance criteria is a valid trade-off in the name of speed. That skipping SLOs, end-to-end tests, resilience checks, rollback mechanisms, or multi-regional thinking is acceptable because “we will improve it later”.

This is not pragmatism. It is not agility. It is not even speed.

It is a lie. And worse, it is a lie told directly to customers.

What “shipping fast” actually means today

Let us be precise. What is usually labelled as “shipping fast” often looks like this:

No clearly defined Service Level Objectives
Partial or non-existent end-to-end test coverage
No automated rollback or kill switch
Manual recovery procedures, if any
No serious resilience or failure-mode analysis
Single-region deployments justified as “temporary”

The justification is always the same: pressure, deadlines, competition, or the promise that quality will come later.

This framing is fundamentally dishonest. Not because teams are malicious, but because the system rewards delivery theatre over operational truth.

Speed without safety is not speed. It is risk externalisation.

Leadership failure disguised as a system failure

This is often excused as a system problem. In reality, it is both a system, and a leadership failure.

Systems shape leadership behaviour, but leadership designs and tolerates systems. What you allow to ship defines what you value. What you repeatedly excuse becomes your operating model.

When leaders accept delivery without acceptance criteria, they institutionalise negligence. When they reward output over outcomes, they hard-code fragility into the organisation.

This is not accidental. It is cumulative.

The Ponzi scheme analogy

This pattern mirrors a classic Ponzi scheme more closely than many would like to admit.

In a Ponzi scheme:

Participants trust claims because others repeat them
Fundamentals are no longer verified
Credibility circulates socially rather than factually
The system sustains itself on belief, not value creation

In many IT organisations, the same dynamics apply:

“It will be fixed later” replaces evidence
“Other teams do it this way” replaces engineering judgement
“We had no time” replaces accountability
Internal alignment replaces customer outcomes

Nobody checks the balance sheet. Nobody asks the uncomfortable questions:

Does this work end-to-end under real conditions?
What happens when it fails?
Can we roll it back automatically?
Can it survive a region outage?
Are we confident enough to bet our reputation on it?

Instead, trust becomes socialised. Risk becomes diluted. Responsibility evaporates.

Like every Ponzi scheme, the system holds as long as belief circulates faster than reality catches up.

The counter-myth: “Customers value speed over reliability”

This is the lie that sustains everything else.

Customers do not value speed. They value outcomes. They value predictability. They value systems that work when they matter.

Speed without reliability is invisible until it fails, and then it dominates the experience. The belief that quality can be deferred is not customer empathy. It is organisational self-soothing.

The self-entertained system

Alessandro Baricco described the internet as a self-entertained system: a space where narratives feed themselves, detached from physical constraints and consequences.

Many IT organisations have evolved into the same kind of closed loop.

They optimise for:

Velocity metrics
Roadmap optics
Internal narratives of progress
Not being the outlier who “slows things down”

In such systems, doing things properly becomes socially risky.

The engineer who insists on SLOs, resilience testing, or rollback mechanisms is framed as difficult, rigid, or not business-oriented. Meanwhile, cutting corners becomes culturally acceptable, even rewarded.

This is how collective dysfunction emerges without individual ill intent.

Why “later” never comes

The promise to “fix it later” almost never materialises. Not because teams do not care, but because systems have memory.

Once something is in production:

It generates dependencies
It attracts traffic and expectations
It becomes harder to change
It competes with the next urgent delivery

Two well-known failures illustrate this perfectly.

Knight Capital (2012)

Knight Capital deployed new trading code into production with no effective rollback, no kill switch, and incomplete deployment isolation. A dormant code path was unintentionally reactivated. There was no automated safety net to stop the system once it began misbehaving.

In forty-five minutes, the company lost 440 million dollars. The firm never recovered.

This was not a complex technical mystery. It was a textbook case of shipping without operational safeguards and discovering, in real time, that belief does not stop execution.

Cyberpunk 2077

Cyberpunk 2077 was marketed and sold as a finished product while known technical instability was deferred under the assumption that patches would arrive later. Trust was monetised in advance. Readiness was assumed rather than proven.

The result was immediate failure at scale: mass refunds, removal from digital stores, lawsuits, and long-term brand damage. Subsequent fixes did not erase the original deception.

In both cases, “later” arrived only after irreversible cost was paid.

Technical debt is not a backlog item. It is an interest-bearing loan.

The promise to “fix it later” almost never materialises. Not because teams do not care, but because systems have memory.

Once something is in production:

It generates dependencies
It attracts traffic and expectations
It becomes harder to change
It competes with the next urgent delivery

Every skipped safety mechanism increases the cost of change. Every missing test increases fear. Every fragile deployment path reduces the organisation’s ability to move deliberately.

Eventually, teams stop improving systems and start managing incidents.

The reputational trap

There is another, more subtle force at play: reputation within the organisation.

Very few people want to be the only team doing things “the right way” when others appear to move faster. Nobody wants to be the one questioned for delays while peers are praised for output.

This creates a race to the bottom:

Standards erode
Discipline becomes optional
Excellence becomes lonely

Ironically, this is precisely how trust collapses internally. High-performing engineers burn out or disengage. On-call becomes punitive. Incident reviews become political rather than corrective.

How it turns against teams

This myth always ends the same way:

Customers experience instability, not speed
Incidents multiply and recovery slows
Teams lose confidence in their own systems
Leadership reacts with process, not understanding

When failure finally surfaces, the question asked is always: “How could we have known?”

The answer is simple. You knew. The signals were there. You chose not to look because looking was inconvenient.

Condemnation, not caution

Let us be explicit.

If you cannot define SLOs, you are not ready to ship.
If you cannot test end-to-end, you are guessing.
If you cannot roll back automatically, you are gambling.
If you ignore resilience and multi-regional thinking, you are outsourcing risk to customers.

This is not a grey area. This is professional misconduct.

You are knowingly presenting unfinished and unsafe systems as acceptable products. You are relying on belief instead of proof. You are monetising trust while silently shifting risk onto users.

In any other mature industry, this behaviour would be labelled as deception. It is a con not because individuals are malicious, but because the organisation has normalised behaviour that would not withstand scrutiny.

Like every Ponzi scheme, it feeds on silence, social validation, and the hope that failure will occur on someone else’s watch.

It will not.

Reality always collects the debt. And when it does, customers pay first, and teams pay next. Shipping without basic quality gates is not bold. It is not innovative. It is not customer-centric. It is cowardice disguised as pragmatism.

Real speed comes from discipline: