The Day IT Accidentally Started Working

Last week, we ran a simple thought experiment: what if other industries worked like IT?
The result was funny precisely because it was impossible. Bridges would collapse. Aircraft would be grounded. Surgeons would improvise mid-operation.

So let us reverse the mirror.

What if, for once, IT accidentally started working like other industries?

Not brilliantly. Not heroically. Just normally. That alone was enough to feel unsettling.

Work Stopped Starting Without Being Finished

The first strange symptom was not speed. It was restraint.

Fewer initiatives were started. Some were cancelled. Others were delayed until capacity actually existed. Work in progress dropped, not because of a framework, but because someone accepted a simple truth: starting is cheap, finishing is expensive.

Other industries learned this lesson centuries ago. You do not pour ten foundations at once and hope some turn into houses. You finish one before digging the next.

In IT, we usually call this lack of discipline “momentum”. In this alternate reality, it was simply called focus.

Requirements Stopped Moving After Commitment

Something even more unsettling happened.

Requirements stabilised.

They did not freeze because the world stopped changing, but because changes were finally treated as what they are: cost. A change after commitment meant delay, rework, or explicit trade-offs. Someone had to say yes, and someone had to say no.

In construction, changing plans after pouring concrete is a failure of planning. In IT, it is often marketed as adaptability.

Here, it was treated as engineering.

Interfaces Were Treated as Infrastructure

Interfaces stopped being conversational.

They were defined early, documented clearly, and protected aggressively. Breaking changes were rare, boring, and slightly embarrassing. Backward compatibility was not a favour, it was an obligation.

Railways standardised track gauges so trains could travel across countries. Electrical systems standardised voltages so equipment would not burn. Aviation standardised cockpits so pilots could survive stress.

IT, meanwhile, usually reinvents interfaces weekly and wonders why nothing scales.

In this brief moment of sanity, interfaces were boring. Which is exactly what you want from infrastructure.

Failure Triggered Investigation, Not Reinterpretation

Failures still happened. Of course they did.

But something deeply unfashionable followed.

There was a timeline. Decisions were traced. Trade-offs were documented. The question was not how people felt, but what actually happened.

No one asked whether the discussion was comfortable. No one reframed the failure as a “learning celebration”. The system failed, and therefore the system had to be understood.

In most industries, this is called responsibility.

In the fragile postmodern IT ecosystem, it is often called toxic.

Sometimes because it is uncomfortable. More often because it is inconvenient.

A Brief, Uncomfortable Note on Accountability

At some point, someone raised an awkward comparison.

Civil engineers are licensed. Pilots are licensed. Surgeons are licensed. They spend years under supervision before being trusted alone. Repeated negligence ends careers.

IT engineers, meanwhile, operate systems that affect millions with fewer formal constraints than people who wire houses. That alone should end the conversation about whether accountability would “kill innovation”.

No one proposed licences. No committees were formed. The observation simply lingered in the room.

It was not an argument. It was a contrast.

Seniority Absorbed Risk Instead of Deflecting It

Another anomaly appeared higher up the hierarchy.

Senior people slowed things down. They absorbed uncertainty instead of exporting it. They protected junior engineers from impossible deadlines and incoherent demands.

As systems stabilised, leadership became less visible, not more. Authority quietly receded as reliability increased. In mature industries, experience exists to reduce uncertainty.

In IT, it is too often used to justify it.

Why This Felt Unreal

Nothing described here is innovative.

There is no breakthrough technology. No cultural revolution. No new methodology. Everything in this story predates IT itself.

Other industries call this engineering.

IT often calls it overhead.

When an industry experiences normality as a shocking thought experiment, the problem is not ambition. It is the absence of foundations.

And that, perhaps, is why the idea of IT simply working feels like science fiction.