Learning Effective Failure

Many thanks to Chris Mero for the reference to this short interview with Lawrence Krauss, a theoretical physicist from Arizona State University. Given that “theoretical physicist” was one of the careers I really wanted to pursue, I have a natural soft spot for this podcast. The fact that it also includes this quote doesn’t hurt:

But I think we do a much better job and a much better service to our students if we try and teach our students to fail more effectively.

How to Fail

A little wisdom from Mr. Godin to get your Monday off to a strong start. I particularly like the last suggestion:

When you fail (and you will) be clear about it, call it by name and outline specifically what you learned so you won’t make the same mistake twice. People who blame others for failure will never be good at failing, because they’ve never done it.

You Are Solving the Wrong Problem

Many thanks to Stacey O’Connor for the reference to this fantastic article on how a human-powered airplane was crafted. As technology as an industry or department continues to shrink due to advances in models like cloud computing, I theorize that those workers and models will be transformed into process developers: business process, product design process, fundamentally design process. The key quote:

The first airplane didn’t work. It was too flimsy. But, because the problem he set out to solve was creating a plane he could fix in hours, he was able to quickly iterate. Sometimes he would fly three or four different planes in a single day. The rebuild, re-test, and re-learn cycle went from months and years to hours and days.

It is interesting to me that this story of process and failing fast uses flight as the example, as the original use of the term “fail fast” that I remember was in this Freeman Dyson interview:

Say something about failure in experiments or businesses or anything else. What’s the value of failure?

You can’t possibly get a good technology going without an enormous number of failures. It’s a universal rule. If you look at bicycles, there were thousands of weird models built and tried before they found the one that really worked. You could never design a bicycle theoretically. Even now, after we’ve been building them for 100 years, it’s very difficult to understand just why a bicycle works – it’s even difficult to formulate it as a mathematical problem. But just by trial and error, we found out how to do it, and the error was essential. The same is true of airplanes.

This brings up an interesting issue of where theory fits in. Presumably there was not a theory of planes before there were planes.

There was an attempt at a theory of airplanes, but it was completely misleading. The Wright brothers, in fact, did much better without it.

So you’re saying just go ahead and try stuff and you’ll sort out the right way.

That’s what nature did. And it’s almost always true in technology. That’s why computers never really took off until they built them small.

Fail fast, my friends, and take flight.

GLSEC 2011: Migrating Core Enterprise Applications to the Cloud.


In the last year, the Interlochen Center for the Arts has moved from an antique on-premise ERP/ CRM solution to two cloudy offerings: Enrollment Rx for admissions to both our summer camp and arts academy, and Convio Common Ground for our advancement and fundraising department. Both of these solutions reside on the Salesforce.com platform, a delivery model that is providing significant financial and time savings for our IT organization along with process improvements for our business units. Interlochen has also migrated away from on-premise Microsoft Exchange and adopted Google Apps for Education, which provides email, document collaboration, enterprise calendaring, and instant messaging.

At the 2011 Great Lakes Software Excellence Conference (April 16th in Grand Rapids), I’ll provide an overview of how these efforts to move to the cloud have benefited our institution and, just as importantly, outline the challenges we overcame in an effort to save others the same heartaches — or to at least prepare them for similar challenges.

Please come join me for a great day of learning and networking. The Starbucks is on me!

Fail Fast and Fail Hard

I haven’t traditionally considered Pete Drucker’s work in the context of failing fast, but apparently I should have been based on this article. Tying the concept specifically to design thinking is a useful model, and hearing the Drucker Institute itself articulate the philosophy is compelling.

I also love how so many references to fail fast are immediately refuted by someone who disagrees with the idea and suggests an alternative, which essentially agrees that failing fast is a good idea but uses softer language like “learn quickly.”

Perhaps everything really is semantics.