Embracing Failure
Failure seems to be a hot topic these days.
Richard Branson wrote post in support of failures.
There are journal papers that analyze learning from recurring failures.
Acknowledging failure
It's hard to learn from failure it you keep calling it success.
Failure is a great sign to stop, when you are doing the wrong thing. It’s the only way to learn, when you are exploring new opportunities. It’s the rare failure that brings nothing, most offer some partial success.
As engineers, it should be natural to say “Project X failed, and we moved on.” Moving on can be a simple as stopping the bleeding. Often there are useful learnings or artifacts. Regardless, identifying that a project was unsuccessful in its goals is not a blame game. It is the start of a brighter future.
That is not to say that one should walk into a project that is doomed to failure. But any new project involves risk, benefits, and costs. When the potential risks and realized costs exceed the perceived benefits, the economic realities can be hard to overcome.
Failing to Fail
Project failures are not uncommon. One company had spent several years working on a new delivery process system for their product. Although the design proposal identified a clear user need, the architectural model was weak. After several attempts to deliver a comprehensive overhaul, the original effort was abandoned.
Abandoning the project was painful. The termination costs were increased due to the project’s long duration. One important lesson the organization did learn was to control the scope of individual efforts. A few of the software components were extracted and delivered in smaller bunches.
Some of the program managers were reluctant to name this project as a failure. Refusing to properly name the project state’s lack of success meant that discussions about the consequences never happened. An open retrospective of the project could have benefited many parties.
A Better Way
One of my favorite stories about failure is placed in the earlier years of the US space program. It might be said that in those earliest years, NASA’s motto seemed to be “Our rockets blow up”.
On launch days, the entire team would gather in the control room. As each rocket blew up, a wave of disappointment would spread. The managers would take on dark expressions, and wonder about their career choices. The engineers would frown at their desks, then gather up their tapes and telemetry data. On their way out, the engineers would uniformly be cheery and optimistic.
One fateful day, the launch is a success. The engines fire as expected, the rocket clears the launch pad as expected, and the payload sails out in a suborbital arc exactly as expected.
A cheer fills the control room. All the hard work has paid off, and NASA is now capable of launching its own rockets. The managers begin to feel secure in their careers.
Once the early cheers abate, a few of the managers notice that the engineers are now moping around. After collecting their tapes and telemetry data, they glumly meander out of the control room.
One of the managers stops the chief of engineering as he leaves the control room and asks him “Why the sad faces? What is the problem?”
“We didn't learn anything.”
How do you fail?
Subscribe to my newsletter
Read articles from Lee Carver directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by
Lee Carver
Lee Carver
Experienced Software Engineer. User interfaces, distributed services, software tools. Software development and operation at scale in multiple application domains.