CWJ: Day -3
Dear Reader,
CodeWorks 09 Vital Stats
CodeWorks 09 day #: -3
Days till I see the Lovely and Talented Kathy:10
Cities left: 7
Miles Traveled: 0
Cups of Coffee: 0
Current Current City: London
Random Statistic of the day
Number of “Random Statistics” that I have waiting to be published: 0
Prep Work
I did no prep work directly last night as I spent the evening with Yair Spitzer and Paul Wander, the heads of Ibuildings UK. On top of a great meal, we had one of the most interesting conversations I’ve had in a long time. I am however, starting to “get my head in the game” so to speak. My downtime these days is spent refining my presentations and practicing them in snippets instead of all at once.
Random Thought: Failure is ALWAYS an option
My good friend Marco Tabini recently wrote an excellent blog post titled “The Importance of Failure“, if you’ve not read it, you should.
Failure is the Sword of Damocles hanging over the head of every software development department. We worry about the consequences of failure so much that in some teams, the mitigation of the risk of failure is the primary activity of the team and not software development. Developers, Managers, Directors, and on up the line need to embrace the fact that developers are human and will fail.
What sets successful development teams and projects apart from the pack is the fact that they learn from their failures. The lesson is not always “don’t do that”. Sometimes the lesson learned is just that you are going to fail sometimes. Successful team don’t hunker down into blame mode, successful managers don’t fire people because of failure. (well, not if they are failing in different ways each time) Successful projects fail until they succeed.
Overcoming failures is a three step process.
- Own the failure.
If the project can be salvaged, the team lead and the developers need to own the failure and find a path to get the project delivered. In the extreme cases, they need to have the wisdom to throw in the towel and cut the company or project’s losses. Sometimes, you cannot wrench success from the jaws of defeat. - Learn from the failure.
Once whatever the failure is is over, take time to celebrate the failure. gather the team together and talk it out. Why did it fail? What could have been done (regardless of practicality) to prevent the failure? Let everyone have their say. Once the team understands the lesson learned, write it down. Make a historical record of the failure, what went wrong and the lessons learned and publish it company wide. Be transparent, let everyone interested learn from the failure. - Move on from the failure
You’ve failed, you know why and you know the lesson. Once it’s published, move on and never bring it up again. A failure is a personal motivational tool if a developer decides to remind him/her-self about it every day so that they don’t repeat it. It is a demotivational tool if management brings it up regularly.
If you are a developer, seek out companies and projects that celebrate failure. If you are a manager, realize that teams will fail and plan for it.
- Mitigate risks whenever possible
- Re-evaluate team members that regularly fail in the same way each time. (Possibly lessons are not being learned)
- Most importantly though, let your teams know that it is ok to fail.
Taking these steps, especially the last one will give your teams the confidence to be productive and creative without fear.
Until next time,
Ég elska þig Matvara dýrust minn Kathy
=C=
Tags: codeworks, cw09, failure, Management, PHP, software development
