Failure is an option

One afternoon, a few years ago now, the head of my department uttered something completely heretical while we were in a fairly high-stressed meeting about some technical difficulties we were having on a project. It was one of those utterances that made everyone take pause, look at him, and wonder if he was off his rocker.
He wasn’t, for the record. In fact, he was striving for us to not view impending doom as a bad thing. While his two words were at first shocking (especially to the Account Managers present, who’d ultimately have to deal with the client), it was also one of those moments you sat back and actually thought about what you were doing.
So what did he say?

Embrace failure.
– Allard Losier

We are taught almost from the moment we enter this world that failure is bad. Failing means punishment, ridicule, losing respect, or in particularly awful situations, death. In the business world, it can also lead to reassignment, demotion, or even loss of a job. And to be sure there are varying degrees of failure, but they’re all generally perceived as negative.
So naturally, when Allard made his proclamation, I was just as surprised as the others. But unlike some of the others (those who have to deal with budgets, scheduling, and the client had a tougher time accepting it), I quickly began to see the wisdom behind it, and the necessity of that point of view.
At the time, we were in the midst of a particularly tough project, and it wasn’t going really well. Depending on whom you asked, it stunk. It wasn’t because of ability — I am proud to say that I was working with a gifted team of developers. Nor was it because of a poor schedule — we’d (originally) allotted for enough time.
So what stunk? Risk.
Risk is one of those things that few people like. Even investment bankers who claim to like risk only go so far because too much risk could potentially ruin any gains. ย And in the world of business, no-one likes to pay for something that isn’t guaranteed.
That’s a major problem. Not the risk itself, but in the unwillingness to take risk. No risk means status quo. It means doing what’s already been done. It means not moving forward … or even keeping pace. In advertising, this is deadly.
When you’re dealing with technology, you need to always be at least looking forward, if not moving forward. And your development team will almost always push for the latter. Developers, for the most part, hate doing things the same way when they know there’s a better way. Well, at least my experience with gifted developers suggests they prefer a better way.
The “better” way involves risk. You have to do things differently. For you to be able to take that risk, there is one thing you need to do: accept the fact that you could fail. Not that you will fail, but that you might not achieve what you’d planned. And it’s not just you that needs to accept that failure is a possibility: your team needs to know this, your project management needs to know this, as does your account team, client team, and the client themselves.
Awareness is important. Aside from a position of being honest, you really should make sure that everyone understands the risk. (It won’t always happen reliably.) This is a point you should never avoid — fill in the details. No, you won’t gain complete comprehension, but you’d rather have a problem of glazed eyes than have those eyes firing laser beams when you have to tell them that you’re not able to deliver because you took a risk no-one knew about.
We’d walked into our project with a considerable amount of confidence that we would deliver. There was risk that we wouldn’t hit our launch dates, but we felt — all of us — that the direction was better for the end product. Still, it required us to take leaps of faith that we could build what we’d promised, not just internally, but also from our client.
I encourage you to consider the same: failure is always an option. Saying that you cannot fail means that you cannot consider possibilities that might lead to failure. But allowing yourself to consider things that might not work, you’ll give yourself a better view not only of the problem but also of the solution spectrum. And while you might not be able to properly decide on a course of action yourself, your insight can lead to the right answer.

Join the Conversation


  1. I’m not sure I agree with you Geoff. Failure to one person may just be one step of progression to another. A developer may feel they failed delivering something when QA returns their work with some bugs, but that work, although buggy, is still a step closer to the end result then when we started. I would have to agree with Yoda: “Do or do not, there is no Try”. But then, Yoda didn’t put time restraints on that, did he? ๐Ÿ˜‰

  2. Tom, c’mon… you’re comparing apples and oranges, here.
    Any developer who feels they’ve failed because QA returned a defect in their code clearly has issues understanding the scope of a problem. A defect suggests that the developer found a solution to the problem (whatever it happens to be) and put it out to be reviewed. That’s not failure — that’s success. The fact that they got something wrong is another problem altogether.
    Really embracing failure is when you see the problem, and aren’t sure what the solution is. You have no guarantees of success or performance, but based on what you believe to be correct and on what research you can find, push ahead (with everyone’s blessing) to find the solution.

  3. I like your post, it has a different perspective.
    The sooner you get to know the risks of your project the better… That way you can start looking for new solutions, new ideas and provide a better feedback to your client (and vice versa) about the actual status of the project and how you can work together trying to mitigate those risks. And if it fails well… at least you and your client were prepared. Worst thing you can do is lie to yourself and to your client…

  4. Oh, careful there, Ivan…
    Always remember that the rules don’t apply to clients. If they decide to call you on a risky move later on, it doesn’t matter if you’ve got a document they’ve signed in the presence of a lawyer written in the plainest language you can find. Clients will still call you on it. Client privilege. ๐Ÿ˜‰
    What you need to do is keep them informed and involved. That way, if nothing else, they won’t be surprised…

  5. Your right man… frequent feedback to the client is the best you could do in these cases…

Leave a comment

Your email address will not be published. Required fields are marked *