Do you remember the first time you played a videogame? Do you remember spending hours trying to get the plumber to his damsel in distress? Or trying different timings on a jump to get to the other side over a ravine? Do you remember not making it?

I don’t remember not making it. I remember the feeling when the plumber and his lady friend are reunited. I remember the rush when I cleared a difficult jump. I even remember the physical steadying of my focus as I went on to the next level, but I don’t remember not making it.

There is no doubt that I spent more time trying to win the game than actually winning it. And yet this is not what defines my experience. I think it’s because really great games strike the perfect balance between reward and failure. It’s fun because the failures are small and the rapid-fire lessons lead to big, exciting successes.

In life, in business and certainly in software development, it’s harder to get this balance right. Failure is expensive and embarrassing when it’s big. This leads many businesses to actively and institutionally avoid it at all costs.

Companies, especially the big ones, tend to create vast and complicated processes to prevent failure. It works really well. Failure is rare in these systems – unfortunately, it’s just as rare as inventive thinking, leaps of faith and intuitive innovation.

Now, before you think I’m advocating a careless attitude to failure, let me be clear. Uncontained, unfocused, unconsidered action is not productive as little can be learnt from it.

What I am advocating is the creation of fail-friendly environments where a lot of thought has gone into creating opportunities to try, test, adapt and learn in pursuit of the big, epic win.

The hardest part is identifying the problem. It takes time to understand and identify fully what specifically needs to be solved. This is especially true when dealing with the complexity of really ambitious problems. (And aren’t the big problems the most beautiful ones.)

Once the core problem has been identified, you need to break it into really tiny pieces. The testing is easy, quick and cost effective when the tasks are small. The financial risk of failure is reduced, which means small and rapid failure can be normalised and integrated into the development cycle.

Lean Start-up’s Eric Reis has some great ideas on how to structurally endorse and internalise failure for a business. The build — measure — learn system puts the potential for failure in the centre and advocates as little time as possible between these three actions to reduce the team’s emotional investment in the build’s success.

His process removes the stigma of failure for a development team, but I caution people from elevating his process beyond its usefulness. Solving the problem must still be the objective, rather than following the process perfectly.

In my experience, it takes the following elements to create an atmosphere of productive failure.

The first is a culture that encourages small, rapid failure while still keeping an eye on the big ambition. It’s a balancing act. If we over-focus on the small, incremental bits of build, we will never solve the big, scary, ambitious problem.

The second is also a cultural element. The team must be driven by curiosity and the insatiable need to know. By choosing exceptional people who share the dream and see beauty in the complex problem, the team will be energised by finding solutions.

The third is celebration. Celebrate when you learn something, and celebrate when you get it right. Find something that gives the team the same feeling as when the damsel is saved, the dragon killed or the race won. Make sure you remember that, rather than the times you didn’t make it.

Finally, remember its all a game called “let’s solve this thing”. It should be incredibly playful, fun, interesting and inspiring, and sometimes you get to change the world.