It’s axiomatic that one learns more from failure than from success.  After all, success doesn’t immediately demand reflective analysis. If you are successful, it’s clearly because you were brilliant and made all the right decisions (just ask any bailed-out investment banker).  If, however, you fail, you are likely to go through a review of your own limitations and weaknesses and be all the better for it the next time.  Failure and perseverance is a recurring pattern in many, if not all, “successful” peoples’ lives.
What is true of successful people, is also true of successful companies, departments, committees, research groups, and teams.  No group of people gets it right the first time, every time.  They fail.  A lot.  Successful groups learn from their mistakes and try again, or they realize the folly of their endeavor and move on to something more productive, where they will probably fail yet again.
My goal is not to sing the praises of perseverance in the face of ineptitude, but to strongly advocate for embracing your inner loser.  Accept the fact that you stink, that most of your ideas are drivel, and that you are going to be a failure most of the time.  It’s not Sisyphean perseverance that sets the wildly successful apart from the rest of us poor shlubs — we all know people who are persistently bad at what they do, and have no hope of ever being successful – no!, what sets the successful apart is the remarkable speed at which they fail.  You see, the problem, my friends, is not failure itself, but Epic Failure.
The relevant definition of epic being “of unusually great size or extent”, however, in this particular case, I’m going to add “duration” to the definition.  Epic Failures are failures that take too long to happen.  Quick failures, on the other hand, are merely steps on the way to success.
Take for example, the IT project. A typical IT project begins with a dozen or more people in a room to discuss “the problem”.  Everyone in the room, entered the room, with a good idea of what “the problem” was already, but the first meeting is a lengthy discussion of the intricacies and various facets of “the problem”.  Invariably, the project team leaves that first meeting with a larger problem than they had when they entered and the long slough to finding “the solution” begins.
As an alternative, imagine a Skunkworks team – a small group of no more than four, technically capable, energetic, and empowered individuals, who are handed problems and asked to find solutions.  The primary goal of this group would be to fail quickly.  Find a solution, test the solution, present the solution to those who will ultimately use it, discover why their solution is inadequate, and then start again with knowledge gained from their failure.
In a month, the Typical Team will have determined in excruciating detail, exactly what they think they need to look for in a solution, while the Skunkworks team will have understood through a series of quick failures that they actually need something else entirely.  The Typical Team may come to the same conclusion in about six months if they hurry.
There may be projects that require large groups of people performing in depth analysis of the problem and every possible solution, but let’s be honest, this approach has less to do with finding solutions, than it does with avoiding the appearance of failure for as long as possible.  

Recipe for success: 1) Fail small.  2) Fail quickly.  3) Fail often.
TweetLikeEmailLinkedInGoogle Plus
Photo of Ryan McClead Ryan McClead

Ryan is an executive at a small, but well-known legal technology company. Prior to his jump to the vendor side, he served for 3 years as Legal Technology Innovation Architect at Norton Rose Fulbright, running Technology Innovation projects around the world. His sense of humor and remarkable tolerance for verbal and psychological abuse has gotten him through more than 15 years in Legal Technology. In 2015, McClead was named a FastCase 50 recipient, and in 2018, he was elected a Fellow in the College of Law Practice Management. In past lives, he was a Knowledge Manager, a Systems Analyst, an “IT Guy”, a Fashion Merchandiser and Theater Composer.