After being an avid Formula 1 fan since 1990 and a software developer since a couple of years later, I’ve noticed there
are a few things in Formula 1 that can be applied to software development. Some of these lessons apply directly to
developers, others to development teams, and some to organisations that employ developers.
It’s Both a Marathon and a Sprint
One similarity I’ve noticed is that both Formula 1 and software development are both marathons with sprints that occur
In Formula 1 there are (depending on season) around 20 race weekends that go to making up the championship. The
championship is the marathon. In software development the marathon is the entire life of the software that is being
The marathon of the Formula 1 championship can be broken down into shorter elements that occur a number of times; these
would be the race events. In software development, these are the equivalent of releases.
Potentially each of these could then be broken down further (at the risk of creating some terminology confusion). In
Formula 1 the race events are broken down into sessions (practice 1, practice 2, practice 3, qualifying and the race).
Using Scrum terminology, these would be Sprints in the world of software development.
So, what can we learn from these similarities?
In Formula 1, there are celebrations for both the overall championship and for winning a race weekend, teams also take
pride in their performance in the individual sessions of the race weekend, but generally the celebrations are internal
to the team and more subdued. In software development we should celebrate the product. Every release is the cause for
celebration. It may not be perfect, but I have never heard a Formula 1 team or driver claim they have had a perfect
weekend either. At the completion of each Scrum Sprint (or the equivalent in the project management methodology used by
your team) development teams should celebrate their achievements, but in a more subdued way. I haven’t covered a
celebration in software development that is equivalent to the championship celebrations in Formula 1, that’s partly
because software products have a very long life span and Formula 1 is based on seasons, but there are some championship
level celebrations that can be found in software development. When a major component or upgrade is completed this is
worthy of a significant celebration.
As well as celebrating achievements, software developers can also learn about sustainable performance and taking a break
after a significant investment of energy. The Formula 1 race calendar has occurrences of back-to-back race weekends,
but these are almost always followed by a break, additionally, drivers maintain schedules that allow them to recover
from every race. In software development we need to be more conscious of our ability to perform in a sustained way. If
we have to expend significant effort to meet a deadline or in the final stages of a release, we must allow time for
individuals and the team to recover before calling on their peak performance again.
During each Formula 1 event there are 3 practice sessions prior to the two sessions that are of significance for the
event. In some situations, the performance in these sessions can have a bearing on the outcome of the race event (for
example a cancelled qualifying session can mean the grid is formed by the results from practice sessions). Additional
to these events, drivers and teams spend many hours practicing in a simulated environment (c computerised simulator in
the case of drivers and mock pit-stops in the case of the team). In software development we must constantly strive to
improve our ability to deliver solutions and to keep up with technological change.
Software developers tend to be adept at keeping up with technological change; this is partly due to knowledge sharing
(which I will cover later) but is also because of our inquisitive nature and desire to improve. We spend a significant
amount of time staying abreast of technology outside of work, and many developers maintain side projects to constantly
improve their performance.
Unfortunately, many companies that employ software developers don’t see the benefits of allowing their staff to practice
and experiment, nearly all tasks are directly linked to a required output. In some organisations time is provided to
practice, experiment and learn, and these organisations tend to produce higher quality products and take advantage of
newer technologies more rapidly.
One aspect that software developers do better than Formula 1 is knowledge sharing. This is partly due to the
competitive nature of Formula 1. In Formula 1, knowledge sharing with a team is vitally important, especially if one of
the cars has been unable to complete a practice session; however, knowledge sharing between teams is kept minimal due to
the competitive nature of sport. In software development we seem to be really good at sharing knowledge externally
through meetup groups, forum sites and even special interest online chat rooms. We are less adept at sharing
information within a team. This can come from egos that want to hoard information, from distributed teams that don’t
have the opportunity to communicate, or from company policies that value an individual’s contribution above the output
of a team.
Quickly recovering from mistakes
In Formula 1, drivers are trained to learn from their mistakes and move forward. I have heard this is made easier by
the fact every time they are on the track they are too busy trying not to die to remember the mistake they made on the
previous lap, but I think there is a certain amount of psychological training that enables this to occur. In software
development we rapidly move on from some mistakes and refuse to learn from others.
When a software developer receives a bug report this is the equivalent to a small mistake on a Formula 1 circuit that
costs the driver some lap time. As software developers we usually fix the issue and move on rapidly, not dwelling of
Where software developers aren’t as good is when a significant mistake is made, or an architectural decision was
sub-optimal. In Formula 1 terms a major mistake would result in the car being unable to continue in the session, in
software development it could involve an outage that prevents the use of the software. A Formula 1 driver will rapidly
inform the team what has happened, take appropriate action to resolve the problem (return to the pits, exit the car to
safety, or find a safe place to leave the car), they will then return to the team to debrief; the mistake will result
in changes to the way the driver or team operates, but they do not dwell on the issue unless it becomes a recurring
pattern. In software development very few organisations are able to follow a similar process. The times I have seen
outages occur it is rare for an announcement of the outage to be made prior to any work beginning on fixing the issue, a
significant outage often results in developers and/or other staff experiencing a level of panic, and rarely have I
experienced a debrief immediately after the incident (it is often days later if at all).
As software developers we need to improve our communication, our immediate response and how we learn from incidents. We
also need to improve our ability to move on from an incident and not let it impact our future work in a negative way.
Software development teams, when compared to a Formula 1 team, are very poor at admitting fault. I have seen countless
cases where the blame for an incident is deflected to other teams, other individuals, company policies or external
factors. In Formula 1, the cause of fault very quickly admits to the problem, from a driver to a mechanic, to an engine
supplier, fault is quickly admitted, then investigations into the root cause are undertaken. This enables the team to
rapidly identify the root cause and ensure it doesn’t happen again, learning from the issue in the shortest time
If software developers are given an environment of psychological safety they will be more likely to admit to mistakes
and errors and actions can be identified that will prevent the same issue from occurring again in future.
It’s a Team Sport
Both Formula 1 and software development are team sports. Casual Formula 1 observers may not realise the size of the
teams behind a single car on the track and may assign much of the credit to the individual driver, but without the
mechanics, the team back at headquarters and a raft of other roles in the team the drivers would not be able to compete.
Software development is very similar; many companies and managers view a software development team as a group of
individual contributors, but in reality, the ability for the team to interact and work as one is what will wake them a
In software development we need to recognise the importance of working as a team, achieving goals as a team and ensuring
the team is always working toward a common goal. In the majority of companies I’ve worked with a form of Scrum has been
implemented (not true Scrum, but a derivative of it); one thing that has been common within these companies is that the
Sprint goals have been defined based on one or two individuals expected achievements and the tasks for other team
members have not been aligned to these goals. To equate this back to Formula 1, it would be like a team working on the
speed of a pitstop and the handling of the car, with a team goal of improving pitstop speed because one individual is
expected to focus on this while the rest of the team is working on the handling. If a team is aiming to improve pitstop
speed, then all team members should be working toward that goal.
Companies can learn from Formula 1 in terms of acknowledging teams over individual contributors. In Formula 1 there is
no award for the fastest wheel change by an individual, but there is a lot of pride taken in the fastest pitstop. When
a pitstop is abnormally slow, all team members rally around the individual who had an issue and work to improve it for
the next pitstop, they celebrate as a team and commiserate as a team.
Large Distributed Teams
Many software development teams are geographically diverse, and a company will often have multiple discrete development
A casual Formula 1 observer may not see the distributed nature of the Formula 1 team, but they are even more
geographically diverse. In Formula 1 the driver is disconnected from the team for much of an event as they are in a car
driving around the track while the mechanics and some central staff are in the pit area; there is then a team of
specialists that are located in the pit paddock area and a further team that is located back in the team headquarters.
All of these people must operate as a single unit to ensure the car remains competitive and that correct choices are
made at all stages of an event.
The similarities between these situations becomes more obvious when communications are considered. Within both Formula
1 and software development, teams must be able to communicate quickly and efficiently to ensure focus is maintained on
the correct tasks. Communication channels between multiple teams need to be clear with common terminology used.
Decisions and findings must be reported to decision makers quickly and clearly to ensure the timeliness and relevance of
Many software companies are still experimenting with how to best achieve this in their environment. A variety of Agile
scaling frameworks are used and customised, some companies have found a solution that works for them, many of them
Another items software development could learn from Formula 1 is the importance of clearly defined procedures for
regular and disaster recovery tasks.
Formula 1 teams have clear procedures for a large number of events, from a normal pitstop to resetting the car’s
electronics while on track, from proscribed engine changes over an event to emergency car rebuilds due to an accident.
In Formula 1 it is not uncommon to hear a driver experience a problem during a race and within seconds instructions are
relayed over the radio to change settings on the car to rectify or avoid the problem. It simply isn’t possible for the
driver or the driver’s race engineer to know all of these settings; instead messages are communicated back to base where
someone is able to rapidly search a procedure manual, locate the correct set of changes and relay them back to the
driver. At this weekend’s Abu Dhabi event, in the first practice session, Daniel Ricciardo’s engine failed; according
to the commentators an engine change normally takes around 6 hours, but with only three hours between sessions the team
used a different procedure (likely with less checks and testing) to complete the engine change and get the car back on
track for the following session; both of these engine change procedures would have been documented to reduce or
eliminate the chance of unexpected consequences.
In software development we often deprioritise documentation in favour of introducing new features. If documentation is
written, procedures are generated for the most likely scenarios, procedures are added for other scenarios as they are
encountered, and the procedure manual is easily searchable, then the ability for a developer to resolve an issue becomes
easier and potential failure points are easier to identify. Solutions can also be developed to improve the response to
Preventing Further Issues
So far, I’ve concentrated on what can be learnt from Formula 1 teams and drivers, but what about learnings from Formula
1 as a sport?
In Formula 1 when something goes wrong it can have tragic consequences; this has resulted in the sport identifying ways
to improve from both the ultimate tragedy of a death caused by the sport, but also from close calls where there was the
potential for tragedy. An example of each of these is the introduction of the Virtual Safety Car (VSC) after the death
of Jules Bianchi at the Japanese Grand Prix in 2014, and the introduction of the halo in part from the impact that took
Jules Bianchi’s life but also due to incidents like the one that fractured Felipe Massa’s skull at the Hungarian Grand
Prix in 2009.
Software development teams can learn from Formula 1’s implementation of the Safety Car and the Virtual Safety car in
terms of incident management. When an incident occurs in Formula 1 it is highly likely that a further incident will
occur due to the initial incident. For this reason, when an incident occurs the entire racing field is neutralised. In
software development we can have procedures in place to prevent an incident from snowballing across our systems to
create a much larger problem; this could be a system that limits activity or reduces the throughput of some systems so
as not to overload a degraded system, or it could be a willingness to shut down an entire system in order to resolve an
issue in isolation.
Constant Iterative Improvement
Formula 1 has constantly worked to improve the safety of events and cars. In the 1950s and 60s there were 15 deaths in
each decade, this decade there have been only 4 (deaths occurring at official Formula 1 race weekends). After every
fatality or serious incident both the FIA and Formula 1 teams work to improve safety, often introducing safety
improvements mid-season. Additionally, as Formula 1 is constantly pushing technological knowledge boundaries, and
especially in the 1970s, the rules were often adjusted to outlaw certain technologies for both safety and competitive
Although software development generally doesn’t cause deaths (this could be argued on many fronts, but as the percentage
of all software that can directly cause a death is so low I’m rounding it to 0), we can learn from this iterative
improvement Formula 1 has applied to their rules and safety features. Many times, I’ve seen software development
organisations release a “completed” product in a big bang release, if these changes are not accepted by customers and
users (the Formula 1 equivalent would be the changes are outlawed) then the entire investment in the changes are wasted.
Instead we should be honouring the principles of the Agile Manifesto and deliver frequently and iteratively to enable
the validation of ideas and prevent waste of development time and effort.