This post is not about F1. It is about process.
When you mention the word process, it invokes dread in software engineers. I, too, used to be in that group. But, years of experience has turned me over to the other camp—the one that appreciates the right process.
Software engineering is a team effort. For a group of people to succeed, the essential requirement is that they must trust each other; they should not be second-guessing one another. Also, they should have an innate, almost instinctual understanding of each other’s behavioral patterns.
Processes create the set up for the above.
Have you seen an F1 pit crew change tires during a race?
Do you believe they would be able to achieve this rhythmic precision if:
- One of the crew arrived late to the pit?
- The driver stopped the car a couple of meters ahead or behind?
- One of the crew forgot to keep the tires ready?
The pit crew can achieve this feat because:
- They blindly trust each other’s actions.
- Each one knows what is precisely expected out of them.
Process is the way to set behavioral expectations and make sure everyone adheres to it; this develops mutual trust and reliability in a team.
Where people go wrong with process is in introducing process for the sake of process; the classic case of missing the forest for the trees.
When introducing a process, you should have clear and tactical answers to the below questions:
- Why is the process needed—the end goal of the process.
- If we did not have the process, what would we miss?
A lot many processes in companies are vestigials of the past. No one knows why they exist. But at the same time, no one wants to put in the effort to eliminate them.
Removing processes that do not add value or are well past their prime is as important as introducing new processes.
Another area where companies go wrong with processes is introducing them because someone else is doing it. Context is critical for a process to add value. If you do not have the environment and the right set up to make a process work, it is a nuisance; it is better not to have them.
Processes are tricky because one needs excellent judgment to evaluate them, and excellent judgment is a rare commodity.