The right to fail and the unacceptable alternative

Posted By on Sep 26, 2012

Every now and then I’m confronted with a manager who is profoundly against the idea of a team’s or individual’s right to fail. A few years ago, I’d be taken aback by such a stance and react in a very nonconstructive way. Today, with a some experience, desensitizing, professional distance and a lot of coaching, I simply ask the question : What’s the alternative?

If management’s overall message is “failing is not an option” or «no mistakes will be tolerated», two things will happen:

1- The team will not fail
  • Reality will be adjusted to expose success
  • The team will successfully follow The Process
  • The team do exactly what we tell them to do
  • Conservatism will reign and rule
2- The team will fail anyways
  • Reality always happens. Even if you order it not to
  • The Process will succeed but the solution will fail
  • …because the team did exactly what we told them to do
  • Complex problems requiring creative thinking will be conservatively patched


So I ask again…What’s the alternative?




  1. In my humble point of view, the alternative is to look at it as risk management. This way, you’re not talking about failure anymore. You can even prepare nice charts to backup your risk assessment strategy and your countermeasures.

    It’s up to the team to optimize their efficiency, but it’s the manager’s job to mitigate and insure against risk.

  2. I would have to disagree with Christian, Risk management and pretty charts is only a way to mask reality. You won’t build a performing team with people that can’t confront each others, you will only end up with pretty charts and a project that fail. When someone is always cutting corners, you won’t fix anything with pretty charts!

  3. If you set up the question that way, that’s all you get.
    But if you manage projects like Lister suggests – like adults – you’ll have some form of risk management and risk retirement, and search for risk and the work activities to reveal those risks.
    But when manage acts in the way you describe they get what they deserve.
    Only when IT shops start behaving in «adult» ways, with mandatory risk management processes at some level, will this type of discussion come to an end and the real problem of SWDev project start to be addressed.
    I know there are many places that haven’t moved past the «child-like» management style, but that just confirms the management of project – in any form – is harder than it looks.

    Read Lister’s presentation and then reconsider your question in light of the maturity of the management statement

  4. Hi Glen,

    Thanks for your comment and link.

    I, in no way disagree with the usage of proper risk management and action items to address the ‘High Probability’ and ‘High Impact’ risks and current impediments.

    This post focuses more on the mindset and culture of an organization, supported by VPs, managers, project managers, developers, etc.

    A “failing is not an option” or “no mistakes will be tolerated” culture and mindset will generate even more risk. And worse still, they won’t appear on a Risk Management chart or matrix. When does «Following the rules» or «implementing ALL the requirements, whether they are valuable or not» appear in a risk management document?

    For example, if a Scrum team (including the PO), does not take risks, experience quick and small failures, learn from those failures and then try again, the worst risk of all will manifest itself : The wrong product will be built and for the wrong price.

    Examples of risk taking that has resulted in failure or success :

    Team decides to refactor a huge chunk of code
    Team decides to create a risky test harness around legacy code
    P.O. makes the call to not implement or to implement a story in a “leaner” way

    All these could have ended in failure. If failure was the result, they dusted themselves off, got support from stakeholders, learned from it, managed the risks and adjusted action/mitigation plan…In a perfect world.

    If failure is NOT an option, that refactoring will not be attempted. Those tests will not be added and technical debt will continue to grow. If no mistakes are tolerated, the P.O. will not make that call. He’ll take the safe route and keep the story at 8 points instead of risking “minimal viable” at 2 points. Why risk it? Might as well fail following the process. Then at least the PO can blame the system engineers, the process or the manager and they can take the hit.

    I feel failure should always be a right. But learning from failure should always be a commitment.

Submit a Comment