Mentors VS Students

[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

[Blue_Mist]

In a way, we're having the same problem. Not to the extent that you guys seem to have, but the same general issue. Our mentors decided a while ago that the robot would be professionally welded, and when we had a debate, one of the mentors called for a vote. The first option was send the part of the robot they wanted. The second option was supposed to be debate some more, but we never got there. Tomorrow is another build session, and we're planning to talk to the mentors together.

I suggest talking to the students first, as to present a united front. We have maybe ten to fifteen students who are deeply involved and three mentors. It might be easier to collect all the students together and discuss this without the mentors if there is a smaller number of people on the team. In my experience, the larger the group, the fewer opportunities to gather people's busy schedules together and talk about important subjects. After lunch might be a good time when people aren't waiting for the debate to end so they can have lunch, and people are generally more easy-going when they're fed.

[thatmorman]

i dont know if this helps your situation too much, but our team motto is student designed, student built, and mentor approved. our mentors are strictly hands off, but for design, they play a big role, but they do not make the decisions for us, they say well that would work better, or that wont be as affective, but as long as a decision would get you by, they do not change the design or idea. you should have a meeting between your team captains and mentors and politely discuss the problem, just make sure they know what first is all about and that this is not all about winning, it is about learning, we are a 4 year team this year, we are very fortunate mentor and student wise to make good decisions and put out good ideas and our mentors do not have to play the biggest role in building the robot, but they still do a ton, but they know that this is our game, not theres. good luck with everything!

[ghebinkim]

We have never had a similar problem, so I don't feel that I can offer any advice on how to fix your problem =\

However, I will say that I definitely think that the mentors shouldn't be influencing your designs and ideas that much... isn't the point of FIRST to get students involved in technology, not adults? We're a rookie team, but we have no mentors, no coach. It's just 10 kids out on their own, and we might not have the best design, but at least it's all ours.

I hope everything works out for you guys.

[Michael Corsetto]

Let me start off by saying that every team is set up differently. Some teams have a technically strong student base that takes the initiative and does all or a majority of the work. Other teams have very professional, experienced and dedicated mentors who do a majority of the work but (hopefully) walk the students through the whole process to give them a look into what being an engineer is all about. A majority of teams though have some sort of mentor to student ratio that they feel provides the best experience for both groups.

I think that it should really be the students decision as to how much mentor involvement they want on the team, but this should be determined with everyone present and should be something that is followed from that point on. It isn't right to one day say that you, as a student group, want to design and build everything yourself and want the mentors to mind their own business, then the next day ask the mentors for help because you realize you don't know what to do. Having technical mentors available to you is an amazing privilege and should not be abused. These professionals come in on their own time and should be treated with respect.

That being said, it also isn't right for a mentor to deviate from the teams approved design, just as it would be for a student to do the same thing. A team meeting should be held with the team as a whole and the matter should be discussed openly and maturely. Depending on how your team is currently structured and what the ratio of mentor to student work is, the mentor may not have felt that what he did was out of line. I know personally, being a freshmen in college and coming back to mentor my old team over the MLK weekend, I had to be called out by a current student about doing to much work on the robot before even I realized it myself. So please leave tempers out it and discuss the matter as adults (yes, you may not legally be an "adult", but FRC is for big kids, so grow up) Most of all, remember that your on a TEAM, and on a team there should be no "mentors vs students".

Just my two cents,
Mike C.

[45Auto]

Where can I go to get some of these students with initiative???!!!

My problem as a mentor is motivation and getting the students to do anything. We typically have 10-15 total students on the team. 2 or 3 at the most are even vaguely interested in acknowledging (much less learning) any kind of basic engineering concepts that are necessary to build an effective robot. The vast majority just want to hook something together and hope it works, while having a good time jacking around with their friends.

Do the mentors just sit back and let the team turn into a social club with a robot that will go around the track and little else?

Do you work with the 1 or 2 students who really want to do this and let them carry the rest of the team?

What are some good methods of getting students to show some more initiative?

[ebarker]

Originally Posted by 45Auto

What are some good methods of getting students to show some more initiative?

With some students if you say "who wants to do x thing" or "we need someone to do x thing" they will just sit there. So you can say "you, you, and you just volunteered to do x thing" is a start.

On the issue of Students versus Mentors, here is a concept that both parties need to get their heads around:

The mathematics of FIRST mentorship

Mentors focusing on making themselves progressively unnecessary takes work. Students focusing on taking initiative takes work on their part too. It is good to remind each other occasionally to drive toward these targets.

[Liz Smith]

The benefit of this program isn't just to have students learn about engineering. It's about the teaching of engineering and design through mentorship. From what I see, your problem is not that your design ideas aren't being heard, and the mentors are doing what they want. I think the problem within your team is more of a lack of communication. Work with your mentors.

There should be reasons you have for designing parts a certain way. (ex: Arm has to be x inches long in order to fit in the starting box) If you're there with the mentors while parts are being made, then you can share your ideas and concerns and designs and they can also give insight and advice. I think the issue may be that all the students are doing work in "one room" and the mentors are doing work in "another room".

[Steve_Alaniz]

Being a mentor is a delicate balancing act. Mentors bring "life experience" and skills that come from years of working with materials, tools and having seen solutions to problems that might help with the robot build.
But FIRST is all about the students. The mentors are only there FOR the students. That's not always a lot of fun but the compensation is having a lot of responsibility. Or so it seems.
For example, safety is everyone's responsibility but this especially falls to the mentors since they are the Responsible Adult. The same can be said about design. Just from an advantage of age, mentors have probably seen more mechanisms and understand their design and have a responsibility to present ideas or even explain why they might not think your idea is a good one (ouch!).
In the end, the mentors could probably do it all by themselves but that would totally defeat the purpose of FIRST. The other extreme is allowing a totally hands off approach which denies the team the advantage of the mentor's resources and experiences.
Mentors have to know when to let people struggle with a concept and when to step in to help drill, tap, cut when there is a time constraint. Sometimes, help avert failure, or even disaster. (I'm not saying mentors can't be the cause of either failure or disaster, but they bear the full responsibility of the results. A student cannot be held to the same accountability because they ARE the student.)
Mentoring is a very "check your ego at the door" job. I've presented various concepts from time to time and have had them rejected by the students. No problem. There is always more than one way to skin a cat... (I know 6) and what may not be the best method, in my opinion, may still work.
So being a mentor is not about pushing students around to force them to do it MY way, because that has so far, never happened to me. (except when it comes to safety glasses... you WILL wear them!) I AM enthusiastic. I want to share what I know and I have to do that in a way that doesn't sound like I'm being pushy.
All I'm saying is that it is not always easy to know HOW to mentor so I'd be surprised if any team never had some friction between students and mentors, but it's not some kind of Student Versus Mentor game. Please allow the mentors the benefit of the doubt and that they are trying their best to help you achieve in FIRST because it really isn't about Mentors, it about you guys.

Steve

[JaneYoung]

You've identified some of the issues that are slowing the build and that is a good thing. A team where everyone works together towards the common goal is an achievement in itself. Getting organized and staying on track/on task is a big part of achieving the goal. Communicating with each other during the design/build is another part of this. If you can, ask for a team meeting to get everyone back on track, working with each other. Liz is spot on.

Also, it can be very hard to stick with a team when things are not running as smoothly as they could be. Many students already have a full plate with academics and school events, as well as other clubs and organizations. At the same time, sticking with a team that is struggling and developing can be rewarding and satisfying - knowing that you are playing a part in helping the team improve.

Another suggestion that we've found helpful is to make notes of this build/competition season and have a postmortem at the end of it, addressing what worked and what did not.

[dcbrown]

This is always a pressure point within organizations that generates lots of "issues". At a simplistic level, groups go through the forming, norming, storming, and performing stages... but often get stuck in "storming" due to conflicting goals and expectations. I see this come up often when team leadership vs membership have different ideas or goals on where they are headed.

My motto has been you can't succeed without failure. It may sound funny, but in general I find this true. If you succeed, you typically are not 100% absolutely positively sure on why you succeeded. But have a failure? Oh boy, hindsight is great isn't it!

Mentors can either hide the experience of failure or support the right of a student in gaining that experience. This may sound cruel or cold or heartless -- but in the longer view my personal experience has been that it is always the better choice. Ok, as a mentor its not "fun" to watch and you end up biting your tongue a lot, but still...

The problem is how much failure do you allow to occur (no one LIKES to fail or PLANS to fail... but it happens anyway). Certainly where any safety issue exists, the "responsible adult" in us must step forward to prevent bad things from happening. But as a mentor I'd rather support a crappy design and the passion behind it (while pointing out some possible pitfalls/weaknesses based upon experience) rather than killing off the enthusiasm by seemingly taking over.

Whether the team is mentor run, student staffed or student run, mentor advised or some other combination, this is fine as long as all team members understand that is the team culture and buy-in.

One last thought. Just as you cannot be a leader without followers, you cannot have a team without students.

But that is just another set of random opinions.

[Team2339]

The relation between Mentor/Student should evolve as your team gains experience.
As dcbrown posted, Failure teaches, sucess just is. Our team is also a rookie team. We finally bonded after the van motor ( my dumb idea ) failed to hold the arm up. Ideas poured out like water and the design by students was on.
I am no longer the sole driving force behind design, and the students have started to assert themselves on the team.
Each team develops at their own pace, depending on needs, personalities, and set goals.
Set the goals, set the design, then build the parts. By then, everyone is on the same page.
Definitely work out the differences before the whole thing becomes a bad experience.

[dcbrown]

Ok, another meaningless rant...

Cognative learning styles. There are "otters", "squirrels", "mice", and "moles". Otters just jump in and swim! Experience by doing! Lots of students are otters. I'm not sure if its true of most engineers, but I'm more of a "squirrel" - a fact finder: go here, go there, and examine EVERYTHING before making a decision. "Otters", understandably, drive me crazy! But I understand and recognize their different action/cognative style and learn to adjust/co-exist & support them.

Anyway, if mentors don't recognize and have a strategy for handling the different action styles, channel them to appropriate activities for example, then lots of intra-group friction can occur.

[ebarker]

Originally Posted by dcbrown

groups go through the forming, norming, storming, and performing stages... but often get stuck in "storming" due to conflicting goals and expectations.

Looking forward to this fall your team might want to engage in a series of structured activities. It can accomplish two things. It helps the group move through the group dynamics stated above. That helps a lot when the build season starts. And it give the group an opportunity to do some fun stuff. It is tough getting to the performing stage in 6 weeks with a group that hasn't worked together before.

Our team did a series of exercises all through the fall and it is paying benefits now. I wish we had done the MOE egg toss trebuchet. But our other stuff was good enough.

[ebarker]

Originally Posted by Team2339

We finally bonded after the van motor ( my dumb idea ) failed to hold the arm up.

If the goal is to 'force' a failure to get the team jump started started then the idea isn't dumb but really smart.

Now we are talking about original intent, but pssssttt, we will keep it a secret and not tell your students.

Really, it was genius.