.png)
For about fifteen years, I was building a drag car and a corporate IT infrastructure at the same time. Not sequentially. Literally at the same time — the '88 Fox Body Mustang and whatever datacenter I was managing that decade occupied the same headspace, the same evenings, sometimes the same weekend.
People think those are completely different things. They are not. They are the same problem with different materials.
The Constraint Is Always the Same
When you're building a 9-second drag car on a budget, you operate inside a brutal set of constraints. The tire has a fixed contact patch. The track has a fixed quarter mile. Physics doesn't negotiate. You can tune fuel curve, launch RPM, boost pressure — but you cannot argue with the fundamental limits of what you're working inside. You find the margin. You build to it. You test.
Enterprise infrastructure is identical. You have a network. You have latency. You have a budget that someone in finance approved three months ago and will claw back in Q4. You have 10,000 endpoints that all need to be in compliance by a date that has already passed by the time you found out about it. The constraint is fixed. You find the margin. You build to it. You test.
What changes is which wrench you pick up.
Tolerance Is a Number, Not a Feeling
When I built the 363 on the Dart Iron Eagle block, every clearance was measured. Rod side clearance. Main bearing clearance. Piston-to-wall. You don't assemble a high-performance stroker and guess. You measure, you document, you build to spec. If a clearance is off by a thousandth in the wrong direction, you'll find out at 8,000 RPM in a very bad way.
When I migrated 300 TB of corporate data to Azure Blob Storage, I built the same discipline into the process. Every container had a defined retention policy before a single file touched it. Every role assignment was scoped. The Intune compliance baseline was documented before we enrolled the first device. If you skip the measurement step in infrastructure — if you "feel like it's probably fine" — you find out in production. Same as the engine. Just slower and more expensive.
The guys who blow engines are the guys who trusted their gut on clearances. The guys who blow up cloud migrations are the guys who trusted their gut on IAM.
Same problem. Different units of measurement.
You Can't Skip the Boring Part
Every single build I've ever done — the '73 Grande, the '85 LX, the '88, the J-Marie, every datacenter migration — has a boring middle phase. The phase where nothing exciting is happening. The engine is on the stand. The hull is upside down. The file servers are sitting in staging. Nothing to show anyone. Nothing to take a photo of.
That phase is where the build actually happens. Everything visible before it was just setup. Everything visible after it is just the payoff. The boring middle is the work.
I've watched people rush that phase in both worlds. A car guy who wants to be on the track instead of in the garage doing the clearances. An IT director who wants the Azure dashboard instead of doing the network assessment. Both end up at the same place: diagnosing problems they introduced during the part they didn't want to do.
Failure Is Data
In January 2003, I flipped the '88 onto its roof at 115 mph at Atco Raceway. The timing system clocked a 14.3 on the roof. The whole thing went viral before "going viral" was a phrase people used.
Here's what I didn't do: quit.
Here's what I did do: figure out exactly what happened. The 363 was fresh and putting out more power than the chassis setup was tuned for. Too loose. Coming off the line, the car stepped out, I overcorrected, the front tire dug in. Specific cause. Specific fix. The car came back the same year.
I've had infrastructure failures that felt just as bad in the moment. Production database. Friday at 5pm. Incident bridges that nobody wants to be on. The same rule applies: failure is data. What specifically broke? Why? What assumption was wrong? Fix the assumption, not just the symptom. Document it so the next person doesn't learn it the same way you did.
The guys who treat failure as a personal indictment don't improve. The guys who treat it as a diagnostic opportunity get faster.
Why I'm Writing This
I've spent 35 years in IT. I've also spent 35 years building things in a garage. I've never found a useful place to put the intersection of those two things — until now.
This is what Boost and Bytes is. The overlap between building physical things and building enterprise systems. War stories from both garages. The lessons that actually transfer. What 35 years of doing this for real looks like up close.
Not theory. Not vendor talking points. Not content written by someone who read a whitepaper.
The same problem, two different garages. I've been in both. I'll keep writing from there.