The 42-Inch Tire Rule: Every Upgrade Drags Its Downstream Costs With It

I spent a weekend bolting 42-inch tires and full hydraulic steering onto my Jeep. The tires were the point of the project. The steering was the actual project.

There's a moment in every build where the parts stop being a wish list and start being a pile on the shop floor. This was that weekend. And the first thing the pile told me: big tires and new steering come as a package, because neither one does you much good without the other.

The physics is simple. Step up to 42s and the factory steering starts working against you. More rubber on the rocks means more force fighting back through the wheel, especially aired down. The fix, full hydraulic steering, takes the driver out of that fight entirely. No more wrestling. No more kickback. The wheels go where you point them.

We did the work in a driveway, not a shop. Bracket by bracket, line by line, fitting by fitting. Two sets of eyes, two opinions, someone to hand you the wrench. The kind of work where you trust the torque wrench more than your memory.

Here's what the weekend was actually about, and it's the same thing I see in enterprise projects all the time: when you change one constraint, you inherit the bottleneck downstream of it.

The tires were the constraint I wanted. The steering was the constraint the tires created. If I'd mounted the 42s and kept the stock steering, the Jeep would have been worse off, not better — more capable in theory, less controllable in practice. The upgrade only worked as a system.

Now watch how the same story plays out in software. Teams adopt a new model, a new platform, a new frontend. The feature ships. And the bottleneck that was invisible yesterday becomes the whole conversation today: the data pipeline that can't feed the new model fast enough, the review process that can't keep up with the new throughput, the ops team that has no runbook for the thing they just turned on.

Nobody puts “hydraulic steering” in the feature request. It's never on the roadmap slide. It shows up the week after, as rework, as firefighting, as the thing that makes the upgrade look like a mistake.

Technical debt isn't old code that's ugly. It's the deferred downstream work you accept the moment you move one constraint. You can defer it — until you can't. With 42-inch tires, steering is the part you can't defer. In most enterprises, it's the operational layer: monitoring, escalation, review, rollback. The parts that decide whether the capability is a story or a recovery.

The lesson I keep re-learning: before you change the upstream constraint, map the full path it feeds. Name the downstream system that will become the bottleneck. Budget the package, not the part.

The upgrade wasn't the tires. It was everything the tires made necessary.

Think this argument fits your event? Tell me about the room — the calendar is selective.