At the IA Summit this year, a few of us presented a panel where we hung out our dirty laundry in front of a room full of voyeurs, many of whom accepted our invitation to come to the mic and tell their own tales of woe.
We talked about our failures—individual, structural, institutional, societal—and not just “failure” in the abstract, but specific situations, specific projects, where we personally failed. We also strove to hold back from blaming stakeholders and clients for these disasters. We owned our catastrophes and spoke about what we learned and why we are doing better information architecture today because of these painful, harsh lessons.
Each panelist addressed a different level of failure: the project level, the organizational level, the institutional level, the global level, but we all talked about why and how we fail, to what extent failure can and cannot be prevented, and how failure is an inevitable byproduct of creativity and experimentation.
With four panelists and a room full of fellows, we felt we only scratched the surface. In the welcoming pages of Boxes and Arrows, we can really let it all hang out, so we are starting a series of articles on failure. We begin with the four case studies we presented in Las Vegas, but also, we hope to include your failures and the lessons you learned. Contact me or one of the B+A editors if you’d like to contribute to this series.
On the panel we worked from the micro to the macro, but here we are going to turn that around and start with Joe Lamantia’s observations about enterprise-level failure and some intriguing parallels from the catastrophic failure of an entire society.
“Take it away”:http://www.boxesandarrows.com/view/it-seemed-like-the, Joe.
Can I just say what a refreshing change it is to smell the dirty laundry. In my experience most of us are busy a lot of time slapping backs and generally confirming how good things are going (even when they are ever so not). It seems in a lot of corporate cultures today it is OK to deride the competition but very “non team player” to criticize internally.
In the past I was a consultant and found that invariably the earlier I went after “the smoke” the sooner the job got done and I was on a plane back home. As such while some folks (team members, partners and customer alike) would avoid conflict by tiptoeing around problems, I was always keen to push them into the open early. It seemed logical to fix things early, get the job done right the first time and so I could get back home on time.
I say bring on the disasters! Publish under a pseudonym if necessary learning from others mistakes is ever so much more less painful – and entertaining to boot 🙂