Learning from Failure

From DevSummit
Revision as of 17:21, 5 May 2015 by Vivian (talk | contribs) (1 revision imported)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Go around: what do we want to discuss:

  • How to fail?
  • Failing better?
  • Hear others' experiences with failure
  • Creative potential of failure
  • How to capture the "aha" moments of failure and actually learn from it
  • Discerning adjusting vs abandoning; resilience
  • Figure out how to learn lessons from failure
  • Revisiting failure with recurring campaigns without fears
  • Speaking truth to power about foreseen failures.
  • Understand why social movements fail or become co-opted
  • How to make sure you're actually learning from the failures
  • How do we deal with entrenched failure--acknowledging it, explaining why you're continuing it, figuring out what next
  • Anticipating failure in a public campaigns
  • Deliberate failures as "bait" or motivation
  • How to effectively & quickly bounce back from failure
  • Spinning failure for funders or other folks

Story/experience sharing:

  • Foreseeing failure: getting instructions from someone with more authority, knowing failure is coming, still having to do this--what do you do?
  • You bring your own experience to the situation; when you figure out that your objection is about serving your mission or goals rather than ego, you try to intervene. Say what you have to say, but sometimes you still have to let go, let the failure happen, be there to pick up the pieces as best you can.
  • Have had many situations where I should have foreseen something and didn't; overarching conversation could be about what you can draw out of a failure that's good, that will make your work better. Enter into known failure with the bright spot of being able to learn something from the situation.
  • It's important to define success in order to understand what constitutes failure.
  • Determine points at which you know you're heading towards failure and know what to do at those points.
  • If you're stuck solo in foreseeing failure, how do you figure out how not to be all by yourself?
  • Trust is needed for effective work; trust someone to roll with something, possibly fail, get together to get something positive out of it.
  • Adjustment or abandonment: deciding as an organization or team where the adjustment points and abandonment points happen.
  • Have a unique job where failure is actually in the job description: try to create a new way of campaigning, do it over and over with the knowledge that it would probably fail. Required acknowledgement of current situation, lack of cross-organizational collaboration and support. Was encouraged to experiment, advance lots of things, fail a bunch, go back and write about/analyze it, sharing.
  • Define language about failure; be able to have a shared understanding of what failure means.
  • Debrief at intervals and/or at the end of the project; collect data during the project, document what you find, create a process to incorporate what you've learned into later projects.
  • Look at your priorities going into a project; recognize if priorities are just unavoidably conflicting, make sure they're dealt with in order. Coalitions add extra complexity because of competing priorities.
  • Science has language for failure. Test a hypothesis--the experiment can be a success even if the hypothesis is a failure.
  • Agile workflow features retrospectives--address what we've been doing and should keep doing, what we should try that's new--less in a frame of what we should STOP doing to make it easier to talk about it within the group without hard feelings.
  • Failure is a success because you recognize what didn't work and don't try it again.
  • The organization or team needs to tolerate the approach of "project as an experiment." How do individuals' proclivities and fears impact the ability to understand and learn from failure.
  • Framing failure as a success is a cultural phenomenon, specific to certain cultural spaces; also, sometimes things really do suck and need to be called out.
  • You should always have multiple measures of success/failure.
  • You don't always agree on the measures of success/failure. Sometimes the priorities are so incompatible that they can't all be held.
  • Organizations can be afraid of publicly acknowledging a campaign failure; sometimes organizations just try to cover up the failure rather than being transparent and utilizing failure to move work forward, motivate constituents, create a sense of urgency around actions being encouraged.
  • Failure is often used strategically as part of campaigning.

Addressing fears around failure, as individuals or part of teams

  • Collaborations can break down--two directions tear the project apart. You can become incredibly cynical when that happens. Is it better to just go it alone?
  • Solo failure is harder; you take it all on yourself, you become a prosecuting attorney against yourself, blame yourself. In a group that can take individual pressure off of people.
  • Being the ball-dropper with other people can be worse than just letting yourself down. Can turn into a negative spiral.
  • Success is harder on your own; if you've built something successfully without any collaboration, you can be doing a disservice to the folks for whom you're building the tool.
  • Techie/developer mindset: it's your job to fix it, you should just be able to fix it. "Developer shame"--helpful to name it, learn to recognize it.
  • Forgive yourself when you do something wrong; active forgiveness.
  • QA (quality assurance) processes can be leveraged as a way to make failure acceptable. If you fail without a QA process it's personal; if you fail and catch it within a QA process, that's part of the process.
  • In many situations people look at an individual as a point of failure, rather than looking at the process, team dynamic, etc.
  • Assess risk factors ahead of time.
  • Assessing risk can help you make it safe to fail, e.g. padding estimates, being able to afford to eat hours on a project, etc. But what about situations where it feels like you just can't afford failure?
  • "Test suite penance": when things fail, the developers "do penance" by improving the test suite so that it catches those failures in the future; after doing that, you're "absolved"
  • Create new pathways for dealing with failure; let's you wind up with a different result than old habits around failure. Need to practice the intentionality.
  • Learn through failure, process it; you need to be intentional about acknowledging it, documenting it, and learning from it.
  • Different cultural perspectives/learning cross-nationally

KEY TAKEAWAYS TO REPORT BACK ON:

  • Helpful to come up with agreed on indicators of failure, so as a group you can understand when failure is approaching and what to do with it.
  • Scientific method: test a hypothesis, even if it fails the experiment is not a failure.
  • Create a safe environment in which to fail or discuss failure
  • Build failure into your process and take the focus away from the individual
  • Knowing when to stop in the process.
  • Ways to react to failures via "penance" that then "absolve" you
  • Build gateways to collect thoughts and move on.