Fear of Failure
Everybody is afraid of something. Heights is a common fear, some people fear spiders or snakes or dogs or confined spaces or the dark. None of these is exactly rational, but fear is part of the psychological makeup of almost all humans—it is one of our prime motivators. One of the most common fears (30% of Americans apparently) is the fear of speaking in front of a public audience. More people say they fear this more than they do death. This gives rise to the notion a third of the population would prefer to be in the coffin than give the eulogy.
The fear I am concerned with here is the fear of failure. Specifically, I am looking at an employee's fear of failing in the eyes of the manager or in the opinion of his/her peers. You can also think of it as a fear of public ridicule. This is not always a self-grown fear; nevertheless, it is a fear that is possibly the single largest inhibitor of innovation. It is worth looking at more closely.
James Robertson |
Consider this: an employee who is afraid of failure does not make suggestions for improvements or innovations. To do so risks disapproval. The employee knows that the manager's role is almost always to protect the status quo—if something is working, then why allow a disruptive innovation? As soon as the manager, or anyone else for that matter, says something along the lines "No, that's not going to work" or "we don't do that here", then the employee has failed in his/her own terms. So why reveal one's ideas by proposing innovations? They could well be the best innovations the organisation has ever heard, but they are not going to be heard—the fear of failure means keeping ones mouth closed.
Thankfully, fear is not always present. As I visit various organisations talking to them about innovation, I am struck by the dichotomy between the fearless and the fearful. Fearless organisation permit—indeed encourage—their employees to have ideas and start the process of evaluating and refining the idea. I hear things like, "That's a great idea. I have no notion of whether it will fit with our product line, or whether we have a market for it, but let's look further into it." The person having the idea receives nods of appreciation from the peers present, and significantly, all of them feel safe to suggest innovations.
I watched with satisfaction the participants at one of my local government clients. I was running a workshop on innovation, and the teams were responding with some remarkable innovations that would change the services they provide. There was no fear (keep in mind that this is a local government organisation). Instead, the team members made changes to their services without any of the anxious "will we be allowed to do this?" kind of remarks so often heard in these circumstances. I loved the smiles of delight when they realised they were making changes that improved their service—this after all is the point of local government—and in some cases made provision cheaper. I am happy to report that the innovations have a life beyond the workshop. Most of them are now part of the organisation's regular list of services.
It might seem strange that to be innovative, it is necessary to have no fear of failure, when failure is a significant factor in innovation. Most innovations fail. James Dyson needed 15 years and over 5,000 prototypes before he brought his bagless vacuum cleaner to market. The great Thomas Edison—perhaps one of the most innovative people ever to live—is quoted as saying "I have never failed. But I have found 10,000 things that do not work." Michael Dell accepts failure as part of his business. But instead of blame, the Dell peers get together after some failure and determine what—not who—went wrong and what they can learn from the failure.
Not every innovation works right out of the bag. Some do, and some take time before they are ready for prime time. Some sound good at first hearing but reveal themselves later to be impractical. So this kind of failure is part of what we do, or what we should be doing. Accept it. I am by no means advocating that we should reward failure by handing out obscenely large bonuses as seems to be happening to CEOs and Chairmen in the banking and finance industries. I am advocating that we accept failure and treat it as an unavoidable aspect of being innovative.
"You have to be wiling to repeatedly fail—and to be misunderstood." — Jeff Bezos
None of this is meant to say that all we have to do is rid ourselves of fear-inducing managers, or anti-innovative organisations, and all will be sweetness and light. Some people carry the fear of failure regardless of the organisation they belong to. This is neither good nor bad, but simply that people who are afraid of failing will never be innovators.
James Robertson
London
April, 2009
Past Perspectives
The Winter 2008/09 perspective entitled IT Financing was written by Tom DeMarco
The Sumer 2008 perspective entitled Groundhog Day Part II was written by Tom DeMarco
The Winter-Spring 2008 perspective entitled Groundhog Day was written by Tom DeMarco
The Winter 2007 perspective entitled Teams Don't Move
was written by Steve McMenamin
The Fall 2006 perspective entitled Three Hours to Three Years
was written by Peter Hruschka.
The Spring 2006 perspective entitled The Web Undone by Tom DeMarco.
The Winter 2006 perspective entitled Have We Finished Yet?
was written by Suzanne Robertson.
The Fall 2005 perspective entitled Adult Behavior on Projects
was written by Tim Lister.
The Summer 2005 perspective entitled No Great Leaps Forward?
was written by Steve McMenamin.
The Spring 2005 perspective entitled Mastering Software Architectures
was written by Peter Hruschka.
The Winter 2004 perspective entitled Early Involvement of Testers
was written by James Robertson.
Links from this site to Amazon.com or Amazon.co.uk are done
using Amazon's associates program. That means,
that if you use one of the links and end up buying the book, we get a cut.
We are not getting rich on this, but thought that you should know that
it is happening.
The contents of this site are copyright © 1995-2009 Atlantic
Systems Guild Inc. and Atlantic Systems Guild Limited. Material may
be reproduced provided this copyright notice is attached and the source
is acknowledged. Please pay us the courtesy of notifying the author if
you wish to use material from this site.
|
Happenings
2009
James
Robertson teaches Mastering
the Requirements Process in Brussels, August 11-13. Please
contact
I.T.Works.
Brussels, September 7,8. James
Robertson teaches Becoming an Innovator . Please
contact
I.T.Works.
Tromso, September 7,8. Suzanne Robertson is in for Mastering
the Requirements Process part 2 . Contact Den Norske Dataforeningen for details.
September 9-11, Suzanne Robertson is in Tromso for Mastering
the Requirements Process sponsored by Den Norske Dataforeningen
September 14-16, Tim Lister
teaches
Mastering the Requirements Process in Washington, DC
for Software Quality Engineering.
James Robertson
presents Mastering
the Requirements Process in London, September 15-17. Contact
IRM UK Strategic IT
Training
Suzanne
Robertson teaches Mastering
the Requirements Process part 2 in Brussels, September 15, 16. Please
contact
I.T.Works for details.
September 17,18 Tim Lister
teaches
Requirements Modeling. in Washington DC.
Contact Software Quality Engineering for details.
London, September 28. James, Suzanne Robertson and Neil Maiden present a tutorial entitled "Innovation, Creativity and their Role in Business Requirements". Please see Business Analysis 2009 conference for details and registration.
James
Robertson teaches Mastering
the Requirements Process in Brussels, October 6-8. Please
contact
I.T.Works for details.
October 12-14, Tim Lister
is in San Diego to teach
Mastering the Requirements Process
for Software Quality Engineering.
Leiden, October 13-15. Suzanne
Robertson teaches Mastering
the Requirements Process . Please
contact
Array Publications for details.
October 15,16 Tim Lister
is in San Diego for
Requirements Modeling.
Contact Software Quality Engineering for details.
Reykjavik, October 19,20. James Robertson teaches
Becoming an Innovator at the University of Iceland. Please contact Ragna Haraldsdóttir.
Suzanne Robertson teaches
Mastering the Requirements
Process part 2 in Rome, October 26 - 28. Contact Technology
Transfer.
Suzanne Robertson presents
Mastering the Requirements Process in Melbourne November 4-6 for Software
Education
James Robertson presents
Mastering the Requirements Process in Canberra November 4-6 for Software
Education
Wellington, November 9-11. Suzanne and James Robertson present Mastering
the Requirements Process . For details please contact
Software Education
Suzanne Robertson teaches
Mastering the Requirements
Process part 2 November 12, 13 in Wellington. Contact Software
Education for details of this advanced class.
Wellington, November 12,13. James Robertson presents Innovation & Requirements . For details please
contact Software Education
Auckland, November 16-18. Suzanne
Robertson teaches Mastering
the Requirements Process . For details please contact
Software Education
Wellington, November 19,20. James Robertson presents Innovation & Requirements . For details please
contact Software Education
November 30 - December 2, Suzanne and James Robertson are in Sydney for Mastering
the Requirements Process sponsored by Software
Education
Melbourne, December 3,4.
Suzanne Robertson teaches
Mastering the Requirements
Process part 2. Contact Software
Education for details of this advanced class.
James Robertson and
Martin Davie present Innovation & Requirements December 3,4 in Sydney. For details please
contact Software Education
Suzanne Robertson teaches
Mastering the Requirements
Process part 2 December 7,8 in Sydney. Contact Software
Education for details of this advanced class.
Christchurch, December 9-11. James Robertson teaches Mastering
the Requirements Process . For details please contact
Software Education
|
In Depth
Adrenaline Junkies and Template Zombies has won the 2009 Jolt Awards best general book.
The Guild's new book Adrenaline Junkies and Template Zombies - Understanding Patterns of Project Behavior is now available. Orders at Dorset House Publishing and Amazon.com
NEWS: IEEE Software magazine has selected "Provoking Creativity: Imagine What Your Requirements Could Be Like" by Neil Maiden, Alexis Gizikis and Suzanne Robertson as one of the Top Picks for influential articles over the 25 years of IEEE Software. Download pdf.
See video commentary about the Adrenaline Junkies book project.
NEWS: Adrenaline Junkies and Template Zombies has been adopted by the Copenhagen Business School for Prof. Rob Austin's course, "The IT Manager as a Business Leader."
The new Guild book has been published in German Adrenalin-Junkies und Formular-Zombies - Typisches Verhalten in Projekten. The book demonstrates the effect of behavior on project success.
Please visit Hanser or
Amazon.de for more details.
Platicando con Tom DeMarco: interview (in Spanish) with Mexico's Software Guru Magazine. "Creo que todos hemos comprendido que el aspecto sociologico de los proyectos es igual o mas importante que el tecnologico ..."
Suzanne Robertson has written an Executive Report "Requirements for Managing
Requirements" for the Cutter Consortium's Agile Product and Project
Management advisory service. Download a free copy
The Microsoft Store on Microsoft's Redmond campus will for the first time start carrying books from publishers other than Microsoft Press. Mastering the Requirements Process is one they have chosen to stock in this initial test phase.
The Volere Requirements Specification
Template has been translated to Spanish. Thanks to Paul Babic of Smartmatic for the translation. A Microsoft Word version is available from the Volere site.
Suzanne and James Robertson announce the publication of the second edition of their best selling Mastering the Requirements Process
In response to many requests we have started a Volere Requirements discussion group.
|