People mostly want to perform at their best; they want to be recognised for leading, winning and generally improving. On the flip side, few wish to be perceived as getting worse, failing, or not trying their best. As such, we often hide failure from others.
My experiences in the software industry have taught me that the word “Failure” is rarely welcomed. Many times, I have been advised to use alternate words such as “unscheduled issues”, “unquantifiable bottlenecks” and my personal favourite, “undocumented features”. Regardless of how you define failure, failure is an acceptable outcome in any project. What matters is what you do when you find it.
It takes hard work and an iterative determination to create a product that people want to use. James Dyson, the inventor of the Dual Cyclone bagless vacuum cleaner created over 1,000 versions before going to market. This may seem a lot for a product that already had a foothold in most households; however, Mr Dyson had a vision to make a better, more efficient product that consumers did not recognise they may have wanted. Although, each and every incarnation of the vacuum brought to light another issue; Dyson learnt from the issue and made incremental success with the subsequent products. A similar process should exist in software production, where we have a vision for a product, we plan how it will be built and we make incremental success out of failed builds and tests until we reach a point where the product can go to market. Developing software requires a Product focus with a mind set where failure is accepted as passage to success.
Success, like the phoenix rising from the ashes, often emerges from failure. It would therefore make sense to promote success by making it possible to review failure without repercussions. Enabling teams to openly discuss failure and subsequently plan a way forward will remove pressure and motivate the team to improve without concern for retribution.
But what if things are going well? How often do you comment on how well a project is going, and then announce that sweeping changes are to be made to make it go even better? However, when change is needed to address a failure we often deliberate at length and assess the permutations whilst looking for success, or react quickly and wait for the outcome and, if needed, react again.
Find your next job with computerworld UK jobs