Of all the questions you could ask a person, asking them to recount the 'worst mistakes' they have ever made might be one of the touchiest. However, that uneasiness might be all the more reason TO ask.
In his book, Success through Failure, Henry Petroski explores failure as being essential to learning and ultimately, success: thus debunking the model that only 'success breeds success.'
So, let’s put that illuminating question to the team here at CM Crossroads.
If one accepts Petroski’s premise that people can learn from their mistakes (which I do), then one most probably would not subscribe to the notion of doing the same things over and over again. This idea segues nicely to a common definition of insanity- that is, expecting different results by repetition of the same actions.
And with regard to these lessons learned. Are they really internalized?
It's been my experience that lessons learned, even when formalized in a classic framework, do not guarantee learning. Learning happens more frequently when it is culturally possible and fostered by management throughout the ranks.
Learning really is the opportunity part of 'worst mistakes'- hence the reference to Petroski.
To keep this light, though on point, here are the tracks to my 'Worst Mistakes' blues CD:
1. Forgetting the Reason which prompted your action:
I think you could apply this principle to every corner of life. It is very bad to loose sight of the reason you started something, launched a project, or even why you maintain certain relationships.
This is what allows madness to have its own life. I look at software development in very much the same way. At some juncture, and usually at great cost, the ego must be checked and remembering the reason you started a project should take the foreground.
Though, I can't say I've actually witnessed this acknowledgment too often, you know the usual suspects: Technologies seemingly selected as resume boosters or for some idiosyncratic bias, good money thrown after bad because 'we've invested so much already' or just simple disconnects from the folks whose input is so critical to the reason.
The end game should never fall into obfuscation. If you set out to build something, its purpose shouldn't be so opaque as to remind others of cable guy Roy Neary's mountain project in 'Close Encounters of the 3rd Kind'.
2. Ego over Reason
Yep, this is a crippler. We've seen multi-million dollar technology projects roll past all projections of time and expediture. Changed requirements provided by the business, but wait, none of them are with the firm anymore. Gee, so now you're building out infrastructure, coding applications, hyping expectations and when you finally get to the dance your date says "why did you wear THAT? and oh, I didn't know you drove an '87 Escort...".
Ego hurts. Well, sometimes it kills. And sometimes wasted money is just that. Wasted money. Point is, while it takes a lot to admit a mistake and put a stop to the bleeding, your CFO will likely thank you.
In the end, knowing when to kill a project is as important as knowing when to start one.
3. Pedal to the Metal
Momentum. Like ego, can kill.
We always hear about 'ramping up'. We never hear about proceeding with caution; heck, let's just throw that to the wind. Momentum without tangible proof of concept is the equivalent of riding solely on emotion. And while emotion is both powerful and useful, engineering is based on objective facts and proven results. This leads back to reason. So, I would suggest that too much vision and too little proof is another worst mistake.
4. Your Candor makes me Cringe
Jack Welch, in his best selling book Winning, devotes a segment solely to candor and its importance. What he's really referring to is the inability of many companies to allow the truth to surface. Too often, those who speak the truth are regarded as dissenters and are met with reprisal or dismissal. Kudos to