A developer’s guide to programatically overcome fear of failure

[aum]

People are more than happy to talk about their successes, but if you ask them about their failures, they can be much more hesitant to share.

 

Failure is a subject that, interestingly enough, is entangled with the emotion of shame. Yet it’s integral to achieving anything novel, and the learnings that come from failure are unparalleled. So, let’s find ways to get more comfortable with failing, and figure out why people fear it.

 

Defining failure

First, we need to define failure. For the purpose of this, we’re going to stick to a really simple definition: trying at something and not succeeding.

 

While this definition works, not all failures are equal. There are lots of different ways to categorize failure. I’m going to keep it simple and break it down into 3 categories.

 

Preventable Failure: A failure where you had the knowledge and ability to prevent it, but it got through anyway.

 

Example: You launch a feature and then realize it didn’t work for customers on a certain plan, even though this was common knowledge.

 

Benefits for this type of failure can include the opportunity to adjust the current process.

 

This type of failure feels the worst because it’s the type of stuff that isn’t new. This is a space we want to avoid being in, but we can learn from this and avoid it going forward. Checklists and automated testing are really good to prevent this.

 

Complex Failure: A combination of internal and external factors come together in a new way to produce a failure outcome.

 

Example: Two services go live, and both being up at the same time puts strain on a shared resource, causing the resource to crash.

Benefits for this type of failure can include:

• Opportunities to adjust the current process and prevent mistakes going forward

• Realizations about the system and how it functions you weren’t aware of before

This failure might have been preventable, but it’s difficult to prepare for every single edge case when you also want to move fast. Failures like this happen, and you can learn and grow from them. For instance, in this example, you could pay more attention to this resource in the future, increase its capacity, or maybe even reassess how things are architected.

 

Innovative Failure: When answers are not knowable in advance because this exact situation hasn’t been encountered before and perhaps never will be again.

 

Example: You launch a brand new feature and users aren’t engaging with it at all.

 

Benefits for this type of failure can include:

• Opportunity for innovation, change, and to reflect

• Opportunity to learn things you couldn’t have learned before

This is the type of failure space you want to be in. It’s new, it’s exciting, and, most importantly, it gives you the opportunity to learn things you couldn’t have learned before.

 

This is the space where innovation happens. Sure, there may be ways to prevent this type of failure. You could have talked more to users, you could have analyzed the data more, but at the end of the day you took a risk, and you learned something from it. You have more questions to ask like, ‘Why aren’t the users engaging?” and you can change the working theories you had.

 

To me, being in this failure space is always better than wondering, “What if this could be the next big thing?” and never trying.

 

TL;DR:

 

 

Now we understand what failure is and the various forms of it. How do we get comfortable with it? Like working with software, let’s take a step-by-step approach.

1. Normalize failure
2. Understand failure
3. Embrace failure

Normalizing failure

In order for us to be comfortable with a topic, it has to be something that we’re familiar with. So, to normalize failure, we must become familiar with it.

 

Everyone will fail at some point in their life. When you first tried to walk, you fell. When you first learned to read, you stumbled over words. Know that you are capable of failing and moving past it. You’ve done it time and time again, even if you may have forgotten. These are types of failures that are common, though, and people are more understanding of them.

 

Crashing an app, introducing a bug, or launching an unappreciated feature are less acceptable types of failures, but they’re also part of the growth process.

 

If you want to write gorgeous, clean, well architected and tested code, guess what? You’re going to have to write trash code first. If you apply this to any other craft or art form—playing musical instruments, painting, writing songs—your first attempts are going to be garbage.

 

Just know that it’s okay. Keep trying. Failure is a part of the process.

 

Do you remember your first big bug? Not something that was caught by QA or pointed out by a senior dev in code-review, but something that made it to production?

 

I’ll share mine.

 

When I first started out as a software developer, I was working for a Fintech start up that dealt with loans for vehicles. I drafted up a query that would find any vehicles that had duplicated VINs (vehicle identification numbers) and pull them up during the loan approval process. Here’s a dummy example of what that code looked like:

 

 

As soon as this change got merged in, I saw this neat little message on slack.

 

 

I was terrified, and also confused. This was my ticket, my code, but I had no idea where I went wrong. The code had passed code review, and it looked right.

 

So, what was the issue?

 

Turns out that to save time, some dealers would list cars with a dummy VIN (think 0000000), and then would update it after the loan had reached a certain stage. This is totally fine, except my code was pulling in every single one of those vehicles with a dummy VIN and causing the page to take so long to load it was essentially useless.

 

The fix? Adding a limit.

 

 

I’m going to be honest, when I first started coding, the idea of performance and query limits hadn’t occurred to me. Since then, I’ve worked at companies where scale matters, but also in apps where saving seconds leads to more user engagement, meaning performance is always top of mind.

 

This was something I had to learn, and failure can be a great teacher.

 

I also want to emphasize the response from my team. It was to get the bug fixed, merged in, and discuss how it happened in the first place. The important thing about failure often isn’t the failure itself, but how you and everyone around you responds to it. There was no blame, there was no ‘you should have known better’, and I wasn’t shamed for my mistake.

 

Understanding Failure

We’ve covered getting familiar with failure. Now let’s dive deeper into understanding failure and its counterpart, shame.

 

Shame:

• “Shame is a highly aversive emotional experience that is integrally associated with avoidance and withdrawal tendencies.” (Mascolo & Fischer, 1995)”

• “Reproach we feel for ourselves when we have fallen short of our standards.” (H. B. Lewis, 1971)

• “A failure to live up to roles or goals.” (M. Lewis & Haviland-Jones, 2000),

• “When a person feels that he or she is becoming his or her undesired or feared self.” (Gilbert, 1998; Ogilvie, 1987)

All of the above are pulled from scientific articles as definitions of shame. While the wording changes depending on the writer and publication, there is one thing that almost everyone agrees on is that

 

Shame is a relational emotion.

 

What does that mean? You can be angry because your foot hit a rock, or feel sad because the weather has changed. But shame is different because you can only experience this in relation to other people. I can’t feel shame without an audience or my perception of an audience.

 

“From this perspective, the function of shame is to evoke behavior designed to hide the self from the scrutiny of significant others, thus minimizing the likelihood of loss of love and rejection.” (McGregor & Elliot, 2005)

 

If we extrapolate the meaning of the above phrasing, we can hypothesize that shame originated as an evolutionary response from tribal times. In other words, you would experience shame, hide what caused you to feel it, and therefore your tribe wouldn’t reject you because rejection essentially meant death. While times have changed, the impact the emotion has on us is still visceral.

 

Fear of Failure

One scientific study defined the fear of failure as such: “The capacity or propensity to experience shame upon failure” (Atkinson 1957). Another posited “Individuals high in fear of failure reported greater shame upon a perceived failure experience than those low in fear of failure” (McGregor & Elliot, 2005).

 

We can visualize this through the shame/failure loop.

 

 

1. You fail at something.
2. You feel shame because of that failure.
3. Shame is a powerful adverse emotion that you don’t want to experience, so you want to avoid failing.
4. You fear failure.
5. The next time you fail, you feel even more shame.
6. Your fear of failing becomes even stronger.

Also, let us not forget that in order for you to experience shame upon that first failure, you need other people, (or your perception of other people) watching you.

 

This is one take on the fear of failure, and personally I find it very compelling. Like much of psychology, one possible origin of this fear is from childhood, specifically when parents are highly responsive to failure but ambivalent to success (McGregor & Elliot, 2005). It can also develop at any point in life though. Remember what we mentioned before?

 

It’s not so much the failure itself, but how you and everyone around you responds to the failure.

 

Okay great. We get that failure exists, we get why people might fear it… How can we become open to embracing failure?

 

Embracing Failure

Part of embracing failure stems from finding ways to be more resilient to it.

 

So, how do we build resiliency?

 

De-Catastrophize Failure: When we fail, we tend to have three dominant thought patterns.

1. Personal: This is all my fault.
2. Pervasive: This always happens.
3. Permanent: Everything is ruined now.

However, we can examine these beliefs further. Did anyone else have any input or involvement? Has there ever been a time where this failure did not happen? Is there nothing salvageable about this situation?

 

Understanding how our brain works and the common thoughts we might have about uncomfortable situations allow us to prepare for and embrace failure. It’s not all our fault, we don’t always fail, and everything is going to be fine.

 

Show yourself compassion. Pretend you are consoling a friend in an identical situation. Would you ever tell someone who made a mistake that they ruined everything? Of course not. Don’t do that to others, and don’t do it to yourself.

 

Pre-mortem: A pre-mortem is done before a project or initiative where the individual or team imagines that it has failed, and works backwards from that point to prevent those failings from happening.

 

Post-Mortem: After the event has occurred, establish a timeline of events and brainstorm action items around how the failure happened and ways to prevent similar instances going forward.

 

Interrogative Self-Talk: A common practice for giving yourself a pep-talk is to hype yourself up with “I can do this” statements, but there’s strong evidence suggesting questioning yourself can be a more effective method

 

This is the difference between asking yourself Will I vs. I will. By asking yourself, “Will I be able to do this?” you have to reinforce the fact that you can, and have the skills to do so.

 

A series of experiments (Senay, Albarracin & Noguchi, 2010) were conducted where they had groups prime themselves with questions or assertions. Interrogative primers performed better every time. Asking these questions is a motivator of goal-directed behavior.

 

Building Psychological Safety: Having an environment you can feel safe failing in is paramount if you want to take risks and innovate. Building psychological safety is hard but so, so important.

 

Here are some suggestions that help create that type of environment.

1. Have leaders be willing to be vulnerable.
2. Encourage empathy and reassure your teammates when they need it.
3. Build in feedback loops so that everyone has a voice and feels heard.
4. Introduce an event where people share their own failures.
5. Create a space where you encourage people to try new things, like a hackday or hackweek (we have one per quarter here at PagerDuty).

Conclusion

I want you to step outside of software development for a second, and just think about your life in general. Failure is something that trickles into every crevice of our livelihood. Have you ever made a comment or heard a friend say any of the following?

• I can’t cook to save my life, so I just get take out.

• I can’t sing, so I’ll sit out karaoke.

• I’m a terrible dancer, so I just don’t do it.

Could there be an underlying fear of failure behind any of these statements? They don’t mention whether they like to do this activity, merely that they’re not good at it. Is this shame creeping in?

 

I’ve been talking about this as if it was something you’re aware of at all times, but a lot of this can be so internalized it’s subconscious. You could have these fears and not even be aware of them.

 

Let’s revisit the original definition of failure: trying at something and not succeeding. Even if it’s likely you will fail, I really really hope you at least try. Remember, you’re not new to failure. Learning to speak, drive, cook, and any other skill you have all involved failing at some point. The old adage of ‘if at first you don’t succeed, try, try again’ still holds true. Hopefully you’ll go and try something you’re afraid of today!

 

Source