Running your own FAILfaire

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.')

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:

• My colleague Galina Voytsehovska, with whom I worked on the internal FAILfaire event, won first prize in the IFC's 'Smart Lessons' competition for her essay on How to Discuss Failure—and Not Get Fired! Lessons from a 2011 Human Development Forum Session. If you want additional background and guidance based on our experience with this internal FAILfaire event, Galina's essay is highly recommended.
• For a (somewhat) contrary view on this stuff, you may wish to have a look at Jason Fried's Learning from failure is overrated post on the always engaging 37Signals blog (be sure to have a look at the comments section too).

---

"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.