McLaren Applied Technologies

What I learned from my biggest mistake as an F1 engineer

Andrew Latham, Chief Engineer - (LinkedIn Pulse
McLaren Applied Technologies

By their very nature, engineers tend to be cautious in their approach. That’s because making seismic, unpredictable change simply isn’t part of an engineer’s cultural make-up when you’ve spent, for example, years refining your modelling and simulation tools.

Every engineer, however, should also recognise that no model or simulation is perfect.

So, when you encounter a situation which shows you something that your models weren’t predicting, or where your understanding wasn’t quite right, you need to venture into that space as an opportunity to exploit, rather than a mistake to be quickly addressed and removed.

 And there’s a critical difference between those two scenarios.

Because we’re so desperate to find every grain of performance, there’s a prevailing mentality that says that accidents shouldn’t happen; and, when they do, we should quickly impose processes and procedures to stop them happening again.

But when they do occur – and they will, because human and procedural errors will always happen – you need to glean everything from them that you possibly can.

Back when I was a junior engineer on the McLaren Formula 1 test team, one of the mechanics mistakenly left a set-up packer in the suspension system of one of our grand prix cars. The following morning, when we began our first laps of the day, the car’s suspension was completely solid because this little packer hadn’t been removed.

 It was immediately obvious to the driver, who quickly returned to the pits and said that the car felt awful in terms of bump- and ride-quality. But he also told us there were some clear positives to be gained from the experience.

At that point, it would have been easy to focus on the problem, remove the packer and simply move on. But we didn’t want to just explain it away; the race engineers wanted to understand the positives, and re-engineer the car to retain the benefits and get rid of the negatives.

Now, that’s not something we would ever have programmed into the car’s set-up or run-plan, but it certainly fast-tracked us towards trying something new, really catalysing new areas of investigation into suspension set-up and stiffness. 

Nevertheless, these valuable learning experiences can be somewhat traumatic. Which leads me to my own worst moment on the race team.

Back in 2006, the regulations required teams to qualify their cars with race fuel-loads. The trade-offs were obvious – load the car up with fuel and you’d end up further down the grid, but with the benefit and flexibility of adjusting your strategy in the race. By contrast, qualify on petrol fumes and you had a good chance to be quick on Saturday, but you’d theoretically start the race with one hand tied behind your back.

The skill came in finding the perfect balance: a fuel-load that wouldn’t compromise your race pace, but which still gave you a good roll of the dice in qualifying.

At the 2006 German Grand Prix, I didn’t merely throw those dice poorly, I managed to drop both of them...

I’d been in charge of setting the fuel-load for Kimi Raikkonen’s final qualifying run. I made a mistake and didn’t put enough fuel in the car. And as Kimi happily trundled out of the garage and rolled to the end of the pit-lane to start his lap, I knew I’d made a mistake – and there was absolutely nothing I could do about it.

 I’m sure you can imagine that horrific, curdling feeling I had in the pit of my stomach at that very moment. 

The post-session post-mortem was pretty grim, particularly in such a highly-charged environment where everything is closely scrutinised. But the engineering team got through it, and we set about planning how we were going to execute what was looking like a pretty compromised strategy in Sunday’s race.

Now, this is where it starts to get interesting: before the race weekend, all our simulations, which had been firmly plotted around a more conventional qualifying strategy, had told us we were likely to finish third. 

In the race, we pitted 10 laps before all our competitors, but still ended up finishing in exactly the same position as we’d predicted: third.

What’s more, there had been a couple of major positives to the weekend: Kimi’s light fuel-load meant he’d taken pole, earning the team and its partners some well-deserved kudos, and, by dint of being at the front, we’d avoided any of the usual first-corner chaos that often happens at Hockenheim. We’d also led the first nine laps of the race before peeling into the pits for that super-early pit-stop.

At the end of the race, we started to realise that there were some peripheral positives to come out of employing that more extreme strategy. We hadn’t previously appreciated the importance of some of those more outlying variables when we’d been designing our race simulations, so that experience helped prompt a shift towards putting less fuel in the car for qualifying from that point onwards.

In both of those occasions, it was important for us to understand whether everything that had occurred because of those mistakes was negative. Good engineering prompts you to ask whether there was anything we could learn from it – you need to embrace the unexpected nature of those accidents rather than simply explain them away.

And that’s one of the key lessons I’ve learned over the years – don’t be over-protective of your own work, understand that it might not always be quite right, and that there’s always something new to learn or understand.

Create a culture that can extract the absolute maximum from these accidents, not one that hides them away and makes sure they don’t happen again.

And that’s not always easy. At McLaren, I’m still surprised by how easily we accept the positives that come from such openly accidental occurrences. And that’s led to a culture where, while people don’t deliberately make mistakes, every consequence of every unexpected event is analaysed with great clarity.

In more general terms, that means understanding the root of any problem with a broad mindset. Don’t start to solve a problem by employing a current solution or way of working – try and understand what outcomes need to be achieved, then work backwards from there. 

With that mindset, you’re hopefully able to present greater reasoning behind your argument, further qualify it with fact and data, and challenge your conclusions in new, fresh and interesting ways.

Make your engineering as much about the journey as the destination.

You've selected 1 product, please select at least 1 more to start comparing.

You've selected {$ vm.basketTotal $} products, you can compare up to {$ vm.basketMax $} products.

You've selected the maximum of {$ vm.basketMax $} products.

Compare Compare