Mentors on the team

[mathking]

I though long and hard about posting on another of these threads. Every team is different, and even one team changes from year to year. I think that one of the worst reactions to have when looking at how another team operates is to believe that you are better than they are because you do things differently. I strongly believe that the most important bond that gets formed in FRC is the bond between mentors and students. I understand and agree with Dean's position about FIRST not being an educational institution. But as a teacher I also think I would not be doing my job if I allowed FRC not to be an educational experience for the students. A big part of that educational experience is collaboration between students and mentors. Collaboration means that we discuss, and listen to everyone's input, and discuss, sometimes argue, and discuss (by now you should be seeing why we sometimes have trouble getting the robot done by ship/stop build date) some more. When problems arise we go back and forth for solutions.

This year's ball gathering device started with a basic design I advanced. Then a student (and a new one at that) suggested a simple change which made the design much better. We worked on it some more and a mentor and student pointed out a couple simple flaws, which testing of the prototype confirmed. And they suggested a fix. Which worked. Then a parent and another student suggested another change. Which distinctly improved the robot. Then we found an annoying but not fatal problem, for a which a mentor found an excellent, easy to implement solution. Finally the student who made the first revision suggested a final solution that actually made the whole thing work better using one less motor. And now we have a very nice gathering device which is simple, easy to remove and inexpensive. That wouldn't have happened if we had proscribed roles for mentors and students.

On our team we have had a strong tradition of the mentors teaching the kids how to do things. Mentors do a lot, and not just high level management. We cut things and drill things. But we try to show the kids how to do it, so they will learn. As a general goal, by the end of the season we want to be in a position where the kids can diagnose and fix any problems that occur with the robot. We also have a strong tradition of the mentors working really closely with the students. Occasionally we argue. We try to always be respectful with it. Arguments are not bad if everyone is being respectful and listening to the other side. More often than not, each party to the argument has a valid point to make. Sometimes that is a point the other people haven't yet considered. More than once I have let kids pursue an idea I *knew* would not work, because I felt they needed to see it not work in order to understand why it wouldn't work. Partly this is because I am a teacher and I think it is the right thing to do. Partly is because a few of those times I *knew* something wouldn't work I was wrong, because I didn't understand the situation well enough.

Our team does NOT have a magic formula. We have something that works pretty well for us. Find something that works for you.

That said, I would plead with all of the teachers out there running teams not to let the mentors design and build everything. You are missing the chance for your kids to learn a lot. (And frankly, you are fooling yourself if you think that kids who watch someone else build a robot are just as inspired as kids who participate in the building.) Teachers, I would also implore you not to have the students do everything. You are missing the chance for your kids to learn a lot. (And frankly, you are fooling yourself if you think that kids who work on their own building a robot are going to be as inspired as kids who work side by side with adults they look up to.)

[GW Kalrod]

Originally Posted by Koko Ed

This comes up every year (and it will come up again and again) and to be honest it doesn't matter what we say, People will see what they want to see and if they believe that teams that have mentors who build their robots (or even assist in any way shape or form) are the root of evil.
Perhaps the only way to deal with it is to let them stew in their own juices and take them off your pick list. Sometimes the best lessons come with a swift kick to the rear.

Yeah man, you've got FIRST nailed.

[johnmaguire2013]

There is a local team (not my team) which, by the students choice, is 99% student-run. Most of the students actively try to prevent mentors from working with them, as they prefer a product which was built completely by themselves. They are always on time, and have a decent robot by the end of build season. It works.

Our team has a lot of students (maybe too many,) and a fair amount of mentors. For the marketing teams (PR/Media, Website, etc.) the team mentors usually assume a leadership role, making sure that things are taken care of, and if no students can solve an issue, they will come in to help. Additionally, with the website team, our mentor manages the hosting (we're on a type of AWS,) and domain, although even this could be done by our students. Some of the teams hardly get any leadership input (like the website team, which has mostly been a product of a couple students creating and coding a design, and a handful more adding content,) while others rely on it quite strongly (the PR/Media team, which has a couple mentors organizing things, and also handling purchases, etc.)

When it comes to our build teams (mechanical, electrical, effector, etc.) our mentors have a larger role teaching students to use equipment, monitoring safety, and overseeing things. Additionally, they will help out with the actual cutting, use of machinery, etc. both to save time, and to provide examples of the correct ways to do things. Again, they also handle purchases of wood, and other materials.

This works for us. It's not a sure-fire strategy, and every team is different. We also have a student leader, who manages a lot of the sub-teams, and he is pretty much able to do his own thing, regardless of our team coach (a mentor.) I think, as many others have said, it's up for the team to decide the type of involvement.

[jason701802]

Originally Posted by Koko Ed

This comes up every year (and it will come up again and again) and to be honest it doesn't matter what we say, People will see what they want to see and if they believe that teams that have mentors who build their robots (or even assist in any way shape or form) are the root of evil.
Perhaps the only way to deal with it is to let them stew in their own juices and take them off your pick list. Sometimes the best lessons come with a swift kick to the rear.

And what does that teach anyone? The teams that have the best performing robots are not necessarily the ones that do the most inspiration. Some of the most inspired (not excited) kids I have talked to are the ones that are on predominately student teams.

Originally Posted by Billfred

With that out of the way, let me ask some questions:

1) If a team can't press a pinion gear onto a motor properly, but a mentor can take it to work and get the operation done quickly and effectively, should the mentor "sit on the sidelines"?
2) If a team has four hacksaws, 40 feet of pipe that needs cutting, and three available students, should that fourth hacksaw just sit on the shelf?
3) If a mentor's demonstration can save the team valuable time and resources, should a student tear it down and start it fresh?

I submit the answer is no to all of these. Balance is the answer.

I agree that the answer to all of these is no. I think it is only okay for a mentor to work on the robot if every student is busy and every interested student knows how to do the task in question. By definition, a mentor is a counselor or teacher, not a doer. A mentor should never do something that could be done by a student, and if they do, they aren't really a mentor. The moment that a mentor takes an active role in the design, they have crossed a line. They can pass on a lot of knowledge, give guidelines for design, show and explain examples of good and bad designs, and offer critiques, but, again, if they take control, they are no longer a teacher or a counselor, and thus not a mentor.


Random side-note for some extra thought: many of the greatest innovation throughout history have come from people who have ignored standard practices and traditional thinking.

[mrnoble]

I have coached the same team since 2003. Some years, I reacted against seeing teams with limited student buy-in and erred toward the student-led model. Some years, I reacted against poor organization and outcome and erred toward mentor-led. I've been part of teams where student leaders did stupid things that cost team unity, safety, and a competitive robot. I've been part of teams where over-controlling adults did the same things. We currently have a mission statement that makes it clear what our expectations and goals are for both students and adults, and which usually helps cut off problems before they happen.

Currently I think that if, for example, I can provide the students with something valuable to do for the team by giving them a CAD/CAM part to work with, I'll do it as long as it fits their vision and as long as at least one student is involved in the process enough to learn how it works, in hopes that they will be the ones who do the same thing next year.

It really is a difficult balancing act to reign in my own ideas and passions without allowing students to set themselves up for a poor season through lack of experience and foresight. I've certainly learned not to judge other teams as harshly as I did eight years ago. I hope I'm a better coach and mentor than I used to be, and that all the students I teach come away from the season feeling successful and proud of their work. I hope that students who were already passionate about an engineering future aren't discouraged, and that students who never considered such an idea before their FIRST experience are coming away inspired. If I'm helping to facilitate these things, then maybe I'm fulfilling my role as an adult on the team.

[SousVide]

no disrespect intented.

But That can't be still correct today, could it?..... Look at what he did right after that...

FLL was started....

FLL, where one of the most fundamental Core Values is for students to do *all* of the work. Not some, not whatever you can do and I will help you with the rest - *all* of it. They are also judged upon it and judged lower during the competition if they do not or cannot represent their own work.

FLL is part of FIRST...

our own FRC mentoring guideline documents - the most recent one this year continues to show the values of having the student do the work - as much work as they are capable - with mentors standing by and encouraging...

Yeah sure, if a student doesn't understand how to use a powersaw - don't just randomly arm them with one. At the end of the day, what is quoted might be what is meant then, but I cannot understand how it could be true today. It defeats the purpose of having the students *do*...

Hanging out is terrific - maybe it will even keep them out of trouble. Doing what is described in the quote is like inviting a bunch of people to a buffet and *not letting them eat*... that's just not right.

Originally Posted by Basel A

The following passage has been quoted time and time again in threads such as this, but for those that haven't read it, I think it is necessary posting.



Emphasis mine. Because the goal of FIRST is to spread awareness of STEM and to inspire more students to pursue STEM education, the amount of mentor involvement on a team does not matter as long as those goals are being met.

[Hawiian Cadder]

First is not about the robots, it is about learning what is possible with robotics, and gaining a good working knowledge of engineering concepts that High school does not offer. This is not achieved as much as it could be without any mentor driven Ideas, High school students typically do not have the mental training to entirely develop competitive ideas without outside help. This means that most competitive robots are either drawing heavily on mentor and lead student experience, or they are drawing heavily on high performance teams posting their methods with the understanding that It will help others. I don't think there will be a single robot that performs well were more than 75% of all of the thought process required were driven by that years student build team.

[SteveGPage]

Originally Posted by SousVide

no disrespect intented.

But That can't be still correct today, could it?..... Look at what he did right after that...

... At the end of the day, what is quoted might be what is meant then, but I cannot understand how it could be true today. It defeats the purpose of having the students *do*...

I totally disagree. Dean certainly doesn't need me to defend his words, so I will just say I've heard him say similar things in the last couple of years, so I think he still believes what he said in 1998.

From my perspective, regarding the role of mentors on a team - this just isn't for "kids" this is for "future STEM professionals. This is the best STEM curriculum in the world, wrapped up in the form of entertainment and competition. If they are not learning and not being inspired, then it certainly doesn't meet the goals of FIRST. How that is done, however, is dependent on the "market" where this is practiced. There can be instances where telling students to do it all themselves could be totally uninspiring, leading to total frustration, and causing them to quit. Likewise, having them sit on the sidelines, and not get a chance to be involved can also sour them on the whole experience. What works for one team, in their community, may not work for another.

In my workplace, I manage a team of education professionals. They have all gone to college, some with advanced degrees, some with experience at other organizations - but when they join our company, they are assigned a Mentor for their first two years. At the beginning, they get to only observe the training events that our company provides, then a chance to teach more and more, finally they are allowed to "go solo." Some need all 2 years to get up to speed, others, perhaps half that. The mentors are there to make sure they have the skills they need to be successful in our organization. The mentors in our company want the new employees to be successful as quickly as possible, so they can contribute to our overall success.

The same is true on our FRC team. We mentor them, so that hopefully they have the skills to be successful STEM professionals. Our FRC team is probably a 60/40 split between students and mentors. If a mentor is doing something, it with as much assistance as a student can give. If the student can do the job, the mentor is there to observe and advise. On our FTC teams, it is probably a 90/10 student to mentor split and FLL is then 100/0 split. But each level has its own goals and its own focus. FLL is not FRC for really short people, and FRC is not giant legos. The different levels of FIRST meet the kids where they are, with what they can do, and at what level of development they are in. They should be viewed as a part of progressive journey, where the goal is to grow the best STEM professionals we can.

On our team, the robot and the competition is a bonus - the learning is the key. How that works, is up to each team to decide, and that may change from year to year.

[Basel A]

I can't speak about FLL, having never worked with an FLL team nor judged at a competition. It's easy to simply say, "The focus in FLL is different," but I simply don't know. But here's what I do know: In my entire life, inside FRC and outside, I've always been more inspired by knowledgeable people who can explain "why" than by my own trial-and-error that leads only to a "what."

SousVide, you seem to imply that one can't be inspired by a robot they did not design, build, or program. But let me say this: as a whole, I've been more inspired by FRC robots I never touched than the robots I've spent dozens of hours designing. It's not the same situation, but I don't think that's too different from a team in which mentors do all the designing, building, and programming.

[Billfred]

My answer: Whatever works for your team. The amount of student/mentor input and direction on the robot build (both in design and construction) varies from year to year on 2815. It's never zero for either side.