Like many others recently, I’ve become a Formula 1 fan after I watched the Netflix show - Formula 1: Drive to Survive. I watched it in 2020, and since then, I have become fixated with the sport.
Part of it is that I’m just a sucker for things at the bleeding edge of technology and performance. However, the other piece to this puzzle is that I see many similarities between running a championship-winning F1 team and building great software products.
While daily stand-ups aren’t as exhilarating as racing around Monaco at 290 km/h, there’s a lot that the sport can teach us about consistently producing valuable work at a high standard.
I’ve identified a few key themes from F1 that applies very well to the art of building software products and services, but I suspect many of these are generally applicable across organisations. Let’s get into it!
Starting with the essentials - teams ensure that their personnel have everything they require to set them up for success.
McLaren’s pit crew mechanics wear wrist support that prevents over-rotation when they change tyres in a rush. It’s a simple investment but, the long term impact is that the crewmates stay injury-free, and a stable team means faster pit stops.
Training plays a huge role as well.
In 2006 we undertook the first of our annual trips to the sports science facility at the Finnish Olympic Training Centre in Kuortane, where we went through in-depth analysis of our individual physical strengths and weaknesses, using biometric testing to help formulate a personalised and truly bespoke program for each of us.
If our role on the crew meant we had to quickly lift a heavy rear tyre, for example, emphasis would be placed on strengthening the core muscles used in that task.
We can apply this same principle to ensure that team members have the necessary work setup required to be successful, in addition to any training that would lay the foundation for their success.
There is no better example for coordination than the signature pit stops of F1. Take a look at this world-record pit stop from Red Bull. There are ~20 pit crew members responsible for making this happen, and they did it in 1.82 seconds. Every crew member knows exactly what they are responsible for, and they trust other crew members to do their job correctly.
The outcome? This choreographed perfection.
When we have a stable team with well-defined expectations of people who can trust each other to follow through - we get great chemistry, solid work and most importantly, it’s fun!
This is probably the most data-intensive sport on the planet. Teams measure everything.
Today, each car houses between 150 and 300 sensors, which generate millions of data points every weekend. In terms of numbers, around 300GB of data per car is generated each Grand Prix weekend. If we add this to the data generated by the rest of the team, it can amount to 40–50TB of data per week.
This trove of data informs all sorts of race aspects like: informing drivers about how their teammates are braking differently to carry more speed through corners; or feeding data to the predictive models that provide race strategy suggestions. Finding even a 0.001 second advantage is valuable.
When it comes to building products, it’s important to track the different aspects of the product and the development process - ranging from build pipelines to application usage and metrics. This will enable you to make data-backed decisions instead of relying on “what feels right”.
Intuition certainly has a role to play, but data + intuition is a knockout combination.
In my team, we started tracking how long the various stages of our release took and started to make small improvements to it every few releases. Over time we’ve shaved off hours from our process by doing so.
Clarity about the current situation is essential for decision-making. This is why teams invest heavily in cross-team comms. Satellite teams, trackside engineers, the driver, everyone and everything connected. This provides the race strategists with context to make optimal decisions based on the present situation.
There's a great video on the F1 channel about the role of a strategist if you want to learn more.
Many teams perform the ritual of daily stand-ups - the intention behind that is to keep the team in sync. It’s not meant to be a status report for your manager.
Everyone on the team needs to be aware of what their goals are and how far they’ve progressed in relation to it. Rituals like stand-ups and other progress-tracking tools can be used to empower teams into understanding where they stand and take any actions if necessary.
You do need to be careful that you’re not distracting your team with too many comms.
Here’s a clip of Lando Norris asking his engineer to not-so-politely shut up.
As tempting as it is to drive flat out the entire race, physical limitations do not allow that. Teams have to be strategic about how they manage things like battery reserves and tyre wear, depending on their race strategy.
To see this in action - watch how Lando's race engineer helps him manage his car to clinch a spot above Lewis who has a 5 sec penalty. Listen how he strategically dictates specific engine modes to set from the wheel, and when to press the "overtake" button to use up battery power.
Similarly, product teams cannot be working all-out to ship features around the year. As much as possible, teams should work at a sustainable pace. Overworking is counterproductive in the long term. The team is perhaps the most valuable resource in identifying creative solutions to user problems, but they need breathing room for that.
Moreover, you want to make sure that the work you put out for users meets a certain level of quality. That’s not going to happen if the team is under pressure to cut corners.
The Toyota Production System practices the philosophy of jidoka, which in their context implies “a machine must come to a safe stop whenever an abnormality occurs”.
The workers are empowered to stop the production line in these scenarios. The managers/supervisors then converge at the line to inspect the situation. After rectifying the situation, changes are put in place to avoid a similar occurrence in the future.
F1 takes this philosophy very seriously - minor errors can cost you the race, and anything short of perfection is unacceptable.
At the 2021 Azerbaijan GP, Lewis Hamilton locked up his brakes which cost him a chance to take the championship lead. The team investigated what went wrong and discovered that Lewis had accidentally flicked on a switch in the car, which had altered the brake settings. They didn’t realise it until it was too late.
At the next race, the switch had a different design so that this would not happen again.
This philosophy is very relevant to the product development process. Is there a tooling issue that costs your developers an hour every few weeks? Or perhaps every time a customer faces an issue, you have to manually sort through multiple logs to figure out what’s happening; because spending engineering time on better logging wasn’t a priority.
There are numerous examples of where implementing change right away will save time and money down the road. Product teams should carefully balance short term priorities against long term costs.
Teams take their post-race debriefs super-seriously as there are lessons to be learned from every race weekend. Drivers and engineers will typically spend a couple of hours after each race reflecting on the events and variables involved to look for improvements. This mindset feeds into their culture of continuous improvement and seeking marginal gains.
Mercedes also do a race debrief on their YouTube channel after every race weekend.
This concept would be familiar to many software development teams in the form of a “retrospective”. Retros are a valuable forum to explore areas of growth and improvement, and most importantly, come out with clear and measurable actions that get tracked.
This is a philosophy that underpins all of the points I mentioned above. It doesn’t happen in a distinct phase, it is a mindset in the sport of F1. I find it fascinating that at the start of the season, the car is not “done”. In fact, it is the least developed coming into the season.
Every week the teams make approximately 1,000 changes to improve the car’s performance. The cars are like a driving prototype — they are never in the same configuration. Everything is open to adjustment and tweaking based on how the car is performing (even during the race).
Furthermore, these innovations are based on data, not on the Highest Paid Person’s opinion.
Source: Jurriaan Kamer, The Ready
At every race, teams experiment with new parts and setups to eke out another 0.01 seconds of performance from the car.
Here’s a graphic of how the teams improved over the 2020 season relative to the leader - Mercedes.
The concept of iterations is powerful, and that’s why it’s a cornerstone of the agile way of working. Getting our work out there frequently in small batches allows us to get feedback and refine what we deliver to our users.
I hope you enjoyed the odd juxtaposition of two things I really enjoy!
Until next time,