What to do when mentors are leading the team in the wrong direction?

[The Doctor]

Last year our team was made up of a bunch of upperclassmen, and this year we lost almost all of them, leaving only 4 people who have been on the team more than 2 years. This has made it increasingly difficult to compete with two of our mentors (unnamed) who seem increasingly intent on running the team themselves. I mean, shouldn't the team be student-led?

Take for example the issue of robot add-ons. Our original design (we actually did it in cad this year!) called for a 6wd chassis short enough to go under the low bar with the ability to pick up balls with an attachment at the front end. However, these two mentors got the idea in their heads that we should have an arm on the front to open door and gate-based defenses, because going over 5 isn't enough apparently? They also decided it would be a good idea to prototype an arm to climb the tower. Neither of these were part of our original design and strategy.

The worst part is that these mentors are leading several students in prototyping these add-ons, which leaves us with no fabricators to build our frame. In my opinion, the frame is kinda important, don't you think?

Like I said, us upperclassmen have had a tough time standing up to them. Does anyone have any idea how to rectify this situation??

[Jessi Kaestle]

Why do you think that the team should be student run and not mentor run? Each team is different and there is no "right way" for all teams to do anything.

The mentors are prototyping with students, how does that not align with your current design if they are just prototyping?

Are the two mentors that "took over" the head mentors? If not, try going to the head mentor and explain your concerns.

[logank013]

I feel like there is a big difference between mentor led prototypes versus mostly mentor built robots. It's when your mentors are building most of your competition robot or aren't considering any student designs for your robot is when you should get concerned. Feel free to PM me if you want to go into more detail in private.

[Michael Corsetto]

First, I recommend taking a few deep breaths. You'll get through this

Second, read back on the post you just made. As a third party, it comes off to me as whiny. Its not bad to be frustrated, but the way you communicate frustrations can have huge implications on your effectiveness to navigate conflict.

Third, I recommend talking to a level-headed adult (preferably outside of robotics) about how you can be a positive contributor to this problem-solving opportunity (aka getting your entire team, both students and mentors, on the same page and working as a cohesive unit).

Fourth, take the new-found wisdom from aforementioned level-headed adult and schedule a time to sit down with your lead mentor/teacher and these two mentors you have conflict with. Aim to find solutions to conflict that include compromises to both parties so your team can land at a happy medium.

I know sitting down and "just talking" in the middle of build season might seem like a waste of time, but trust me, its worth it!

-Mike

[ey206208]

Unfortunately, a team lead by mentors is OK by the idea of first. The job as students is to be inspired. I do not agree with this, and the students should lead the process. My team has had a similar issue where a few mentors were pulling the team in a direction the students did not.

Here is what we did: A few of the student talked to the head mentor about how we were not happy with the direction a few mentors were pulling the team. We had a meeting with the whole team to try to re-adjust our approach, and try to make decisions more team-centered. So far, it seems to have worked.

I would recommend voicing your opinions to the mentor you feel confident will take your concerns and try to make a change. Hopefully you feel this is a an option.

[logank013]

Originally Posted by ey206208

Unfortunately, a team lead by mentors is OK by the idea of first. The job as students is to be inspired. I do not agree with this, and the students should lead the process. My team has had a similar issue where a few mentors were pulling the team in a direction the students did not.

Here is what we did: A few of the student talked to the head mentor about how we were not happy with the direction a few mentors were pulling the team. We had a meeting with the whole team to try to re-adjust our approach, and try to make decisions more team-centered. So far, it seems to have worked.

I would recommend voicing your opinions to the mentor you feel confident will take your concerns and try to make a change. Hopefully you feel this is a an option.

I agree with what he says. Having every major decision made by the whole team will help a lot. That's basically what we do. So say your team is choosing from three drive trains. Make certain criteria a drive team needs to meet this year. See what criteria each drive train does as a team. Make a pro/con list on a white board as a team. Have some discussion (will come with no problems when making the pro/con list) and talk about why you'd want to choose drive train A. At the end, look at the lists and rankings and summarize each drive trains capabilities for this game. Then take a team vote. It works well and people don't feel left out. Plus it means majority rules. And if two are really close in vote, try prototyping them further and let the results speak.

[sanddrag]

Originally Posted by logank013

Then take a team vote. It works well and people don't feel left out. Plus it means majority rules.

In the words of JVN, "Voting is not an engineering decision making process."

Also, howabout the people who are consistently in the minority? They will in fact feel more left out.

[GreyingJay]

Originally Posted by sanddrag

In the words of JVN, "Voting is not an engineering decision making process."

Also, howabout the people who are consistently in the minority? They will in fact feel more left out.

Voting by popular opinion is not an engineering decision making process.

But the process of analyzing each option, listing pros and cons, weighting them, deciding what levels of risks and tradeoffs are acceptable, can lead to a decision by consensus.

People who are consistently in the minority in this type of decision making tend to have different base criteria than the others. They have a different level of acceptable risk for example, or they are using decision factors not in everyone else's mindset (like "coolness factor").

[The Doctor]

Originally Posted by GreyingJay

Voting by popular opinion is not an engineering decision making process.

But the process of analyzing each option, listing pros and cons, weighting them, deciding what levels of risks and tradeoffs are acceptable, can lead to a decision by consensus.

People who are consistently in the minority in this type of decision making tend to have different base criteria than the others. They have a different level of acceptable risk for example, or they are using decision factors not in everyone else's mindset (like "coolness factor").

This is also somewhat of a problem this year with so many unexperienced members who don't know the difference between Labview and a PCM, therefore wouldn't be very valuable in a democratic process. One of the mentors in question here could also be considered part of this group, as they don't have much experience with manufacturing and engineering, but they're pushing some design aspects just because they saw them on Ri3D and though they looked cool.

[Chris Fultz]

Originally Posted by sanddrag

In the words of JVN, "Voting is not an engineering decision making process."

I agree and will expand a little on what Logan said. By capturing the objective criteria and then evaluating options based on those criteria, the best solution is often very obvious. If it still comes down to 2 very good choices, then additional testing, prototyping and evaluation is required.

"Data Driven Decisions".

[mrnoble]

It's always tough for us CD participants to evaluate these types of problems. Even long and detailed descriptions of the situation leave important information out, and show (mostly) the side of the aggrieved. From your brief description, OP, I see nothing inherently wrong or un-FIRST about your situation. Mentor involvement is part of the program, and each team decides how deeply the mentors should get in the decision process. You've also got a small team, it seems, so each person has more weight in the process. I hope you can work it out; I hope you can talk to the mentors and other students without it becoming a passive-aggressive drama, and that you will find the adults to be reasonable and wise.

[tcjinaz]

Originally Posted by sanddrag

In the words of JVN, "Voting is not an engineering decision making process."

Also, howabout the people who are consistently in the minority? They will in fact feel more left out.

Kinda sounds like how we decided on programming in Java this year. My first contact with a bunch of the students this year (September) was in a meeting where a number of "experienced" people (including the lead mentor) held a vote on Java versus LabView in the finest traditions of the Soviet Politburo. The outcome was predetermined, and there was no time for rational technical arguments. None of the "experienced" folks in that effort are involved in the controls & software side of the robot now, and we're struggling with a bunch of rookies who can't see what's going on. The grand virtue of LabView is that you can see what's going to happen.

Gee, just like the multi-million dollar mistake I am living through at work. Kids. welcome to the real world.

TJ

[Christopher149]

Originally Posted by The Doctor

Our original design (we actually did it in cad this year!) called for a 6wd chassis short enough to go under the low bar with the ability to pick up balls with an attachment at the front end.

Oddly enough, this sounds a lot like our present design, CAD included (though, ours has 10 wheels ).

How many students do you have (other than the few experienced ones)? And in terms of the number of mechanisms, it seems apt to point out:

Originally Posted by Effective FIRST Strategies - 1114

Golden Rule #2: If a team has 30 units of robot and functions have maximum of 10 units, better to have 3 functions at 10/10 instead of 5 at 6/10

[philso]

Originally Posted by sanddrag

In the words of JVN, "Voting is not an engineering decision making process."

Also, howabout the people who are consistently in the minority? They will in fact feel more left out.

Originally Posted by GreyingJay

People who are consistently in the minority in this type of decision making tend to have different base criteria than the others. They have a different level of acceptable risk for example, or they are using decision factors not in everyone else's mindset (like "coolness factor").

The people in the minority may have a better understanding of the situation than the majority. The majority might be trivializing/overlooking a major disadvantage of the solution they are favoring. We currently have a situation like this.

It is part of human nature to let emotions affect the decisions we make, especially when we vote. I have also watched votes where team members voted for what their friends voted for rather than evaluating the evidence for themselves and making their own decision.

[GreyingJay]

Originally Posted by philso

The people in the minority may have a better understanding of the situation than the majority. The majority might be trivializing/overlooking a major disadvantage of the solution they are favoring. We currently have a situation like this.

OK, that's fair. But it's the same problem - those people have access to different data and experiences than the others, so their job should be to educate the others. Or, the others will soon discover for themselves (perhaps during prototyping) what the minority knew about that they didn't. It's still not about a popularity contest.

Originally Posted by philso

It is part of human nature to let emotions affect the decisions we make, especially when we vote. I have also watched votes where team members voted for what their friends voted for rather than evaluating the evidence for themselves and making their own decision.

Sounds a lot like the Asch experiments.