Mentors VS Students

[JesseK]

Originally Posted by purduephotog

Something else to think of: Sometimes mentors may see a design flaw and try to correct or plan for it if something fails. They may talk and try to steer or get the students to see the problem, but if they don't... said flaw might not manifest until later.

But yes, it's disturbing to be handed a new part when the design hasn't shifted.

This is most definitely true. And most of the time, it seems to be that any given flaw is noticed during the one build session when the person who initially designed that part is absent. No amount of communication will alleviate the frustration of coming back to a new part in this scenario, which seems to happen more often than not in my experience. It's not intentional; it just happens.

It basically boils down to how open-minded everyone is and (agreed) the magnitude of any trust issues.

[pyroslev]

Its easy to see that all teams have the issue of mentor(s) versus students at times. We had a situation last night.

A/The mentor for the programmers came by last night. He's good at what he does but in all honesty he has not read the games rules but once and thought we had another week. He took a minute to watch what they were doing and in his own words as best I remember,

"I think I am ready to usurp control."

I myself am a mentor and am ashamed of his actions and what the results will be on those that were not there to see the changes he made.

[Straberrie]

Originally Posted by cmonkey99

We're having some problems on our team as Mentor vs. Student powers lately.

It seems that about 5 of us will start working on the robot with our previously decided design and one of our mentors will come back from the shop with the part already built but in a completely different design and most of the time very quickly and poorly done.

Then about half the time we're able to convince them to change the part back and the other half of the time they "convince" us with their supreme knowledge( )that their idea or part is better.

Now I thought the purpose of the mentors was to suggest things sometimes and help us out when we needed it. Not to change our design and make half-baked parts.

Its gotten to the point where I almost feel like dropping out of the club and focusing on MESA and other things.

Not to mention the fact that there are only about half the students doing much work, the other half just sit around and shoot the breeze.

I was wondering if any of you have faced similar situations or have any suggestions.

Keep in mind we're a fairly small team with about 4-7 students and 2-3 mentors at each build meeting

Thanks for any help

Well! If that is a problem, I suggest you confront your mentors about it! Mentors are there to help you and I am sure that their HUUUUUGE input into the team.... even if it means changing the design is only provided to help you. The mentors see flaws in the design and just want you guys to do a really good job, so they over do it. Just tell the mentors that you do not particularly like everything being changed and I am sure they will work something out. If you simply tell them to change something back, they might not see a reason to do it if their design is the one that works best, but if you explain to them that you want to be a part of the team and by team you do not mean one person (mentor) group, they will probably understand that they were a bit too clueless about teamwork.

Our team is also pretty small and we don't have too many mentors coming at each meeting, but they help us. They don't build the robot by themselves, but when we are having trouble, they are always there to help out. I know from experience that mentors are there not to restrict you, but to elivate your skill. Besides, I am sure that some parts of your designs were implemented into the new versions your mentors created! Even though we don;t have such problem, if we would, we would just all group up and simply tell the mentors what is wrong. They just wanna help you the best they can, so don't complain, just talk to them, K?

[Matth3w]

My science teacher/Mentor tells us that there are two types of FRC team robots. Student built robots and robots assembled by students. Our robot is hard to control, and it lifts the ball a few inches from the ground. In our eyes as rookies, thats more than success. In your situation, it is still a student built robot im sure, just with a communication gap between the adults and students. It sounds frustrating i agree, but it also sounds like the mentors really want you guys to succeed. I don't know what your teams idea of success is, but i wish you guys the best.

[Scottman]

don't worry the same thing happen to us this year too
there was some conflict between the students and the mentors on the design and how the team was acting and performing, the teachers decided that the robot was the students not the mentors and let the students build the robot how we wanted
just put it behind you and shot for the ship date and if you get it you get it if you don't there is always next year

[PrincessJae]

close to your same situation, we have 12 team members and 3 mentors. They are strickly hands off and give us suggestions on what to do and provide organization and make sure everyones on task. But everything concerning the robot is up to us. They can add advice- but basically we have the final say on everything.

[647techangel]

instead of quitting and giving up on the team, compermise with the mentors and become a good team leader and get the students that do nothing to do something(make them feel important).
its the worse thing is 2 give up
i should kno i have been through this type of thing

[Zyik]

You have to remember that FIRST isn't just about the students. It's about students and mentors working together and learning from each other to create something beautiful. So, with that in mind, I'd like to say this about 973.

Normally, 973 spends a couple of weeks hammering out a design and ends up way behind, using the practice day at regionals to finish up building. However, this year, for once, we were ahead. We got our general robot design withing the first few days, as opposed to the first few weeks. We managed to finish the bot before ship date and got several days of driving it around to practice. We also have a design that, I at least believe and the practice matches appear to agree with me, will do well, far apposed to how we normally do.

This is primarily thanks to one mentor. He's been a constant inspiration, keeping us on schedule, and generally helping in every department, from programming to machining. Without him we would be back in our old habits and the robot would be far from finished, let alone ready to be in its crate already. He doesn't just hand out an answer, he shows you why his is better using math and logic, something that our mentors don't normally do as most of the time we are so far behind schedule we have to rely on the "I'm a mentor so I know better" reason. So, not only has our robot improved with the addition of him, the teams overall knowledge has as well.

In other words, thanks Adam Heard. We wouldn't be where we are without you. You may be a bit of a jerk sometimes, but we owe ya.

[catsylve]

If the mentors and students on a team are not seeing eye to eye or are having issues with who is supposed to do what, it seems that you may need to try some team building. Now that the build season is coming to a close, try taking a little time to get to know each other.

When a trust begins to develop, it is easier for mentors to turn tasks over to the students and let them incorporate their own ideas.

As a teacher, I recognize the difficulty of getting to know a new group of people over and over again. You worry about keeping things safe and making them work out for everyone. But if you establish a trust at the beginning of the season, you will have a more productive and comfortable build.

You need to accomplish this in the off season or pre-build.

[GeorgeTheEng]

This has been an interesting discussion to read through and I have to put in some input from my own experiences this season. My students have stuggled with one or two engineers this year who are new. Some of the kids and I had a heart to heart chat about why and it drifted to how my approach to working with them is different then the new engineer's approach.

At the most basic level, I treat them as adults. When I discuss an option or design I don't discount any points of view. I think whatever decision is made, there is a strong desire in anyone to feel heard and respected.

I will admit that at times, I do strongly suggest or force certain decisions. And with a VERY limited number of decisions insist on specific decisions. But I do a couple of things. I'm a mentor so you can claim my decision is based on experience and that may be true. But am I serving the students well if I make statements like "this is the decision..." or "this is the way it is going to be..." without putting my reasoning behind it? I don't think so. I think a mentors approach should generally be help and direct the student's decision so that they understand why I want something do a specific way. A Phrase like "Wouldn't it be safer to run the wires inside the arm rather because another robot could accidentally run into us and rip them out in their current location" does more to help a student understand then "we're running the wires down the inside." It also keeps the door open for additional suggestions. And as engineer who works for a company with a strong peer review process, I know that you always need to be open to suggestion. In addition, by asking questions and leading the students can be guided through the thought process that we've spent many years developing.

Our experience as mentors is only beneficial to the students if they are allowed to understand the rationale behind a decision.

The team is both mentors and students. We all put in lots of hours, blood, sweat, and tears into the hunk of metal and electronics that goes on the field. If a team communicates effectively and all opinions are respected, then everyone from the student to the mentor to the CEO of the major sponsors should be able to take pride in what ends up on the field.

I challenge teams to define whether the season was successful NOW. The performance of the robot, and the awards should be secondary to the experience that ends officially in the next few hours when FedEx loads your crate into it's truck. I for one, will say that Team 87 was successful.

[purduephotog]

Why does it have to be 'mentor vs student'?

The other day we had this situation arise. I had my opinion. Another mentor had his opinion. We called one of the student leaders over to 'settle it' (since we were all pushing student designed student built). We both stated our cases. Poor kid looked like a deer in the headlights and finally said "But no matter what I saw one of you is going to be mad at me!".

Funny thing was, both the other mentor and I answered at the same time "No we aren't". We didn't care- and we explained that if he chose idea 1, we'd go with that for now and build a backup of idea 2, and vice-versa.

The second problem ... we'll save that for another post.

[Chris Fultz]

First, I wish the title was "Mentors and Students" - that is a little more representative of the idea of a team.

But, to the topic. There is lots that could be written, but the first sugestion is to try and talk it out with the team. Talk to other students and see if they share your view, or if you are alone it in. Talk to the mentors, and explain how you feel things are going and ask if there are some better ways. Talk and work it out. In the end, a team needs both motivated students and motivated mentors to be successful.

Remember, their is no defined way to run a team. Some work very well with a high level of mentor activity, some with a high level of student activity, and others with a blend of the two. Chances are, the 'better' teams (define that however you want) have learned a "style" over a few years and have adapted to it - mentors and students.

As a mentor, one of the biggest challenges is to know when to step in. Yes, there is value in letting a student make a mistake and learning from it, but sometimes those mistakes have a significant impact on several students and mentors. Letting one student "learn from their mistake" by having a robot break down in match 1 of a weekend is an expensive price for a whole team to pay and not fair to anyone involved, especially if a "better way" would have prevented it. Even letting a whole group learn by buildig a robot that cannot function is a high price to pay for a "lesson".

A mentor is responsible and accountable to several people - students want to learn and be inspired, other mentors want to contribute, parents want their kids to gain some real knowledge from the program, school administration wants to be sure the students are safe and benefiting, sponsors want to be well represented by their teams, the mentor himself / herself needs to know they are adding value to the process - if not there are lots of other things to do with their time. If things go really wrong, it is more likely for the mentor to hear about it than the students. It is a delicate balancing act and is not easy for anyone.

[Joe Matt]

Originally Posted by dlavery

So what you are saying is: you don't have mentors, you have accountants.

That is unfortunate. Both you and your "mentors" are missing out on some great opportunities. I would really urge you to go back and listen to the discussion from the kick-off. Hopefully, some of the comments there will strike a chord.

-dave




.

I agree, except I think FIRST sometimes gives too much benifit of the doubt to mentors, saying they're the bee's knees and the only other option is a bunch of idiot students running around.

Think of the build season as kiddie bowling. Mentors should be the bumpers and your mom who lines you up and gives you advice. They're all there to help you achieve success and offer encouragement, but they can incorrectly be ignored too. The fun thing is finding the balance between the "it's my robot set, get away kids" teams and the "what is a mentor" teams. That's where FIRST works wonders.

[Gdeaver]

The very title of this post exposes the problem. The concept of us and them has been driving the human race crazy for ever. Some think First is all about science and tech. I submit that the greatest benifit First imparts on teams is the TEAM thing. Sounds like this team has failed in this most critical test of the build season. You have not become a TEAM. You are a bunch of bickering individuals. You loose.... For next year your TEAM needs to discuss the people issues and look for methods and activities to build and nurture the team's people skills. This can be much harder than building a robot. This year our TEAM was faced with an insurmountable pile of problems. No money, not enough meeting times, baned from using anything but hand tools, And on and on. But, we came together and work as a TEAM and over came every problem. I am very proud to be a part of this year's team. We won. Now the problem for me is to figure out why this years team came together and why the 2007 team did not to the same degree. The most challenging problems in life are the people problems.