Syndicate content

Running your own FAILfaire

Michael Trucano's picture
epic fail
epic fail

It's fine to celebrate success but it is more important to heed the lessons of failure, Microsoft founder Bill Gates is meant to have once remarked.  Those of us who have worked for any period of time on educational technology projects, or on international development projects (let alone in the space where these two areas meet!), will have come across at least one project that 'failed' -- and perhaps did so spectacularly.  How might we learn from such failures?

One way to do this that is gaining traction in increasing numbers of organizations is a FAILfaire.  What is a FAILfaire, you ask?

In the words of the MobileActive NGO, which has been a big proponent of the approach,

"While we often focus on highlighting successes in our field, it’s no secret that many projects just don’t work – some don’t scale, some aren’t sustainable, some can’t get around bureaucratic hoops, and many fail due to completely unanticipated barriers. At FAILFaire we want to recognize the failures: the pilots that never got anywhere, the applications that are not delivering, the projects that are not having any measurable impact on the lives of people, and the cultural or technical problems that arise."

Writing on the World Bank's Education for Global Development blog, Ariel Fiszbein, the World Bank's Chief Economist in the Human Development Sector (which includes health and education), notes that "Publicizing what doesn’t work is a fundamental part of any approach to evidence-based policy.  Lack of results is a likely outcome of any innovation. We should remain open and even celebrate those that bring us the bad news as they are helping us stay honest."

Or, in the words of the Dutch Institute of Brilliant Failures (there really is such a thing!), "sharing lessons from what hasn't worked can stimulate entrepreneurial thinking and behavior (in the broadest sense of the word) by encouraging people to develop new ideas and enabling innovators to turn ideas into reality". Such efforts could be wasted in a culture where failure is seen as shameful and few are prepared to take risks. A FAILfaire -- a term that appears to be novel enough that it is still not in Wikipedia -- is one small attempt to help change such a culture.

OK, you might say, I'm with you so far.  Conceptually what you say makes a lot of sense.  But what is attractive in the abstract can become decidedly less so when you try to translate such laudable sentiments into actual practice.

The World Bank has hosted three FAILfaires in the past 15 months or so: two were open to the public (we wrote about the first one on the EduTech blog, ICTworks recently posted a wrap-up of the second), and one was a strictly an internal affair.  In the past week I have been asked by three different organizations for advice on setting up an internal FAILfaire.  While it is always flattering to be asked for advice, I must admit being seen as a 'go-to guy on failure' does leave me a little conflicted. So be it: In case it might be of interest to any other organizations, I thought I'd quickly share some of what I've learned about how to run FAILfaire events, based on my own personal experience as both organizer and participant, and as a result of discussions with my colleague Galina Voytsehovska, whose excellent short paper on this topic recently won an internal knowledgement management award here at the World Bank.

First, it is important to note that we used the excellent general FAILfaire template put together by MobileActive.  Everything that is described below owes a tremendous debt to the innovative thinking and direction that the good folks at MobileActive have provided in this area.  If you're interested in hosting your own FAILfaire, I'd suggest you first have a look at the MobileActive guidelines, and then come back to this blog post here.  For our context, doing a FAILFaire as an internal event meant that we had to change a few things -- and we introduced a few additional new 'innovations' as well. (Some worked well ... some didn't. See below.)

An important caveat: It was important to note that at no point were we really 'celebrating failure' (this is a goal expressed by some FAILfaire organizers).  While I understand the intention that is meant to be embedded in this phrase, this is a rather dangerous (and incorrect) formulation in many contexts, I think, for a number of reasons.  Our goal for the event was to provide a space where could celebrate taking risks and the open and honest sharing of information (even and especially about what doesn't work or isn't working) so that we could learn from these things.

In many of the types of institutions that could perhaps most benefit from open discussions of 'failure', enthusiastic rhetoric about 'celebrating' mistakes might well be counterproductive.

It is possible to talk with colleagues and peers about things that haven't worked in an informal way while at the same time not losing track of the fact that much of what is being discussed is serious business, with serious consequences for mistakes and failure of any sort.

"Celebrating failure": Such language may be catnip to critics of your organization or the industry in which you work -- as well as to people looking for sensational headlines and posts on Twitter.  It can also be difficult to get some managers to agree to let their staff participate an event with this theme.  (I discussed this concept with one person whose response was: 'My employees are free to celebrate their failures -- if they wish to do so, they will have a lot of time for this as they are standing in the unemployment line.')

FAILfaire organizers are encouraged to plan ahead and anticipate danger areas
FAILfaire organizers are encouraged
to plan ahead and anticipate danger areas

With that in mind, internal FAILfaires might wish to have the following two core general objectives:

  • to draw lessons from experience and see how it may be useful for other colleagues who are working on similar projects;
  • to foster more open dialogue among staff about how to identify and respond to project challenges of various sorts, in the hopes of making them more successful.

Our seven ground rules (adapted from the MobileActive FAILfaire guidelines) for presenters were:

  1. No names (i.e. you can't talk about other people by name; as a gimmick, we referred to all presenters by only their first name and last initial, e.g. "Mike T.").
  2. No blame (you can't blame others)
  3. No recording (including no webcasting, no blogging, no live Tweeting of identifiable information, no archiving of presentations on the Intranet)
  4. You can only speak about projects you worked on
  5. Chatham House Rule applies
  6. 7 minute time limit per presentation
  7. Audience participation required

We advised presenters that they were free to change the names of anything in the project they were to discuss.  We did not have an open Q&A session, in an attempt to limit 'speechifying' from the audience as well as to avoid situations where audience members don't follow the same rules that presenters are using and try to name names, assign blame, etc.  The idea here was to help make the presenters feel as comfortable as possible, and to lessen the opportunities for cranks and trolls (in the Internet sense of the term) to be disruptive influences.

We were very strict about the seven minute time limit:

  • An electronic clock (actually an iPad running a stopwatch app) was set up directly in front of each presenter to help them keep track of time.
  • Slides were set to auto-forward and change after 1 minute (presenters were free to advance them more quickly if they wished).
  • We used a large Chinese gong to signal the end of each presentation (this would get progressively louder each time we sounded it, eventually drowning out the presenter, at which point the audience was prompted to applaud enthusiastically).

Presenters were asked to prepare a single question for audience response; the audience then used handheld voting devices to 'answer' each question in real time immediately upon the conclusion of each presentation.

We were able to recruit ten brave souls as presenters for our internal FAILfaire.  We made sure to have an equal number of men and women, so as not to associate 'failure' too closely with one specific gender.  (That said, we did find it interesting that it was much more difficult to recruit men as presenters than women, a fact which occasioned a rather lively discussion in its own right.)

For what it's worth:

  1. Convincing people even to participate was a rather herculean task. The three 'worst' presentations (or so I've been told) were from people who were among the first to agree to participate.  The more people we added to the agenda, the easier it was to convince others to join in.  (Frankly, I think having even 'bad' presentations is not such a big deal -- as long as there aren't too many -- as the whole point is to promote/foster a culture of sharing, and if everything is too slick, this may intimidate some staff, who may be less likely to volunteer to participate in future sessions).
  2. As noted above, we used a gong to try to keep people to their seven minutes.  Most did (only one person had to be gonged multiple times -- seven separate times in total before the plug was pulled!).
  3. In between presentations, we put up slides with quotes about failure.
  4. Stage management is a real issue when you try to move things along as quickly and cram in as many people as we did.  This is something that should definitely be rehearsed beforehand. We had a number of glitches in this regard.
  5. We used interactive response devices ("clickers") as a way to solicit audience feedback.  These are handheld polling devices that you can use to respond to multiple choice questions displayed in a specially prepared PowerPoint presentation. As we did with the fast pacing, we had some implementation challenges with this, but it something to consider, as it is a potentially valuable tool to help quickly engage with an audience in a useful but limited way.
  6. Following on the excellent example from the summer 2010 FAILfaire organized by the World Bank Institute (WBI) and MobileActive, we tried to adopt and promote a very informal, friendly presentation style. (One 'joke' that seemed to go over well was repeated references to the 'F word' ... by which I meant 'failure', of course, but we let this hang in the air for awhile.)
  7. We promised the presenters that we would not make the slides available after the event.  Nothing was archived on the Intranet.  No tape was made. The internal bloggers did not blog about it.  These were concessions to secure people's participation. We would have preferred to share more information, more widely ... but our first priority was to make the presenters feel safe and supported.
  8. Some of the people who OK'd the internal FAILfaire were a bit worried about the event. To be honest, I don't think a number of these folks exactly understood what we planned to do. (We were, for example, asked not to use the word 'failure' in the title, and to 'focus on success'. We, um, accidentally forgot to do these things.)
  9. A number of people pre-cleared their presentations with their managers -- something which we encouraged.
  10. We went out of our way to ensure participation by very senior and well-respected staff members in the event to make opening remarks.  In addition to the content of what these folks said (which was excellent, of course), we wanted to show that there were senior, well-respected staff involved in the event, which was meant to implicitly signal support 'from the top'.  Many people have said things to the effect of "you should have had more managers, etc. involved".  Yes, that would have been great, but we did the best we could. (For those seeking to do something like this within their own organization: Good luck to you on this count.)

The feedback I've had from people who participated in the internal FAILfaire has been very, very positive. Are things like a FAILfaire the answer to promoting greater openness and transparency within an organization?  Of course not, but as part of a larger concerted effort towards promoting more sharing of information within an institution, something like this can perhaps be quite useful.  It can also be used to help energize younger staff: Interestingly, there appeared to be a bit of a split by 'seniority' of people within the institution.  Generally speaking, the reactions I had from folks under, say, age 35, contrasted quite a bit with those from staff over age fifty (read into that what you will).

So: If you're interested in running your own internal FAILfaire,

Good luck.

(Please make different mistakes than we made.)

And, as they like to say in Silicon Valley:

Fail forward, fail fast, fail better!

You may also be interested in:


"There are no secrets to success. It is the result of preparation, hard work, and learning from failure." -Colin Powell


Note: The image used at the top of this blog post of a train wreck at Montparnasse station in Paris ("epic fail") is in the public domain and comes courtesy of Wikimedia Commons.  the image of the warning sign in the middle of the blog post ("FAILfaire organizers are encouraged to plan ahead and anticipate danger areas") comes from Paul Downey via Wikimedia Commons and is used according to the terms of its Creative Commons Attribution 2.0 Generic license.
 

Comments

Submitted by Ian on
Congratulations on successfully organizing an internal failfaire and on doing such an excellent write up of the mechanics and the lessons learned. I attended the first Failfaire organized by Mobileactive in New York and was inspired by it to try to do the same as an internal event in the organization in which I was then working. I was unsuccessful at getting this to happen, encountering but not overcoming some of the same issues you mention in your blog. I even write this up a my own failure in a recent blog post: "KM Triple Fail No Faire" http://kmonadollaraday.wordpress.com/2011/10/17/km-triple-fail-no-faire/ I was happy to learn recently that the next "public" failfaire will in fact by hosted by the organization I used to work for (no credit to me), and once I heard I was among the first to volunteer to present - I hope that doesn't bode too badly for the quality of the presentation....

Submitted by JoeN on
Mike, "Those of us who have worked for any period of time on educational technology projects, or on international development projects (let alone in the space where these two areas meet!), will have come across at least one project that 'failed'" As I'm about to QA the final report on exactly this type of project, thanks for an amazingly timely post! The one thought I'd offer, is that it's rare in my experience, that projects of this type ever have in place anything but the crudest metrics aimed at measuring success. The one thing your piece made me determined to do was design better ones in future.

For what it's worth, we recently ran another internal FAILfaire event and, because this blog post here still seems to generate a steady amount of traffic, I thought I'd provide some information on some new things that we tried this time around. Our recent FAILfaire event was over 2x larger than the one I wrote about above. Scale brings with it a new set of challenges -- trying to keep a level of personal engagement when you have over 350 people in a room can be rather difficult. We laid out index cards on every seat in the auditorium, with space for people to write a few sentences about (1) a project failure of some sort in which they were involved (2) what they learned form this. As people filled these out during the course of the event, they raised their hands and someone ran over to collect their cards. In the short periods between presenters, the MC then chose a few cards to read aloud while walking through the audience. This was an attempt to give a 'voice' to people in the audience, while at the same time keeping to a tight schedule (and avoiding a situation where an audience member was given the microphone to share information about a failure and they either (1) talked for too long (2) gave a speech (3) was critical of a presenter, or what a presenter said). We again enthusiastically used a gong (as described above), and the recent popularity of a certain Korean rapper meant that that cheap jokes about having at times to resort to gong-nam [sic] style were too easy to resist. We again used interactive response devices ('clickers') to poll the audience after each presenter. Given that we only had 120 or so of them, we spaced them three chairs apart, and had people pass them in a choreographed way after each round of voting so that a new group would be ready for the next vote. (We also made sure to collect them *before* the end of the event, to lessen the chance of some of the devices going missing.) The main goal of this FAILfaire was, as in the one described above, to create a space for people to talk openly about some of the types of things they normally don't talk about openly. In doing so, the hope was that a few people in the audience would be sufficiently energized by what they heard and the dynamic in the room to organize one of these sorts of things themselves. For those of you looking to organize this sort of thing yourself: You may wish to set a goal for yourself to get enough people excited about organizing this sort of thing so that you yourself do not become a go-to person within your institution around 'failure' (a designation perhaps best avoided), and can hand over the reins to another person when there is demand for doing another event of this sort. note: This January 2013 FAILfaire was one in what is now a loosely coordinated series of related internal events trying to learn from 'failures' of various sorts, a movement that has received increased momentum over the past months. Those interested in this topic or type of thing (which you presumably are, if you have read this far down the page!) may also be interested in some related comments from World Bank president Jim Kim, http://www.linkedin.com/today/post/article/20121211162106-32702694-big-idea-2013-learning-fast-from-failure

Add new comment