As engineering teams, we spend a lot of time putting together ambitious goals.
But the more ambitious the goal, the bigger the potential for failure, and therefore anxiety and fear as we go after it.
That’s why, as leaders, one of the greatest investments we can make in our team is to help engineers overcome their fear of failure.
In this article, we’ll explore how engineering leaders can create an environment that reduces fear of failure so teams can safely work towards ambitious delivery goals with passion and focus. We’ll look at what fear is, why it matters to engineering teams, and what tools we can use to combat it, from small releases and iterative deployments to automation and incident practice.
What is fear?
Fear is one of the seven universal human emotions. It arises with the threat of harm, either physical, emotional, or psychological.
Often fear is a forecast. We feel it because there’s something about the future that’s uncertain or worrying. And our bodies and brains have a defense mechanism that makes us want to act when that feeling arises – often without putting real thought into it.
The classical example when talking about irrational behavior in connection to fear is the fear of flying. It is statistically one of the safest modes of transport, but still many people have a disproportionate reaction.
Fear can exert itself in varying degrees of intensity, from nervousness, anxiety, and dread to panic and horror. It’s not just about life-threatening scenarios; it also impacts everyday tasks and behaviors.
Take a look at this paper by Ralph Adolphs. It builds on a study that shows that we as humans, just as rodents, respond drastically differently depending on certain variables of what we fear, for example, if the threat is far away in time, if it is definite or not, and if there’s an opportunity to hide.
Let’s go through a couple of examples:
The study shows that if what we fear is very dangerous, we’re inclined to respond forcefully with screaming and running being the most likely response, closely followed by attacking the threat.
If we add to it that what we fear is an inescapable fact, then attacking the threat head on ends up being the most likely response.
However, if what we fear is distant in time or place, we’re actually likely to respond by trying to hide from it.
Most interestingly, the study shows that actually stopping and doing a risk analysis of the situation is inversely correlated with all threatening scenarios. Meaning, when we feel fear we are always unlikely to respond in a calculated, measured manner.
And this is why it’s so important to invest in reducing fear from work.
Why does fear matter for engineering teams?
When we set ambitious goals for our teams, we need to be aware that the chance of failure increases, and in that, so does fear. And depending on how the teams perceive the threat (how certain it is, how remote it is, etc), it may trigger a few different behaviors.
For engineering teams, ambitious goals are often tied to the delivery of software, for example launching a new feature, deploying code, or changing the architecture. We know that software is complex, meaning we can never fully know what will happen. But to make good progress we often need teams to take risks and go the extra mile. For example:
- Propose an innovative architecture to scale beyond today and patiently work through all the criticism
- Refactor a hot spot in the code despite the business criticality of said function, to set us up for scale
- Deploy code to production on a Friday to be able to get data and feedback over the weekend
- Give feedback to another person to help them learn so that they can make more significant contributions
All of these have social, technical, and professional risks attached, and therefore might trigger reactions to fear including hiding, freezing, or, yes, screaming. But this is not the response we want. So, the question becomes, how do we create an environment where engineers can attack goals fearlessly?
Four ways to tackle fear in engineering teams
Reducing negative responses to fear such as hiding, running, or outright panicking is a challenge but not impossible, especially if we have the right structures in place. Here are a few methods we can use to tackle fear among our teams:
1. Reduce danger through small, iterative releases
Big bang releases can trigger fear due to the sheer size of the change, not only to a specific part of the code but to the overall environment and team responsibilities. Since there are so many variables at play, outcomes are very uncertain. When teams are allowed to build up large changes from the start, the pattern often becomes pushing releases into the future, which continuously adds to fear.
Smaller releases that update production code in increments are intuitively much safer as everyone can see how the code is gradually evolving. Also, since a lot of the work will be practiced every day, the whole process of releasing becomes familiar.
2. Increase identifiability through automated deployments
If there are a lot of moving parts and custom tasks involved with deploying code, that act itself can raise anxiety. The perception could simply be that there are too many random things that can happen. And if there would be a problem we wouldn’t even know where to start…
By automating the tasks involved with deploying code, teams can feel confident of what deployments look like. This means that a problematic deployment will have less unknown variables to be considered. We can be more assured that it is code that’s at fault and not something else.
Similarly, investing in good monitoring can also help teams increase their understanding of what success and failure looks like. Having an information radiator that shows errors, performance statistics, API calls, and deployments allows team members to update their own mental models of how the system works.
3. Reduce inescapability through gradual rollouts
It’s natural to fear a deployment if there are uncertainties around how to address a potential problem if there were one. If deployments are hit or miss, we’re more likely to want to take extra steps to ensure they’re safe.
For example, if there’s no known way of rolling back a change to the previous state, then it stresses that the change is perfect, which is a recipe for fear.
By investing in canary releases, for example, where code gets gradually rolled for customers as metrics are being closely monitored, teams can become more confident in their new code and know that there’s a safety net and limited blast radius in case something happens.
4. Reduce hiding by practicing incidents (and celebrating the learnings)
The good thing about incidents is that they’re relatively rare. But this can actually be a problem because when they do occur, teams may feel ill-equipped to handle them. And it’s easy to hide from the fact we don’t know how to handle an incident until it’s too late.
One way we can reduce the temptation to hide is to encourage engineers to practice how they’ll respond when things go wrong. Teams can practice so-called chaos engineering by forcing incidents and outages to happen, allowing them to experience failure and optimize on the experience.
Encourage your devs to spend time on ops-related tasks while on the job. Use on-call weeks as a way to involve them in tasks associated with incident management and operations. This might include tuning alerts, adding metrics, or improving the incident reporting templates. Involving operations engineers early in the development process can also increase awareness of common operations pitfalls and give folks a chance to mitigate problems.
Whenever a learning surfaces from your incident practice, help the team to make the changes needed, especially around soft things like skills and processes which may be overlooked.
Reflections
No team has ever won due to the greatness of their goals; it’s how the players behave that influences the outcome. As leaders, we have a responsibility to create a safe environment before we set ambitious goals. By using the approaches listed here, we can reduce fear and set our teams up for success, making it safer for them to propose solutions, deploy software, and manage the consequences.
