Some of my most spectacular failures were not the ones where I was up late at night coding by brains away trying to figure out some new problemset or use some new language – “Okay, so that’s what happens when you take up all the memory”. No they were the ones where mine, the team, maybe the company’s back was up against the wall and I had to figure out things on the fly – maybe it was when I gave a technical presentation when the audience was expecting sales content or when I uploaded an older set of files to a new site and had to learn how to recover the files or when our demo wasn’t ready but I was asked to present what we had and build a story around it.
Perhaps my delivery wasn’t as polished as it should have been or the customer wasn’t as pleased with the latest “same” updates as they had thought they were getting and our internal team didn’t fall over in their chairs when my demo broke for the third time during the presentation (or fifth button click).
I did learn that it was important to figure out your audience before doing a presentation and source control, versioning and labels are a great set of steps on way to pre-validation of a deployment and that getting customer feedback earlier in the demo cycle helped make the end product better. In all those cases though, someone stepped back, let me run and let me fail. They could have jumped in at any point, put the brakes on, told me what to do – but they didn’t.
They gauged the risk and let me try.
It’s not enough that we preach about failure and letting people try and try again if you are not going to let them do it when it really matters. If it doesn’t matter, i.e., it’s something insignificant, it won’t matter to them.
Let the Fail… and in the end… watch them grow.