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").

[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.

[IronicDeadBird]

Originally Posted by 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??

The issue I see here is that you have mentors allocating resources to something you don't agree with. The compromise in my mind would be to re-distribute students so you can fabricate things and just leave an open enough frame that you can have modular super structures. In my humble opinion drive bases are pretty pretty pretty important. Remind them that without a frame the super structure isn't going anywhere any time soon. Anyway if you just try and get a solid modular robot the mentors will be able to prototype FOREVER and you will have the frame.

[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".

[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.

[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.

[RRLedford]

You are clearly upset with the perceived redirection of the team efforts away from the original plan.

All upsets will usually boil down to one (or a combination ) of three things:

1) Undelivered communication(s)
2 Unfulfilled expectation(s)
3) Thwarted intension(s)


In the case of #1 - I suggest that the ideas being hashed out in this thread need to be transitioned ASAP into a team meeting discussion covering the same topic of this thread.

This meeting discussion needs to address any issues relating to #2 as far as design agreements made and abandoned, (without consensus), and how you think that the #3 goal of doing well in competition may be put at risk if the boulder gathering and shooting is torpedoed by plans for adding an arm concept that occupies the needed space for the boulder mechanisms.

Priorities will need to be clearly reestablished and compromises will likely need to be made, but the bottom line is that the entire team needs to get back on the same page, or the season will turn into one where mentors/members will be blaming each other for future issues/failures, giving less than their max. efforts, and undermining progress toward goals to which they haven't fully committed to accomplishing (which you can STILL DO even when you think another way could be better).

Remember that negative assessments within a team can only lead to negative impact on progress and results. The sooner you communicate and clear the air surrounding these negative assessments, the better.
Clinging to negative assessments only sets the stage for you to gather more proof that the negative assessment was correct, and nearly always, merely being right about an assessment is less satisfying than accomplishing the goal.

Using this thread to collect confirming views for your negative assessment of where things are heading with your team will ultimately do little to fulfill your FRC team's goals.

The process for that to happen needs to take place within the team itself, and with all members present and communicating honestly. However, you can gain some insights for how to handle such a meeting from this thread, and this is the purpose of my post.

-Dick Ledford