👁6views

Technology Culture: The Sinking Car Syndrome

The Sinking Car Syndrome: When Your Architecture Is Terminal

There are two types of post-incident reviews in technology. The first type is genuinely useful, where you learn something, fix something, and sleep better. The second type is an elaborate ritual in which intelligent adults spend considerable time and money figuring out why a car sank, before commissioning a study on how to make the next one sink slightly less.

This post is about the second type.

The London to New York Road Trip

Imagine you need to travel from London to New York. Simple enough goal, but here’s the twist: you’ve decided to go by car. Before you dismiss this as obviously insane, allow me to present the business case, because there absolutely is one, and it was almost certainly written by a committee.

1. Cars are “tried and tested.” Planes crash, and we have a slide deck about that.
2. We have existing supplier relationships with multiple car manufacturers. The volume discounts are exceptional.
3. The person who made the final call really, really likes cars.
4. The incumbent support team knows cars. Retraining them on boats would take quarters.
5. We need to start execution tomorrow. A car is available today. Alignment achieved.

So off you go. You take a small hatchback and manage approximately 3 metres off the coast of Scotland before it becomes a submarine, which the team logs as progress. Undeterred, they send a truck on the basis that trucks are more durable, famously. The truck manages 2 metres, which is technically worse, but the team attributes this to a suboptimal angle of entry and documents it as a learning. Next comes the Porsche. You get a bigger run-up, you hit the water with genuine conviction, and you make 4 metres, which is celebrated internally as a 100% improvement on the hatchback. The team now has data, the data is analysed, a dashboard is created, and a retrospective is held.

Six Months Later: The Land Bridge Strategy

Half a year in, the team has logged 12 metres of progress and the sunken cars are beginning to form a rudimentary land bridge, which someone in leadership describes, without irony, as “emergent infrastructure.” Two hundred million dollars have been committed, sunk costs have been sunk both literally and financially, and pivoting now would mean admitting the original decision was wrong. Nobody in the room wants to be the person who says that, because the person who made the original decision is still in the room and still likes cars.

So the team brainstorms optimisations: wind the windows up tighter before entry, apply additional underseal to improve aquatic durability, experiment with tyre pressure since overinflation shows theoretical promise, or simply procure more cars and sink them faster. All of these ideas will be explored and some will even show marginal gains, but none will result in reaching New York, because the fundamental choice of car over boat was wrong from the start. You cannot iterate your way out of a categorically incorrect architecture; you can only make the failure slower and more expensive.

The Actual Problem

I am called into post-incident reviews fairly regularly, and my job is usually framed as find the root cause, suggest a fix, and restore confidence. But more often than people want to hear, the root cause is the architecture itself. The system was never going to work the way it was designed, not because the engineers were bad or the implementation was careless, but because someone made a foundational technology choice that was wrong and rather than confront that, the organisation built an increasingly elaborate structure around it. At that point, no amount of tuning, patching, right-sizing, or retrospective documentation changes the trajectory. You are not fixing a broken car, you are analysing why cars sink.

What To Do Instead

The honest conversation, the one that actually costs less in the long run, sounds something like this: “This architecture is terminal. It will never reliably do what we need it to do. Let’s stop optimising it and start deciding what we transition to.” From there the questions become how quickly can we pivot, what does the migration path look like, and what can we salvage versus walk away from. These are harder conversations than root cause analysis because they require someone to say that a previous decision was wrong, but they are the right conversations, and the longer you delay them, the more sunken cars you are funding.

The goal was never New York by car. The goal was New York. Get a boat.