Value in Failure vs. Value in Success

[Kevin Leonard]

Originally Posted by chrisfl

I'm going into my junior year of high school and we just had to read a book sorta like this, "The Triple Package". The book discusses why different ethnic and religious groups in America succeed or fail. Throughout the book the author discusses how the three parts to being successful are
1. Superiority complex
2. Insecurity
3. Impulse Control
The first 2 seem conflicting however they play off of each other.
For example, your team wins your division at champs but gets knocked out on Einstein. This scenario creates the perfect balance you need for learning. In this scenario, your team creates a superiority complex by knowing they are the best in their division however still are insecure after losing on Einstein. These 2 parts foster innovation in the future. If you were to flawlessly win in both your division and on Einstein you wouldn't have that chip on your shoulder to do better next year, you would become relaxed. Meanwhile, the team that got knocked out on Einstein will innovate to try and ensure that doesn't happen again.

1678 is a team that fits this situation. Every year they come out with a great robot and make it onto Einstein and just barely miss the win. Then after years of innovation they manage to win and be on top.

This makes me scared to see 2826 next year.

[Monochron]

Just as an example of what we have tried, we often do small projects in the off-season that are completely open to student failure, and then offer more guidance and try to deflect failure more during the season or in "large scale" off-season projects.

For instance, last year we did a t-shirt cannon competition where we built 3 teams and had them compete to build the strongest / fastest cannon. The teams were entirely student led with mentors only helping when specifically asked. Rather than mentors constantly offering guidance or trying to foster ideas, we made our involvement entirely up to the students. As a result very few groups came to us for help and only one group was ultimately able to build a cannon that shot more than 10 feet.
Afterwards we had a debrief on what went right with that one team and what went wrong with the others. It was mostly due to one or two students putting in a lot of work researching build techniques and making their mistakes early in the process.

We don't think that the massive 2+ month FRC season is a useful place to let the students fail if we can prevent it. But a short small scale project lets them fail in a more low-key environment and a good post-analysis helps them uncover what caused that failure and how they could prevent it.

[Deke]

As a mentor/coach/teacher I think it is incorrect to choose or let someone fail. Instead we should do our best to give them the correct tools or suggestions to succeed. Teams can then move to bigger and better problems as a whole group.

I like Corsetto's fail faster approach, and to answer the op's question: Failures come often enough that we don't need to create them or let them continue when discovered.

The question I ask is: what are you going to do when you fail? I fail all the time and you are going to fail; there is no doubt about it, no one is perfect. Are you going to try another method, fix the problem, find a solution, or let it take you down?

[FrankJ]

Originally Posted by Infinity2718

As a mentor/coach/teacher I think it is incorrect to choose or let someone fail. ...

You don't want people to fail. You don't won't airplanes to fail. You do want to teach how to take appropriate risks. Taking risks will lead to occasional failures. Successful people learn to accept failure and continue on. Successful people learn from their failures. Sometimes the only thing they learn is that what they was trying was a really bad idea. Prototypes that don't work aren't necessarily failures.

[Siri]

Originally Posted by FrankJ

You don't want people to fail. You don't won't airplanes to fail. You do want to teach how to take appropriate risks. Taking risks will lead to occasional failures. Successful people learn to accept failure and continue on. Successful people learn from their failures. Sometimes the only thing they learn is that what they was trying was a really bad idea. Prototypes that don't work aren't necessarily failures.

The question here is whether it's good for students in a FIRST environment to have an entire season as a "prototype failure". I would be floored if you found an FRC mentor arugeing students that should be barred from iterative development. Rather, "failure" in this context means the opposite of iteration.

Look at the OP example: The "value in success" example is 71. They succeeded because they failed and iterated upon it. The "value in failure" question comes only when when students are [at risk of] carrying a single failure for an entire season (or longer), e.g. poor strategy resulting in limited opportunities to fail/learn/be inspired in follow-on experiences. We want our students to be successful people and learn from failures, but how do they become successful enough to recognize and handle failure properly? Do they make every mistake to its fullest, or to what extent should mentors facilitate learning from others' previous mistakes (share their experience and knowledge).

[Deke]

Originally Posted by FrankJ

You don't want people to fail. You don't won't airplanes to fail. You do want to teach how to take appropriate risks. Taking risks will lead to occasional failures. Successful people learn to accept failure and continue on. Successful people learn from their failures. Sometimes the only thing they learn is that what they was trying was a really bad idea. Prototypes that don't work aren't necessarily failures.

I would reword this a little bit, its more of a process. Instead of taking appropriate risks, engineering is about identifying risks and mitigating them. Once the criteria are defined, such as a strategy in FRC, ideas are created for solving them. Those ideas should have their risks identified and them gone through the engineering process to eliminate or reduce. If they can't be eliminated analytically, they need to be tested conservatively and eliminated that way. So from a technical standpoint, its not about taking risks, but more about identifying them (which is the hardest part) and reducing them. Without the initial engineering, many prototypes are setup for failure and go through the shotgun approach with hope of finding a solution. With time in FRC and available people, sometimes the analysis gets short changed, but people can be amazed at how much time can be saved with some basic physics calculations. I don't think any ideas are bad, but they must be sorted through to get to the best solution.

Maybe this is from my aerospace background, but we don't take risks, and if anything is in question, we conservatively test it to ensure reliability. Now that doesn't mean there aren't failures during development, but that is what development and prototyping is for, reducing risk.

Originally Posted by Jared Russell

Given how integral finding success is to understanding complex problem domains (and therefore inspiration), I never intentionally "let students fail" in FRC. There will inevitably be enough unintentional failure in any endeavor we take on that adding intentional failure on top of that seems unnecessary.

This is what I was trying to imply in my first post, Jared has explained it more elegantly.

To me the OP's question is the following: Which methodology is better from a mentor perspective? Learning by teaching through success, or learning from teaching through failure? Is there a balance?

My answer still is to teach through success. Learning through failure may be effective, but it is long and time consuming compared to learning through success. Example: basketball coach gives a new kid a basketball and tells him to throw it at the hoop until it goes in. Versus basketball coach pulls the new kid aside for 10 minutes and explains how to use his legs and square up his elbow and finished with a good follow through. Which kids is going to learn faster? I just think the latter process gets everyone farther faster.

[marshall]

I think I'm torn on this subject a little.

Based on the above comments, I have a question about allowing a student to fail. Is there any value in teaching humility through failure? I do my best to find a way to reach all of my students. Sometimes that is easy and sometimes it is more difficult.

A couple of years ago I had one particular student that I could not reach. He was very determined to do things his way after having come from another FRC team that was run very differently than ours and having participated in FRC from a very young age. He was determined to turn our team into his team and have everything his way... In the end, I let him take parts of the process into his own hands and it did not lead to success that year for us. It taught him a lesson that I don't think he would have learned had I put my foot down and said 'no' to him along the way.

To be clear, I'm not sure it was valuable for the entire team. I think it did more harm to the team than good to that one student. It has helped to make me a better mentor for seeing that though. Remember students, your mentors aren't perfect, we are human too.

[Jared Russell]

Originally Posted by IKE

I have worked with a few "over-confident" students and let them intentionally fail (in a safe manner, and in time that corrections could be made) in order to do a bit of an ego check.

Originally Posted by marshall

...

Teaching the line between success and failure is impossible if someone cannot perceive the difference between the two. Teaching them the hard way that their perceptions of success do not match reality can be a necessary first step, though I think in general there are multiple ways of doing so.

[The other Gabe]

REALLY LONG POST ALERT

Both have value.

Failure can be a powerful tool in areas that are less consequential to how well the team will do at competition- offseason projects, learning skills (like CAD, or how to scout a match correctly), that sort of thing. a failed season teaches a team something different- it (hopefully) catalyses change, allowing the team to fix whatever the failure was (over-extension, not listening to each other, not enough driving practice), fixing it for the next year.

Success is a good tool on the large scale- building a working robot that does what you wanted it to, winning a regional, being ranked higher than the previous year. A successful season has the danger of making a team complacent to keep running the team how it has been run, ignoring the skill of the students (either letting mentors control too much in an area which has a strong set of students- ex. being having the mentors decide most of the strategy, while leaving it up to the kids to design the robot, when the students are, as a whole more strategic minded and have trouble coming up with design ideas- or vice-versa, keeping a hands-off approach when the students need guidance). However, a team can also build off of success by realizing that they still failed during the year. Identifying those failures can help them become even more successful.

now, figuring out how involved the mentors should be to ensure competitive success while allowing for smaller, educational failures is a much harder question, because there are definitely multiple right answers, and many of them are dependent on a specific team in that specific year.

2046 has had some very successful years as well as some years that were not so good, even if we won things. In the 4 years that I was on that team, I experienced both, and feel that the successful years differed from the unsuccessful years on two points. the first was creating a successful design for the game challenge (duh). the other was being able to learn from our earlier events (first regional, every district event) and from build season, allowing us to build on our successes and identify where we failed. mentor involvement has been an issue for the team (we re-though how involved mentors should be after our flop of a season in 2013), but we were successful when we had a lot of mentor involvement, and when we had very little. I have 2 examples of such years, which were probably our two most successful, and definitely had our two best looking robots.

In 2012, my team had an extremely intelligent group, many of them more experienced seniors. however, they still worked heavily with mentors in order to complete an ambitions robot design, one that was ranked extremely high in the world (I think our OPR was in the top 80 of the world, but that was 4 years ago and I was a Freshman, so I could be blatantly wrong), and was a generally pretty OP robot. That's not to say that there weren't failures that year; the robot went into the bag not nearly complete, partially because of how long it took to make everything, but also because people messed up sometimes, and had to learn from those mistakes. that means that our first event exposed some more flaws in our design, making us realize we needed an improved intake and a hooded shooter. all of these were smaller failures, though, and learning from them lead us to even greater successes in later events, including our second regional win. Our main failure was our electronics and pneumatics, which were generally a mess. At CMP, our pneumatics developed multiple tiny leaks in the Quarterfinals; the drive team could not find them, and we ran our second match without the ability to put down our multi-tool (& we were therefore unable to use our turret).

In 2015, there was really not that much mentor involvement, yet we powder coated for the first time- a student set up the connection with a powder coating group, got their sponsorship, and then created a place in our shop to powder coat (it kinda looks like a meth lab if you're just walking by ). our robot design was though up of largely by students- most prototyping groups were student-lead, and it was designed, fabricated and programmed pretty much entirely by students. it worked pretty well at our first event (well, after we slowed the lift down), getting us to finals. It still had some major flaws; we were never able to fix all of them due to weight and availability of workers, but we added a top claw, canburglar, and improved our intake over the course of the season. despite not being picked at DCMP, we were at CMP, and ended up being finalists as a 22nd pick robot (we filled the perfect niche- our allies were both feeder station, and couldn't upright containers. we were a landfill robot that could). Our main failures were attempting versatility (being able to do landfill & feeder) in a game that rewarded consistency, and not using a can claw on a coaster.

Both of these years taught valuable lessons (well 2015 did to me personally, I can't say for the team yet). our success showed us ways to continue to be competitive, and our failure created improvements that were implementable over the long term.

Once you get into things mentors do for a team other than teach us skills, such as leadership, creating strategy, etc, it gets murkier; how do you let a student learn from failure as a leader, when that failure could cost your team any chance at success later in the year? I really dont think there's a right answer to this question, because in this area, both the mentors and the students are learning, and should therefore work collaboratively. IMO, there is one thing that every mentor should want: the students to be able to work without their assistance (if FRC is training most of us to be future engineers, we'll eventually need to work independently anyway): it is a mentor's job to teach us how to mill, how to use CAD, how to lead; if we've learned that, then they can take a step back, and maybe even be able to see their families during build season


TL;DR: I have personally experienced this:

Originally Posted by Ginger Power

Long story short, value that comes from failure takes more time and often leads to fewer new discoveries and experiences (less build time and prototyping time in the above example). Value from success often allows for more and greater success and failure opportunities since it can be done in a quick way.

is more powerful than this:

Originally Posted by Ginger Power

Long story short, value that comes from success is generally easy to come by when it's handed to you, but the value that comes from failure has a more permanent and lasting effect.

although both give valuable lessons.


That took me over an hour of writing and re-writing... ya'll're making me think

Originally Posted by cbale2000

but if you don't choose to pursue a STEM field in the first place, what is the point of learning the skills at all?

I'm not going into STEM. the skills I learned here are still important (I wont go into detail here, it's not the thread's theme and my post is already way too long)

[Kevin Leonard]

Originally Posted by Infinity2718

I would reword this a little bit, its more of a process. Instead of taking appropriate risks, engineering is about identifying risks and mitigating them. Once the criteria are defined, such as a strategy in FRC, ideas are created for solving them. Those ideas should have their risks identified and them gone through the engineering process to eliminate or reduce. If they can't be eliminated analytically, they need to be tested conservatively and eliminated that way. So from a technical standpoint, its not about taking risks, but more about identifying them (which is the hardest part) and reducing them. Without the initial engineering, many prototypes are setup for failure and go through the shotgun approach with hope of finding a solution. With time in FRC and available people, sometimes the analysis gets short changed, but people can be amazed at how much time can be saved with some basic physics calculations. I don't think any ideas are bad, but they must be sorted through to get to the best solution.

Emphasis mine. These two stood out to me. If I have a student that has some crazy, insane idea or otherwise has objections- I don't want to let that derail the team and our process, but I also don't want to tell them "no that's a dumb idea", because that doesn't help anyone either. I want to run through the analysis with them- let them prove to themselves what the "right" answer is, and point to objective metrics of why thing A is being done.

Originally Posted by marshall

A couple of years ago I had one particular student that I could not reach. He was very determined to do things his way after having come from another FRC team that was run very differently than ours and having participated in FRC from a very young age. He was determined to turn our team into his team and have everything his way... In the end, I let him take parts of the process into his own hands and it did not lead to success that year for us. It taught him a lesson that I don't think he would have learned had I put my foot down and said 'no' to him along the way.

To be clear, I'm not sure it was valuable for the entire team. I think it did more harm to the team than good to that one student. It has helped to make me a better mentor for seeing that though. Remember students, your mentors aren't perfect, we are human too.

I think lessons in humility can be taught in ways that impact the overall team less. Smaller exercises in failure rather than large ones. A failed prototype followed by an engineering analysis of that failure might do it, or an detailed analysis of the idea in question compared to other ones. I would hesitate as much as possible from letting other students down to teach one student, but that's a difficult call to make, especially with different personalities involved.

Originally Posted by Clem1640

Failure can be a great and valuable learning experience, but this requires a few crucial mindsets and capabilities:

1) Introspection. You must firmly believe that your failure was due to factors (at least in significant part) under your control. Therefore, by doing something different, you might succeed. If you assign your failures to outside agents, then you really cannot productively learn from them.
2) Critical Analysis. Understanding the factors behind your failures, your shortfalls, your strengths, weaknesses, opportunities and threats. Understand how you might succeed and what changes you might make to your habits / processes to improve your prospects to succeed.
3) The will (and the physical/financial/temporal capability) to change what you do and the way you do it (your processes) in order to succeed.
4) The ability to inspire your team to make the necessary process changes that are needed for success.

This +1000