Cover photo

Thoughts on "How to Build a Car"

Reading through How to Build a Car, a few product-related themes flow through the entire book:

• The constant search for advantages. Poring over the newly released rulebooks to find gaps & technicalities to creatively exploit. Examining other domains for cross-over insights. Every team isn’t just racing on the track, the design/engineering teams are racing each other to identify the smallest of levers before the next team.

• The car is a system, not merely an object. The interconnectedness of components, the mutual constraints & dependencies, all of it. You can’t just “add a feature” without likely disrupting multiple seemingly-unrelated factors.

• It’s not enough to know the car well; context matters. Driver, track, weather, regulations. It’s the job of the team to understand the impact of these factors and design the most optimal system for a given situation. The winning setup on a given day will be disaster on another.

• Testing is good, necessary, and an insufficient substitute for reality.

• So much building is rebuilding. The car is never done. Every iteration is a hypothesis, a sort of offering to the world of physics. The feedback loops are constant and overwhelming if you don’t know what to look for. Even in the middle of a race, they’re making user- and data-informed adjustments to the vehicle.

I’m nowhere near an expert on any of the topics in this book, so this has been a fascinating view into the F1 racing realm.

F1 fans: What have I missed?


Header Photo by Martí Sierra on Unsplash