I have written in the past about how the language that we attach to failing is part of the fundamental challenge of organisations dealing with the ambiguity of the world we are in. Failure is pejorative, so it’s no wonder that people find it so hard to embrace.
The lessons from the world of agile software development seem to be that if one doesn’t exactly know the answer to a particular challenge, hypothesise, test, evaluate and re-hypothesise to iterate through the loops again. This is much less pejorative language, but unfortunately the overriding organisational culture of “known knowns” that manifests in things like business cases mitigate against agility in our companies and institutions.
But the learning cycle, or scientific method, that is embodied in agile needs to also encapsulate errors that turn out to be the answer. In the world of science and technology many a great discovery has come not through rigorous scientific process, but minor cock-up. From Teflon to penicillin, chaos and serendipity have been the mother of invention.
I was chatting yesterday to someone who once made a mistake whilst running a database extract. She was working for a professional services company that needed to update the information they held about which consultants spoke which languages. A mail merge out of the languages database resulted in an email out to everyone in the company, asking them to confirm details held…
… except that a glitch meant that everyone was listed as speaking German.
The result? A higher response rate to the exercise than anything ever seen before (although much of it irate). Net result? The mistake led to cleaner data.
When it comes to failing most of the focus today seems to be “what can we learn?”. Maybe the greater prizes can come from asking how do we get mistakes into the system to actually answer some of the challenges? We need to not only embrace trying things that don’t work, but also the ability for errors to be in the system to do things of which we would have never thought…
mmitII 