EWB loves failure. And so do I, to be honest. I love getting in there, making mistakes, doing things wrong, and generally screwing things up. You probably think I’m crazy right about now, but bear with me. Failing gives you something concrete to grab onto and run with; to analyze, accept, and change. It gives you a basis for learning, once you get past the psychological barrier that tells you that to fail is to do wrong. It’s not.
What are the actual tangible results of failure? If you strip away all the aspects about it that are socially constructed and search for the core of the negative effects of failure, you’ll find that at the very worst, failing leads to some degree of damage. Of this you must be conscious, but before you partake in some activity, realize the long-term effects of the potential damage you could cause. They’re probably less than you expect (unless you’re a colonialist), and realizing this is the key to accessing failure constructively.
At the National Conference in St. John’s in 2009, I took part in a really cool workshop about idea generation in which the mantra “Fail fast, reiterate” was introduced to me. It has stuck since. The philosophy behind this expression is the idea that to fail is really only worthwhile if you’re willing to come back with a new idea, a new iteration with which to tackle the problem. The “fast” bit forces creativity and innovation (two of my favourite things), because it says that you need to get back to the problem immediately. The only way to do so is to generate ideas that look at how you’ll do it differently the next time.
Enough about failure theory; let’s get to the important stuff. I’ve failed in my work. Okay, sure, I fail on a daily basis. In greeting my elders with greetings reserved for younger people, for example. Or telling the acting chief of Sagnarigu that I don’t think he’s really the chief (that didn’t go over well). No, I’m talking about a bigger failure. You may remember a post I wrote previously entitled “EMIS and Data Sovereignty”. Spoiler alert: I basically said that EMIS steals District education data and returns it literally months later, after it is no longer useful.
I wrote this post when I was actually quite angry. I had just spoken to 5 different District Education Statistics Officers who all told me that they didn’t have access to raw EMIS data. I was fired up (I tend to get that way about data) and wrote a list of suggestions for the National EMIS Team right then and there, along with the aforementioned blog post.
Fortunately, I had the chance to attend training for EMIS officers on data access and analysis. I went into this training full of preconceived notions of misplaced data sovereignty and ready to ask some very tough questions of the EMIS Rep running the session. That same rep proceeded to type “EMIS” into an Excel dialog box and BOOM–data, all up in that spreadsheet. Right before my very eyes. It turns out that districts have all of their raw EMIS data stored on their computers in an SQL database that is very easily accessed through Excel.
I was turbo-wrong. I had nothing to be fired up about anymore; cue deflation. In the few moments after I saw all that data appear gloriously projected on the wall of the computer lab, I realized that I had failed. I had gotten too emotionally involved, and had limited my scope of sources of information. Beyond that, I hadn’t questioned my assumptions. To me, the last one is a serious failure, and one that a wise person warned me about before I left for Ghana.
In those few moments, I remember thinking, Okay, time to reiterate. I put my game face on, pulled out my orange EWB notebook and found out what went wrong. The answer? Well, I don’t know if I have the complete picture just yet, but I do have some new leads. I don’t want to take the same path as I did before, so I’m not going to write my thoughts here just yet.
After all, I’ve still got some assumptions to test.