Love ItLove It

Innovation mroe on failure, and the reality of software…

First off, most organizations support the concept of commitment around failure. No one likes it when we fail, and in many cases, we have an organizational desire to move quickly past failure. I think in many cases, there is a great organizational benefit to remembering, recalling, and learning from failure. I’ve had CIO’s and CEO’s tell me I was crazy for saying that but I believe it is true. If you have an organizational failure learning system, then what happens when you fail? You don’t condemn it you learn from it.

Many organizations in the real world also adopt the stop at failure commitment model — very few organizations power through initial failures as de rigor. In the real world, the first two are the models most companies adopt. Failure is a really bad thing.

When you consider the reality of failure in organizations and the commitment that often accompanies that (to and around) it changes the impact on innovation. Just to note, any organization willing to take a risk is supporting innovation, even if they stop at the first failure. This isn’t about stifling innovation.

A commitment to failure forces creative project realignment. If you fail (and we all do at some point), then you have to figure out if your idea has merit and redesign the solution to fit into another project or idea. It’s like a rider attached to a Bill in the US Congress. (Although sometimes the riders attached to the Bill end up being larger than the Bill itself). In this instance, with failure as a wall rather than a fluid part of the project, you end up with a squishier definition of failure. The definition of failure almost becomes a full stop problem. There are few full stop problems that even time can’t solve.

The commitment around failure means you have to consider the risk of failure in your project and have a workaround quickly available. Sometimes this can cause your project to veer off course a little. Clayton Christensen[1] published the innovator’s dilemma several years ago. In that book, he talked about the chosen path of innovation and the actual path being slightly different. He was addressing the concept of commitment around failure, although I doubt that was his intent. It’s my interpretation of his information at this point.

Software Architects, innovation and inclusion

Software Architects are people who consider what is coming when they design what will be there. In those considerations, where does innovation play? Are software architects looking far enough forward to see what may be on the horizon?

Or even should they? Should software architects be looking at the very edge of what is possible? Sometimes past the edge of what we know, things stop being clear.

It’s a balancing act that many software architects struggle with. How far over the horizon should I peak in building my solution. I’ve asked myself and others that question for years. Based on my thinking over the past few months, I’ve put together some simple rules going forward for architects to consider.

[1] Harvard Press “The innovators dilemma” by Clayton Christensen

  • Question of

    did you know the Altair computer uses switches and didn’t have a keyboard?

    • Yes
    • No
  • Question of

    Have you ever used a computer punch card?

    • Yes
    • No
  • Question of

    did you know OCR was once only done by using punch cards? (optical character recognition)

    • Yes
    • No


What do you think?

16 points

Written by DocAndersen

One fan, One team and a long time dream Go Cubs!!!!!!!!!!!!!


Leave a Reply
  1. I capture the unique reality from your article. For a long time we have read, heard, and maybe even been trained about failure; how to respond to it, and efforts to rise from that failure. Unfortunately, it seems that not all people or organizations are ready or committed to it, at least preparing themselves for innovation failures. Indeed, failure or innovation that failed to involve and drop many things.

  2. Some one told me in the airforce that the pioneer of computers was invented to drop bombs in sequence, such as the Lancaster bomber. To be a bombardier was a specialised job and failure on the way bombs were dropped meant the death of the whole crew of the plane.
    so a system was devised on planes so that bombs were dropped like a card in a slot. It was indeed a type of birth for the invention of computers

    • As always your view is welcomed and I agree!!!! I suspect we can take your brilliant thought and say “people know some areas of innovation, such as medical, computers, and so on. What they now they understand. what they don’t know they struggle with!”

Leave a Reply