The Failure Quota

Not only IS failure an option, it's the best opportunity for your teams to learn!

Creative teams can learn best from the new things, not from repetition. Because of this you need to create an environment where creative failure is NOT failure, but a learning opportunity…

We had to let a recently hired build team member go a few weeks back. Sad, but it was the usual story: their performance clearly did NOT equal what was on their resume. Sure, they had passed all the developer tests and interviews with flying colors, but sometimes things just aren’t what they seem. It happens.

Later that day the lead tech made the comment, “Yeah, he was maxing out his failure quota on a daily basis.” It was a funny, sarcastic comment that got a nice round of laughter from everyone. But it got me thinking… What if your builders actually had a failure quota?

Now, let’s be clear, we’re not talking about “procedural failure”. If the company is paying you to put cover sheets on your TPS reports, put the damn cover sheets on your damn TPS reports and be done with it. Likewise for being at meetings on time, commenting your code, filing your reporting, whatever. The ins and outs of your day to day job is part of your job description and not under discussion here.

We’re focused on what I call “creative failure”. A builder talking about their typical creative failure goes something like this: “Yeah, we have the standard database connection routine, but I thought I had a great way to squeak some more optimization out of it so I tried to recalibrate the dilithium crystal matrix… but it didn’t work. Sorry.” Or some such. My point with this discussion is that we should actually ENCOURAGE creative failure. At least under the right conditions.

Sure, you’re saying, here at Acme DevHell Solutions we encourage our teams to be creative. But, come on, that’s kind of the standard line in this day and age. Everyone says that. But it misses the point I'm making. I encourage my teams to take a certain amount of their time each sprint, to not only get outside the box, but break the box down, pour gasoline on it and set the bastard on fire. Get way out there, way into new territory.

I suggest that you can step up your game… Have the next sprint retro not be a retro at all, have it be a “failure workshop” where they talk about what they learned. Some ground rules though… there’s always ground rules.

1. Absolutely, positively no management or executives attending. No exceptions. This includes you Mrs. Scrum Master. Go grab a Starbucks and let the team work this out between themselves.
2. Each builder gets 10 minutes max.
3. Like a good brainstorming session no idea is too strange.
4. The builders talk about the following things:
   1. What was the problem they were trying to solve. CODE problems, nothing else.
   2. What was their approach and why did they choose this?
   3. Why did it fail?
   4. What did they learn?
   5. How did they finally solve the problem stated in A? And yes, “I reverted to our tried and true methods,” is perfectly acceptable.

Now this might sound like silly talk and you’re probably wondering why you would spend valuable company time on such a thing. Several reasons, actually…

First by formally encouraging the builders to fail and then talk about how they failed you are creating an atmosphere where this sort of thing really is encouraged and not just written on a framed motivational poster hanging outside the east conference room. Whatever position you hold at the company your actions speak way louder than your words; guess which category this falls into?

Second, builders are thought workers. They NEED the safety of knowing that there is a net underneath them and falling won’t mean firing. If they were workers on an assembly line this would be different, but they aren’t. Not even close.

Third, when you rely on someone to be a creative, thoughtfully engaged worker you have to actually let them be that. You need to tell them and show them that its not only ok, but its expected that they will flex their mental muscles.

Finally, if you are going to pay the salary cost of them failing then the failure workshop makes sure that this lesson becomes cultural knowledge. No sense in everyone repeating the same mistake over and over, right?

At the end of all of this I encourage you, and your company’s executive team, to actively promote failure as an acceptable action for your thought workers. They will appreciate it, and who knows when a build team member gets the pleasure of reporting a success instead of a failure.