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

[philso]

Originally Posted by GreyingJay

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.

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

Thanks for the link to the Asch experiments. Fascinating.

[MrJohnston]

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

[jgerstein]

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

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?

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.

Originally Posted by The Doctor

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?

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.

[tindleroot]

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.

[hrench]

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.

[The Doctor]

Originally Posted by IronicDeadBird

The issue I see here is that you have mentors allocating resources to something you don't agree with.

It's not so much that I disagree, it's that we need our priorities reassessed (e.g. building a frame before the add-ons).

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

[The Doctor]

Originally Posted by hrench

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 agree with this, except that most of the ideas that have come up at this point have been taken directly from Ri3D, which makes me think that the people are promoting them are going mainly for the "OMG, we could do all of the defenses if we want to" idea... and not the "let's build a working robot before bag-and-tag this year" one.

[adambotz]

I experienced a similar problem and so have my friends. Most of the solutions here are telling you to talk to the mentors, well this is quite obvious. How are you going to be inspired by sitting down and having youre ideas crushed? If it is a school club, go talk to an administrator from school and tell them the problem and ask them for help.

[NicusTM]

As another member of the team I figured it'd be worth coming out from lurking around to say that this is a very huge issue this year for our team. Just today I was talking to another member of our team, who is normally incredibly motivated and productive, and he said if it kept up there wasn't much of a point even coming to team meetings anymore, since we simply aren't getting anywhere.

Me and him were thinking about simply writing out everything we felt needed to be changed around the team to bring productivity back up and get build season back on track, and have every member that agrees sign it, because at this rate we will only have a semi-functional robot to show for our efforts. Almost every single veteran on our team agrees that this year has simple gone awry so far, so that wouldn't be a half bad way to go about things.

Ultimately, this is a giant issue for our team this year, and I can reasonably assume that other teams may be having some similar issues as well, so maybe other teams can pick up some of the advice people have giving thus far and apply it to their teams.

[Mr. Ackroyd]

Great discussions going on with this topic. I am very sorry to hear that things are not going so well with your team this year.

Team dynamics are an eb and flow each year and need to be looked at and figured out before the season begins. I took over our team this year from a coach that began the team back in 2009. He lead them very well and had a good dynamic with the students and mentors. Strong student leaders really are what lead a team and that is difficult to have each year. What I mean by this, if you have student leaders that can lead their sub teams really well, it makes the mentors job a bit easier in which the mentor can focus on helping the students grow in design. If students are weak in some areas and have met their match in design the mentor can help guide.

Over the past three years our team has been lead more in a way by the kids, some good some bad comes with this setup. The mentors were given less of a role when decisions were being made for design reviews. This caused for delays in the schedule and many hardships in which the students were left with a bad taste. This year I came in with the notion that we are all a team, mentors and students. I wanted to create a culture where students lead in design and ideas. We had an aggressive schedule for design review this year and finalized our design by the second week. Students can only design and build to a certain point, so I instructed the mentors to help get the student to the next level and guide them with their expertise. Not doing the work for the student but asking the right questions. And all of this was completed in full team meetings and votes where the students asked the questions and mentors provided concern when needed.

In doing this we are two weeks ahead of where we have been during the last three years, the team morale is very high, the mentors are happy and the students feel a sense of urgency and accomplishment. Although we do not have a robot built. We have all necessary hardware components ready to go, besides tread. We are in the fine tuning stage where we are looking at electrical placements and making sure mechanical parts will fit where needed. Once we are happy, the plan is to build the robot in three days and when the treads arrive get them on quickly. We hope to have preliminary drive capability this time next week.

Good luck and I hope your team can get back on track

[James Juncker]

In the past our team has had some similar issues, what we have done is strategized over what we found important to the game, and determined what we would be building to complete those tasks. Some years we have had mentors too attached to ideas. We try to go for as many points as we can but sometimes people get attached to cool looking ideas. At some point people need to realize that as a team we will wait her work to get an awesome robot, or fail when trying. We all know that we did the work and can be proud of it. When mentors get too involved we take them back to our original plan and see how what they got sidetracked by relates to the initial plan. If the idea doesn't relate we tell them to hold onto it and we might pursue it later on in the season. If it's an idea a that would help the team we wait a bit to see if it is viable, then present it to the entire team at our mandatory weekly meeting and discuss it for a while.

[The Doctor]

So, to follow up, tonight I called the team to a meeting, reminded everyone that “It’s much better to be quite good at a few things than be relatively poor at many things.”, and assigned everyone to work in a group to work on our pressing concerns. I'd say it worked well, and everyone (including the mentors, who I now believe weren't really at fault in this situation) had something to do, other than play online games...

Here's an excerpt of the speech I prepared, feel free to borrow from it if you are experiencing the same difficulties.

Guys: lets face it. We’re almost halfway through the build season and we don’t have much to show for it. This has been a problem in past years for us, and I was hoping we could resolve it this year, before it’s too late.

First I want to say that in the interest of time, we should scrap the hanging mechanism and front arms. Many folks on chief Delphi agree that we shouldn't still be in the design phase this late in the build season. It's never worked in the past for our team, nor is it particularly promising. In past years, whenever we take this long to complete a robot, we never do very well because we need to spend a bunch of the competition time refining the code and practicing, which means we aren’t on our best at the start.

Why do I think we should scrap these two big ideas right now? A wise man once said, “It’s much better to be quite good at a few things than be relatively poor at many things.” That's why we’re on alliances, so one robot doesn't have to be good at everything. After all, we have a pretty good list of capabilities.

I'd also like to point out that just cause you saw it on robot in three days, doesn't mean it's a good idea. Ri3d teams usually try to bundle as lot if ideas into one bot without refining the design and strategy in order to be effective in competition. If we try to refine all the possible ideas and incorporate them into our strategy, we’ll never get done.

We need to assign a group leader to each category and make sure they get the right about of people to work on their specific job, but we have to make sure that the higher priority jobs get filled first. We should do this at the start of every meeting, to make sure that there are people working on the most important stuff first.

[Collin Stiers]

I think your best bet is to try to have a rational conversation. These mentors may not see your view, but maybe they can, or maybe they can convince you that their current path is best. I find that most problems like this can't be solved with a good honest debate.

There is nothing wrong with mentors trying to prototype their ideas. The problem in your case seems to be that the mentors are pulling students off of (at least in your view) more important jobs. so maybe the best thing to is to have those students return to their job, but have the mentors keep pursuing their own ideas.

My team is almost 100% student lead, to the dismay I think of some of our mentor, but they have discovered a way around that. Every year our mentors have their own ideas, they let us pursue ours, but they also work on theirs a little bit. One of our mentors does this quite substantialy often building a mostly functional robot with his prototypes, however he never interferes with us, only taking students to help him when they don't have other jobs. And that process has been incredibly helpful. I cannot say how many times he has saved us. Often in the middle of the season we will find we have reached an impass, or we are working a dead end. and this mentor will come to us and say. "look guys I think you have a problem here" or " I think the decicion you guys made earlier has lead to a dead end, but in my own work I think I have just the solution for you"

I this way the mentors get to lead the team, not by force, but by merit, because at some point or another, us students are usualy force to admit that their idea/plan is better or smarter than ours, that is why they are mentors after all.

[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