I’ve been seeing mixed answers to this question while talking and hearing from different teams going from teams where the mentors support the training and teaching of the students from behind with their knowledge and guidance while letting the team captain and subteam heads manage the projects and make decisions about the robot and work organization themselves as much as possible, meaning letting the team members design and build the robot more independently as they see fit and acting mostly as pillars to fall back on for safety, advice and questions when necessary, focusing less on how their robot turns out, putting the students’ learning from experience and facing challenges at priority. to teams where the mentors instead take it upon themselves to manage the work process behaviour and order for the subteams, and be responsible for validating the team members’ ideas about the robot design, construction, coding and strategies, being those in charge of settling on the decisions for the robot’s sake thanks to their knowledge and experience. and most of the time they may even step in to complete robot tasks themselves instead, like when team members lack the skill to produce good results or are just having a hard time, meaning overall they see the robot’s quality and success to be largly their responsibility also, and their form of help is more equal to the team members and subteam heads roles (or at least that’s how it sounds to me). Moreover it seems teams functioning this way put the robot’s completion more at value than having the team members take the better part of it.
So i’m curious to know what the opinions on this subject are, how do you think mentors should act in an frc team?
Should they be left more on the guiding and parenting of the team, stepping back while letting the students fully take charge on the robot themselves? Or should they show more involvement and support to the robot’s creation by stepping in to lend their expertise?
When team members aren’t functioning as well for the robot’s sake is it up to the mentors to put the building blocks for them? Or should the focus be more on patiently instructing the team members even if it means the robot ends up failing?
Should it be praised when mentors involve themselves in design and construction or is it actually not right?
Also, I would love to hear examples about your mentors, the role they have in the team and how it translates into the way your team manages projects during build season.
And of course to hear from the mentors on this site as well.
As it’s probably clear, i’m more in favor of the first option because it sounds more ideal to me that teams in frc would focus on the learning experience of the students more so than actually winning the competition, but i would love to hear more about different perspectives, personally in my team it’s kind of a mix between the two, since my team feels the students should be independent when working on the robot and have the opportunity to contribute to it on their own, but at times we find ourselves struggling with tasks and our mentors end up feeling the urge to step in and do the job for us because the quality and success of the robot is very important to the team and there’s always the stress of time.
This discussion has been rehashed a number of times on CD and I think the TL;DR is that there is no one size fits all solution since teams are all in very different situations. A good thing to think about and discuss, but I think if you’re looking for a consensus, you’ll probably just keep getting mixed signals.
Yes. This topic has been discussed many times on this forum. You should use the search feature and read through some of those threads since you will likely get the same types of answers.
One of the main learning opportunities for you is to figure out what is “right” for your team, at this time. None of us know enough about your team to give you a definitive answer. Even if you describe your team here, you will have left out details that would change the advice given to you.
In short, what is “right” for your team may not be right for my team. There may be more than one “right answer” for any team. What is right for my team now is probably not going to be the right thing in 5 years time.
The correct answer, to beat all other correct answers, is…
It Depends.
It depends on the team culture as a whole, it depends on where the students are in their development, it depends on the game, it depends on other factors. It also varies year-to-year for the same team; it varies team-to-team.
I think the only thing you never want to see is only mentors with their hands in the robot.
Mentor involvement might not only vary from team to team but from subsystem to subsystem. As a mentor I want to make sure the students deliver a robot on time and learn the broad engineering design principles and specific technical knowledge so they improve for next year and carry on strong skills into their next phase of life. Maybe that means designing something and walking back through the process after the fact, maybe that means working through motor calculations for their concept. Half the time it means sitting with the programmer as their rubber duck until they make the robot work.
You don’t want to see it consistently. Sometimes **** happens and the mentors happen to be the handiest because the students are getting fed or somesuch. But if it’s consistent across the event/year/seasons, then it’s time to start wondering. (Also doesn’t mean they’re doing anything wrong per se–it does mean that quite probably the students aren’t getting the full benefit of the program.)
And you never want to see only students with no mentors in sight. There’s other issues there, related to YPP and supervision and liability. As much as I’d like to see a fully-and-only student-built machine, no mentors at all is an issue.
Not only is there not a one-size-fits-all solution, the appropriate balance may change on a yearly basis, an hourly basis and even a minute-by-minute basis. I feel confident in saying this, as I’ve been in all four extremes (over- and under-helped student, and over-involved and overly-hands-off mentor).
On the mentor side, I bounce back and forth largely due to the:
I do, you watch
I do, you help
You do, I help
You do, I watch
process.
I also find doing things to be useful to learning because it allows more things to happen in parallel. If the team doesn’t understand the utility of a tube crush spacer, how to design one, or how to make one, it might take a while to get there. Early this season, after we crushed some MAXTube with through-bolts, I designed and 3D printed some crush spacers so the chassis could get assembled. Now, we have a bunch of different crush spacers and nut holders on the robot that were designed and printed by students. They didn’t get formal education in crush spacers; they simply had a chance to use, reverse-engineer, and synthesize. Frankly, if I had given a talk or a design exercise with crush spacers, I don’t think it would have been as helpful as just giving out parts and saying “try these” was.
Very much this. Without getting into specifics, we’ve learned this lesson multiple times over the last few years. A good portion of our mentors are alums, and we all try to give the students a better experience than we had when we were on the team. In some scenarios this worked great, in others, not so much.
Every year is different. Some students graduate, others join as freshman. Some people step up, others step back. As a mentor, all you can do is maneuver all of these constant changes to bring your team success, whatever success means to you.
Some years you have very assertive students who come in with new ideas every day, so mentors can take a more hands off approach. Other years, your team is too green and ideas are sparse, so mentors have to take a more hands on approach. Neither scenario is wrong. Sometimes you can have both going on at the same time.
I’ve had mentors who have been extremely focused on their ideas, not really taking students’ ideas into account. I’ve also had others that were the opposite. Luckily, I can say I’ve learned something from all of them, even if I disagree with their methods.
My senior year, one of our alum/mentors came up to me and asked “why are you doing that when you can teach someone else how to do it?” Personally, as I’ve stepped into a mentor role, I’ve taken this to heart. Sure, I can do things myself faster/more efficiently than the average student would. But that’s not what’s important. I’d much rather see a student learn how to do things, and help them gain the confidence to be able to do them on their own.
So need to spread this to every corner of the FRC world.
How they go about doing it depends on their team. Each team is unique in so many ways: Mentors [Skillset, Experiences, Availability], Resources [Work/Lab, $, Stock/Equipments/Tools] and Students [Maturity, Skills, Depth of Knowledge, etc].
Just because 1 approach work for 1 team doesn’t mean that approach would work for another. From students point of view, you might/might not have much of a choice depending on your area.
Even though this has been talked about a lot, I’ll at least comment what my experience has been. I won’t say too much about what I think the ideal is though.
I am a mentor for my team now and this year our team was about 10 students, six of which were first-years. we also only had one student who was a senior. Most of my time during practice was teaching the first-years everything I possibly could while also managing the other students. I am also not very experienced in teaching so I found this quite challenging. At the beginning of the season I tried my best to foster some brainstorming among the students, and we hashed out some decent ideas about robot design. In the end, I was in fact the person who decided which design we went for. I honestly wish that I could step back further from the decision process, and I could if I really wished. However, I wanted them to be able to accomplish something and learn from it, and felt if we attempted the other designs, we would not complete them. So, my main focus this year is to try to teach them as much as possible so that they can design and execute the robot themselves much better next year. And I believe that requires that they have strong guidance in certain areas. I also believe that nothing inspires kids more than seeing that they can accomplish something, and they truly have. Even if they required a lot of guidance.
I mentor two relatively small teams (~10-30 students). This is something I do and never put it into words (at least not as eloquently), and I want to add that it’s especially good if you can employ it on an individual level. One of my students was very green to the FRC/Robotics world at the beginning of the season. At first, I showed him exactly what to do to repair the robot and what signs of damage look like. Eventually, when stuff started to break I fixed it with him helping me or very closely observing. This student actually skipped the penultimate step in the process because he is an information sponge and watching him work independently I knew he could get it done without me.
He went from 0 to the point where I trusted him to get a working robot on the field every match. This is where I disagree with the full-hands-off-mentor mentality because growth like that can’t happen without kindling to get it started. Full-hands-on mentality is fundamentally flawed too because you take away that sweet-spot of independent-immersion where the real learning happens.
Students can’t be left alone to fail from the start but they can’t be micromanaged and stunt their growth. You have to iterate on them and build up mutual trust so they get to the point of independence.
On my teams, our goal is to get the students to the point where they can do strategy, continuously improve, and have a complete understanding of the workings of the robot, etc, without mentors by (at least) district champs. We joke and say this is because the mentors want to watch cool robots in the stands all weekend, but really it’s because that is the kind of situation where they come into their own and do the independent learning the program is all about.
