Fear of change

I don’t like going down stairs. Let me be more precise: I don’t like going down stairs fast.

When I was a kid I tumbled down a staircase, and it was painful and traumatic. I remember going to the doctor, and for some reason I remember seeing my black eyes for days. Since then I don’t dare go down stairs fast, even less if they have no handrail.

“Fear is the enemy of speed”. Only when we overcome fear can we go faster.

Eric Elliott argues in this article that eliminating fear is the most important factor in building a high velocity development team.

Every time we are about to go to production we are scared to death:

What if a critical bug slipped past us?

Or if the user hates the new experience?

And what if the production servers fail?

They are all fears, legitimate or not, plain fears of change.

Change is scary, and our organization is afraid of change.

The role of a development lead, according to Elliott, is to eradicate the fear of change. We have to get to the point where nobody is afraid to change a line of code.

The big problem we have is that development teams are afraid of change, and that is what makes them slow.

They are like me with stairs. I’m sure an eighty-year-old lady would get down a staircase faster than I do, and that’s embarrassing.

The same goes for development: we have to be able to make changes day after day, not once, ideally several times a day.

Ask yourself these questions that Eric Elliott proposes:

1. How long does it take your engineering team to fix a bug and deploy the fix to production?

2. Has your team ever done a “hot fix” of the code in production? Has that ever failed?

3. Can your team prototype and test a major redesign of the user interface on your live site, without affecting the experience of all your users?

4. Have you waited weeks or months for simple changes to be pushed live to your customers?

As Dory said in Finding Nemo, “Well, you can’t never let anything happen to him. Then nothing would ever happen to him”. It’s the same with your development team: if it never faces one of the four scenarios above, it will never become a high performance, high velocity team.

Change has to become so routine that nobody worries about it happening anymore, and changes only happen when we stop fearing them.