24 March 2017

Hesitation is Failure

About 14 years ago a very sage friend of mine said to me 'Hesitation is failure'. At the time I didn't really understand what he meant but what I've come to realize is that if you sit around thinking about a problem rather than trying to solve the problem, you are hesitating. So why is that failure?

A different friend told me a story about his experience at West Point that I think illustrates the point. It was during the first week of leadership training when my friend was assigned a squad. The platoon leader had all of the squads muster in a common area. Surrounding them were a number of 55 gallon oil drums. 

When the squads were mustered the instructors, without explanation, started shouting orders to "move" and "seek cover" while others set off explosives in the oil drums. It was total chaos as a half dozen instructors screamed at the squads and the squad leaders tried to figure out what to do. 

As my friend tells it, he instructed his squad to run away from the common area and to rally at a point a few dozen meters away. His squad followed their instructions and he passed the test. Other squad leaders however had frozen in the confusion. It was gently explained that they had succeeded in killing their entire squad. 

What was the point? Well, the squad leaders that hesitated to issue orders and respond to the situation had failed, resulting in hypothetical death and dismemberment. 

Obviously in software the consequences of hesitation are far less significant. That said, when we hesitate we fail. So it is much better to take action, any action, than it is to contemplate and analyze and consider. I guess this relates to my statements about not needing a card for every single thing. But it also has to do with decision velocity. Everything we do has some amount of consideration, so I'm not suggesting that we don't think a least a little bit about what we're going to do. But I am pointing at getting stuck in analysis paralysis. When we are stuck there, we are failing.

So how does this relate to daily team room operations and projects? Well, for me anyway, when given a card to work on, just dive right in. When you have a question about how something works, don't sit around speculating; read the source code. It is perfectly reasonable to take a risk in your development environment, very few things we do can have catastrophic results, and when they do, well, we can guard against them. But the hesitation, the over analyzing, the hand wringing, that is what ultimately kills our forward momentum. So, my suggestion is, stop over thinking things and just give it a try. Get things done by getting things done, rather than over considering weather you should do things.