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

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??

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.

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.

First, I recommend taking a few deep breaths. You’ll get through this :slight_smile:

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!


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.

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

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

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:

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.

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.

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

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.

Sounds a lot like the Asch experiments.

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.

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

Sometimes, the challenge is to get people to be willing to listen or to understand that they need to learn something. Until that is achieved, efforts to educate are fruitless. As a mentor, you may have had students telling you that you are wrong about something you have done for twice as long as they have been alive :smiley:

Thanks for the link to the Asch experiments. Fascinating.

The Doctor: There are a lot of good thoughts in this thread. Heed them.

A couple other things:

A team cannot be completely student-led and expect to compete. The beauty of FIRST is that it creates partnerships between students and professionals where students get to fully participate in the design process of something well more complex than what they could do on their own, with professional engineers as mentors. Mentors must be a part of the leadership of a team. At the same time, it is correct that students need to have a huge role as well.

How this is balanced necessarily changes from team to team. Are there teams that go too far in one direction or the other? Sure. Of course, that might just be my opinion… Even on our team, the balance changes a little each year. Two years ago, our team was full of talented seniors, so we let them lead the way - and let them ignore the advice of mentors as they pushed hard and really needed to learn from mistakes. Last year, our leadership team was much younger and needed more guidance. This year we are balanced somewhere between the two. The point is, every team is different every year - and there will always be somebody who disagrees with the balance that your team finds. To a degree, you will have to trust your mentors on this.

At the same time, it does sound like you are unclear as to the team’s decision-making process. I do believe that being clear on this is one of the most important things about running any organization… What do you do when different folks have different opinions? After all, if you put 100 brilliant engineers in a room to solve a problem, you are likely to end up with 150 different opinions… I do believe voting is poor… We tend to have lots of inexperienced kids each year. Should kids who have never built or designed a robot have a strong voice in the engineering and design decisions?

I would start by talking to your head mentor. Express your concerns, but use it as a time to better understand how s/he is leading the team and what his/her vision for the year is…

You really have two separate questions here. There’s a lot of good advice here, but here’s my input as well.

Your team should be run in a way that works well for your team. That will depend on the nature of your team as well as your goals, and the exact balance of leadership between students and mentors is likely to change a bit from year to year. Over the years, we’ve come to an arrangement that works for us, in which the mentors provide guidance to the student leaders, and help them lead the rest of the team. The amount of guidance depends on the leadership team that year, but even the most capable students can benefit from the experience of the mentors. You said yourself that you lost most of your experienced members - you’re likely to be in a position in which more guidance from the mentors is appropriate.

I’ve had experience with a team pushing to be 100% student-led as a reaction to students feeling that the previous season had been too mentor-driven. I’d like to caution you against that - it was not a good experience for anybody on the team, particularly not the students. With that said, I don’t know your team, and I’ve only heard one side of your story, so I’m not in a position to judge how things are going on your team.

My recommendation for handling the situation with your mentors would be to sit down and have a talk with your lead mentor about the concerns you’ve expressed here. If you don’t feel comfortable having this discussion with them, pick a mentor you are comfortable talking with. It’s important to stay calm and to remember that your mentors want this to be a good experience for everyone. Explain the problems as you see them, and be prepared to listen as well, not just talk.

I’m not really in a position to comment on your strategy or design, aside from saying that the frame is indeed important. My best recommendation would be to sit down with your mentors and ask if your team can do a review of how well you’re addressing the design requirements for the strategy you’re working towards.

Information and communication are two of the most important aspects of getting a team to work coherently together (mentors and students alike). During my two years, especially last year, my team has been extremely student-driven, and that worked well for us. However, I’ve seen teams that are mentor-driven, too, for good reason. There is no perfect balance, no “one-size-fits-all” scenario, and I think it’s unfair to say “Student-driven is better” or “Mentor-driven is better” because both can be the case in different situations.

I disagree with the idea of voting given that most cases of that allow uninformed students to vote. Last year, my team made a great offseason tank drive that improved upon the previous season’s drive train, which we were planning to use. However, when RR was revealed, the whole team suddenly convinced themselves that a swerve drive was the only good option, and that we should build one. I was in the tiny minority (less than 5 students, pretty sure) that believed that swerve would cost us more than the benefits we would receive (especially since holonomic drives were a better overall option when defense isn’t present). In response, those opposed to swerve made a clear list explaining the pros and cons of each drive system, and we were able to convince the team to go with something a bit more manageable, mecanum. If we had voted on a drive system, swerve would have probably happened and we wouldn’t be sitting with our district win blue banner now.

Communication is important. You mention that the mentors are pushing these prototypes that you feel aren’t in line with your team strategy. Ask them why! I’m sure they have a good reason behind their choice, and if they don’t, maybe they will re-evaluate their choice. Also tell them how you feel. Information is important, too - explain logically (e.g. cost, time, effectiveness) why you feel their choice is unwise. Offer an alternative, and explain why you feel it’s right. Put everything on the table, and make sure everyone is coming to a decision together, since no one should be getting “their way” on a team.

I’m pleased to see that a good deal of the advice I see being given here I agree with. My own team has this squabble recurring. I think declaring one group (students/mentor) ‘runs’ the team is wrong. You need to get together.

Technical adults that volunteer their time (and money?) to a robotics team do expect some kind of a return for it. Mostly the good feeling of cooperation and teaching, spreading the ‘engineering bug’, but winning can be nice too. So when an engineer has what he/she thinks is a good idea, of course he/she should be allowed to prototype it. But the same for the newbie/rookie. I’ll help everyone prototype to the best of my ability. Even if I don’t like their idea, I’ll still do my best with it. What we do is brainstorm ideas and then vote on the ones to prototype to keep it manageable.

The reason they’re ‘mentors’ is presumably they have training and experience that gives them more knowledge than young people about this specific subject. As a mentor, I’ve seen thousands of machines and hundreds of FRC robots. Please stop thinking you’re better at this than me.

But you said you’re ‘prototyping’ and I think that’s a great sign. When my team prototypes (which I really think should be called ‘proof of concept’, because we’re not going into production), then we compare the different designs and try to use objective data–can drive train 1 cross the rough terrain 6 of ten times, while drive train 2 can only cross one of ten.

This way its not ‘voting’ and ‘opinions’ that rule the decision making process, but instead something approaching “Science.” This is the way to get buy-in from the ‘minority’ voters. Yes, some criteria is weighted and there is always ‘sway’ toward one idea or another. But if you’ve ‘proved’ one idea is better, then you have to agree.

As for prototyping half-way into build season, I think you should’ve been done with it a week ago. Good luck!

As for the frame being important, I personally think the mechanisms are more important and the frame just ties them together. You can’t design the frame–using CAD or cardboard–until you’ve compared and chosen the mechanisms. We use a kit frame often and still make good robot.

Anyway, just don’t lose heart. You guys gotta get along and telling mentors that you students run the team isn’t the way to do it. It’s about working together.