Team Argument!

[EricH]

I have some points to bring up, and I'm not quite sure you'll like them.

1) If there is a sensitive issue on a team, we do have an "anonymous" forum. I'm not sure this doesn't belong in there, I'm not sure it does. I'm just saying. (You may need to use it eventually...)

2) Both of you are right. The mentor is right because it's not about winning. It is about a group taking a project that they all agreed on and worked on to competition and learning along the way. He's also right--to a point-- that in industry, you do things the best way.

However, you are more right. In industry, you do things the best way that is available. Friction stir welding may be the best way to do X, but most shops don't have the equipment, meaning that it's not the best way until you get the equipment (which is kind of expensive). And, after a design is approved, you don't change it unless of necessity most dire.

3) The team, not the leader, chose the design. He's miffed, and develops his own design. This is not good! Most teams, when a design is chosen by the team, lock the design. It's not open to change, unless something really needs to change. You, as a team, need to talk to this mentor and tell him that he's acting like a child. (Not in so many words, of course, but that is what he is acting like from your description.) In other words, take the blow to your personal pride and live with the group's decision.

4) Your other option is to force his hand. Get working versions of both NOW. I mean ASAP. Test them against each other on a certain day, say Saturday (Sunday at the latest), no exceptions or excuses. If one doesn't show up, the other wins by default. Winner take all. After build season is NOT the time to make a major change!

5) You ask about what other teams do with parallel designs. Here's what my old team does: We don't cut metal until we know what we're doing. If two designs serve the same function, we try to have space for both. At some reasonable time, we test all competing designs. The best one for our purposes wins out. We throw all other ideas into mental hoppers--if a design might not work, a "tiger team" figures out a backup plan.

I do know that at a couple of points, designs were tested late in the season against each other with no ill effects--one due to allowance being made already, the other due to being reasonably interchangeable on short notice.

To sum up, if you're going to revisit your decision, do it now. If not, tell him flat out. Everyone has to make sacrifices, including him. If that includes giving up his design, so be it.

[smurfgirl]

Originally Posted by dmoody92

I raised my hand and voiced my opinion that if we decide to pick the Auger that everyone who didn't work on the team would feel totally alienated because they had no help in making it. I said that I would rather lose miserbly with the bot I made, then win it all with a bot I had no help on.

I didn't make this just to air out dirty laundry and for you guys to back me up. I want to know how you guys handle back up ideas, do you just pick an idea and go with it or do you make two robots and pick the best one. Another big issue with this is that they have split our total funds between these two robots. What do you guys think?

[Edit] Now that I see this post, it's really long and intimidating looking. I'm really, really sorry about that- I have a tendency to spew out a lot more words than I expect.[/Edit]


These two thoughts both show a very high level of maturity and understanding. I applaud you for that, and I hope you can continue to voice your concerns reasonably to your team- you have a lot of good insight.

While I think your team probably should have addressed these concerns when it formed and at the beginning on the build season, it is definitely better to deal with them now than to let the repercussions of the disagreements manifest further and cause excess turmoil. You don't want that kind of tension to stay in your team for long. You should have a team meeting, and discuss the concern you have brought up in the first paragraph I highlighted in the above quote. Teamwork is important- you have to have your whole team in this together. If your team made a decision as a team, your team should honor that and move forward together, even if individuals think there is potential in other options. (I bolded "as a team" because that statement is very important- if the decision did not involve the whole team, then that's the step where you have to rethink things. Those who were left out of the decision-making process are going to feel the same way you do now.)

The fact that it is your lead mentor who lead the rebellion group is also important. Our mentors have much more engineering experience than us, and a lot of insight from their experiences throughout life. They might see an idea that they believe is the optimal solution, and it is understandable why they would think it is a good idea to bring the team to work on this. However, there is one flaw with this logic- this is not what FIRST is about. FRC is a program for high school students, designed to inspire and teach many lessons that will apply throughout life. The mentors are there to be that- mentors. While they can help enormously with their knowledge and insight, they should not be taking over the reigns to the extent that they are suffocating the creativity and the learning of the students. Perhaps you need to give a gentle reminder that this experience is designed to let you, the students, flourish through the knowledge you obtain through your hard work- the successes and the failures alike. While the robot design your team voted on may not be "the optimal design" in the eyes of your mentors, it is yours- yours to build as a team, yours to learn from as a team. You are absolutely right that you will get a lot more out of losing with a bot that is truly yours than winning with one that was just handed to you.

To reiterate- you should definitely hold a team meeting where you can voice your concerns and discuss these problems with the team. Make sure it is open to the whole team and you are not excluding people by, say, meeting during volleyball practice when everyone on the "auger" team is also on the volleyball team. Consider holding a special meeting outside of build time and sending everyone an e-mail explaining why it is important that they come. The high-energy, high-stress period of the build season can be really frustrating, so remember to remain calm and explain everything rationally during the meeting- your goal is to resolve conflict, not to create more of it.

Also, now that I have explained all of this, I realize I never directly answered your final questions. Ultimately, it makes sense to pick one design and go with it. Building multiple prototypes in the early stages (weeks 1&2) is a good idea to decide what to go with, but like you said, building two full robots is a waste of time and money, and will split your team in half. You should definitely decide on one idea early on and go with it, with your whole team as one. Anyway, good luck!

[Stuart]

Originally Posted by Molten

Ok, let's go with the business analogy:

Ok, there is a need for a new part. Team gets together and discusses ideas. They narrow it down to two. They decide to go with one idea for whatever reason. One of the employees who didn't get their idea picked, decides to go ahead with his design. He steals a couple of people from the group to move it forward. He takes money from the mainstream plan to fund his design. The two designs are finished about the same time and are put to the test. There is a possibility of two outcomes:

1. The individuals idea is indeed better. The team goes with this idea. However, when the boss goes to review the design, he notices what the individual has done. The employee has undermined the team by taking funds and distracting co-workers. That employee is on the fast track to getting fired.

2. The individuals idea is actually worse. The team goes with the mainstream idea. The boss sees what the individual has done. Wasted time and money on something that is an inferior product. This gets him fired.

Notice a link between the two outcomes? In both, regardless of which design they go with, the person who goes against the team's best interest is usually fired. Regardless of whether or not they was right. Something to consider for next year. After the stunt that mentor pulled, I'd see about getting him removed from the team. Take these scenarios to the student team leader. See what he has to say.

hmm some times true other times not so much. I always tell my students to follow their gut and speak their mind. There is a difference between a "team player" and a yes man.

As far as the situation at hand. you need to ask your self " what do you want". What is worth more this mentor, or your pride( or your mentors pride or your teams sense of self). if what you want is the best winning robot ever then by all means have the test( but please have each team test and present the others work . . don't have 1 testing team, I have never had a "fair" result come from 1 testing team). If what you want is an organization that puts the team before the robot than I suggest that you and your team leadership sit down with the mentor and his team and work something out( you will have to lose something when you do this).

what ever the decision you make you need to do it with haste in mind. Design changes( and indecisions) at this stage in the game are too costly

[xitaqua]

Hello All,

As a mentor, I would like to reach out to all the mentors reading this thread :

Remember what it meant to be a mentor to you before the season started.

If the reason that you volunteered to be a mentor is so you can build a robot, you probably joined the team for the wrong reason in my opinion. As an adult you have plenty of opportunities to see "your design" realized. Give this opportunity to the students.

A mentor is someone that guides the team, for you to be a guide you need to be an honest broker. It is like when you are a foreign country and you hire a "guide", that individual will provide you ideas of what to see and what to do, but in the end is you that make a decision. A guide shows the path, leads in the path, but doesn't drag others along.

I am aware of what my team picked for their robot design, I am also fully aware what other teams picked for their designs. I will say this, the team that will win this competition, is the team that will be able to compete next year, and the next year, and the next year, and the next year.....and ever.

I really don't care about the robot design.

It is not about who has the best design, it is about who has a team that will go on, go on even if they loose their Mentor. Or if their Coach quits because she is overwhelmed. The main sponsor drop out and you are out of $6,000.

Those are the winners.

Cheers,
Marcos.

[dmoody92]

Thank you all for your input. I'm going to talk to our student team leader and try to have a meeting with them.

I know that we should have put an end to this earlier but the thing was, at first it was really small and he said that this would be totally non-intrusive to the main design, it would be worked on outside of our build time and would only be used if our initial design totally didn't work. Since some time has passed and they had a little more progress to the design, his demeanor totally changed and went to this test.

Honestly, there is no way they could get it up and running in the next few days. All they have is a frame with two wheels, and the big worm gear that will be the auger, but there is no electronic integration at all, and no program. Our programming team consist of two people, myself and another kid (who frankly has no idea how Lab View works yet). It's hard enough for me to not knowing what lab view was before the build season, but to make two fully functioning robots is just impossible for me, and I am not going to make two very weak programs just so that they both have something.

[Rick TYler]

Originally Posted by Molten

1. The individuals idea is indeed better. The team goes with this idea. However, when the boss goes to review the design, he notices what the individual has done. The employee has undermined the team by taking funds and distracting co-workers. That employee is on the fast track to getting fired.

Congratulations, you just fired the inventor of Post-Its. (Not exactly, of course, but pretty close.)

It's not that easy in business, but the analogy is flawed. A robotics team is always under an artificial brutal time limit and can't make nuanced decisions. In developing new products in business, we hedge these kinds of bets all the time. There is some need to focus, but having a small team checking out the road not followed can be an effective strategy. On a robot team, this is always a bad idea.

The other part of the analogy that doesn't work is that in business the result is more important than the process. I've worked with product teams (new product development is what I do for a living) that all hated each other, and I've worked with teams that were practically mutual-appreciation societies. Some teams were more dysfunctional than a family on Jerry Springer and others practically sang Kumbaya every day. The teams that follow bad process and don't make the best of all team members sometimes make great products, and the happy cooperative teams sometimes stink. All else being equal, I'd rather work with the "nice" team, but I'd take bad process that makes good product any day over the reverse.

Having a mentor and a small team building plan B is distracting, but not fatal, if you can afford the parts and time. I have some sympathy with your mentor's position. Three times I've been on a development team that was racing towards a bad solution and being unable to stop the race were some of my worst experiences. Just because you are the majority doesn't mean you are right. Just because your mentor is in the minority doesn't mean he's right, either.

The thing that will save you (probably) is that there are usually lots of ways to make pretty good robots. There are even more than a few ways of making really good robots. It's not the approach, usually, it's how well it's executed.

It's important for students to remember that mentors go through learning just like the students. One of my most important jobs as lead mentor for my FTC and VRC teams (we have seven robots) is recruiting and training new mentors. It's much harder to bring in new mentors than new students. I have this little speech in my mind that I never deliver because it's impolite, but I'll share it with you because you are all my friends:

"I'm the lead mentor of this team. I am not a professional engineer. I have, however, been involved in writing software, designing products and running projects for 25 years. You are better at mechanical, electrical or <whatever> engineering than I am, but I know that I'm better at mentoring students through this process than you are. This is now my fifth year doing this and it's your first. If you won't follow my lead, I encourage you to leave now."

I seem to be drifting...

For what it's worth, I wouldn't have let a rookie team decide on an engineering approach. I would have walked the students through the process and then led them to the right choice. Learning the process is key, and the results don't really matter, so (as a mentor) I might as well lead our students to a workable strategy. If your lead mentor was on one side of the argument and the students were on the other, there's a pretty fair chance that the mentor is the one who is right.

Here's another bit of philosophy for you all: my job as a mentor is to get 1) a working robot, with 2) prepared students, to 3) a robotics tournament. Letting students on an FRC team violate rule #1 means I have failed as a mentor, and I am fully willing to override any sort of "vote" to lead my team into a successful year. This is NOT what I do with my experienced students. By their third year, they are clearly able to build robots with little or no input from mentors, and that's fine with me. It gives me more time to build my hobby robots while they work on competition robots. (This is a lot easier with Vex robots than in FRC. I love Vex.)

Good luck. Focus on what you can learn from this experience, and not on a sense that someone is treating you unfairly. I can tell you for sure that being treated fairly is not universal in business!

[synth3tk]

Originally Posted by dmoody92

Honestly, there is no way they could get it up and running in the next few days. All they have is a frame with two wheels, and the big worm gear that will be the auger, but there is no electronic integration at all, and no program. Our programming team consist of two people, myself and another kid (who frankly has no idea how Lab View works yet). It's hard enough for me to not knowing what lab view was before the build season, but to make two fully functioning robots is just impossible for me, and I am not going to make two very weak programs just so that they both have something.

Then as Lead Programmer, I suggest that you focus on your "main" (team-designed) robot, and kindly (KINDLY) remind him why he's here, and what he has to sacrifice for the sake of the team. As stated above, he is there to guide you, and not only has he been a hypocrite, but he's going against what he's ultimately there for, which is inspiring you, the students.

[Andrew Schreiber]

Originally Posted by dmoody92

Thank you all for your input. I'm going to talk to our student team leader and try to have a meeting with them.

I know that we should have put an end to this earlier but the thing was, at first it was really small and he said that this would be totally non-intrusive to the main design, it would be worked on outside of our build time and would only be used if our initial design totally didn't work. Since some time has passed and they had a little more progress to the design, his demeanor totally changed and went to this test.

Honestly, there is no way they could get it up and running in the next few days. All they have is a frame with two wheels, and the big worm gear that will be the auger, but there is no electronic integration at all, and no program. Our programming team consist of two people, myself and another kid (who frankly has no idea how Lab View works yet). It's hard enough for me to not knowing what lab view was before the build season, but to make two fully functioning robots is just impossible for me, and I am not going to make two very weak programs just so that they both have something.

Just for the sake of playing devils advocate on this whole thing, I do not know what your sponsorship position is but generally schools and sponsors want winning teams. Face it, shiny trophies make people happy (I know it makes me happy but I am amused by simple things like that). Your mentor may be under pressure from sponsors or the school. I believe that airing your dirty laundry in a public forum was not the proper move. If you feel you really need to I would use the Anonymous board here. Remember, every post you make reflects on you, your team, your school, and your sponsors. I am not saying this reflects badly merely reminding you of the implications of posting.

That being said...

Some teams are genuinely all about teaching and student involvement, some are more about winning. Having participated on teams that are about as drastically opposite as you can get (397 and 27) I can tell you that both ways have their merits and their demerits. Your team needs to decide what it wants to be, how important is winning? Is it more important than having the kids really love doing it? Can you do both? These are things that need to be decided. How does this solve your problem? If you want your students to feel involved and inspired by what THEY can do then you need to talk to your mentor and tell him that you guys feel passionate about your design, you worked very hard and feel that it should be given a fair shot instead of being crippled by dividing your efforts. If you decide winning is more important (nothing wrong with this thinking) then you do need to test both designs NOW. Not next week, not after build season, you need to test NOW. Testing doesnt mean having code, testing means manually driving the thing with a drill if you have to.

Also, if you need help feel free to PM me about the programming, Im not the best on here by any means but I am willing to try to help.

Best of Luck, I hope to hear wonderful things about your team in the future.

[Rick TYler]

Another general comment -- these sorts of approach disagreements can frequently be solved within two weeks by building prototypes. When I did FRC we went through a lot of plywood, 2x4s, PVC pipe, and cordless drills (they make great temporary power sources) in prototyping. With FTC and VRC we just use the parts slobbed together to demonstrate approaches. You can usually lock in an approach after the prototyping, especially if the team members can agree in advance to accept the results of the prototype "shoot-out" and that there are agreed-upon analysis criteria.

Good luck.

[RogerR]

Originally Posted by dmoody92

...I said that I would rather lose miserbly with the bot I made, then win it all with a bot I had no help on...

There are quite a few other more significant factors that others have already spoken to, but this was something I feel very strongly should be pointed out. One of the first things I learned when I left college, and moved into the profesional engineering feild:

There is no pride in authorship.

When personal pride becomes part of the decision making process, problems arise. Most of the posts like this that are posted on this forum seem to be caused by this situation.

Its week 5, so it sounds like the ship has already sailed for your mentors design; but if you are going to do a side by side comparison, I would suggest that you work to the best of your abilities to optimize both designs, so that the best one (as decided by some quantitative measure) is shipped, not the one that got all the time and effort just because you liked it more than the other. Have your mentor's group help to perfect the wheel as rapidly as possible, and your large group the auger. I can almost guarantee that the mentor will go with the winning design, regardless of which it is. I can give you the same odds that there will be hurt feelings if his group feels that you're working to sabotage their design.

Whatever you choose to do, do not allow this to become personal. This cannot become a fight over 'your' design or 'his' design, because no matter who thought of what parts, the robot that ships in 12 days belongs to your team, for better or for worse.

*edit* heed Rick Tyler's words, as he made a lot of good points

[RyanN]

First off, I'm tired and did not read through the thread fully. I'm also going to try to keep this short and simple.

From what I understand, you have an auger sitting at robotics waiting for programming and to be mounted, right?

What about your other idea? Is it sitting there waiting to be put on? I haven't heard you mention this at all?

I know when I design a robot, and my idea is not implemented, I feel bad, but I don't make a big argument over it. I go with the what the rest of the team wants.

I understand that your team doesn't want to go this approach though...

Whether or not your team wants to go with the auger design, you guys need to come up with a decision fast. Time is running out. Everything needs to start coming together now. If the other design has not been started yet, you should probably dump the idea. Give the programming team a few days to get something working. Make the robot aesthetically pleasing. Make sure it's wired up properly.

Fighting over a major design of your robot this late in the season is a big 'no no.'

I know if I had a working design sitting in front of me right now, I would definitely consider it.

My 2 cents.

[Molten]

Ok, two people made comments disagreeing with my previous post. One mentioned Apple, the other mentioned Post-its. I'm not going to pretend to be knowledgeable of Apple, though I see no story to connect those dots. Post-its, however has nothing to do with this scenario. Read up on how they were made and they don't apply to this at all.

That said.

As I've read your posts, I've noticed that you are completely dedicated to your team. You seem to believe that your mentor should take one for the team. I agree. However, If he won't...maybe you should. Seems like his design has a lot of work and could still have a lot of learning opportunities. Maybe, going with his idea now and involving the entire team with his design would allow you to get a robot done while the students could all take part. Next year, I would see about getting rid of him. But for now, you must deal with it.

Also, When I read a thread like this, I make a point not to read what team posted. This is for a simple reason, it doesn't matter who posted it. Leave the team's public image out of it and give him your advice.

A note to Rick TYler: When it comes to designs, there is no right or wrong. There is what will work and what won't. I agree that the mentor's design has a slightly better edge at working. However, with that said, if both ideas work...either is as good as the next. And that is when majority rules.

[EricH]

Originally Posted by RyanN

From what I understand, you have an auger sitting at robotics waiting for programming and to be mounted, right?

What about your other idea? Is it sitting there waiting to be put on? I haven't heard you mention this at all?
[...]
Whether or not your team wants to go with the auger design, you guys need to come up with a decision fast. Time is running out. Everything needs to start coming together now. If the other design has not been started yet, you should probably dump the idea. Give the programming team a few days to get something working. Make the robot aesthetically pleasing. Make sure it's wired up properly.

Fighting over a major design of your robot this late in the season is a big 'no no.'

I know if I had a working design sitting in front of me right now, I would definitely consider it.

My 2 cents.

The way it actually works (as I understand it) is that they have 2 designs proceeding independently of each other. The team-chosen and team-built design is dubbed the "wheel". The other design, the "auger", is being built by what could best be termed a "splinter team" or small group that doesn't like the majority decision.

I'm not sure which one works. It is known that the auger isn't operational yet. We haven't been told the status of the wheel at this time. We do know that the OP doesn't want to start work on code for the auger, at least until the design is chosen by the rest of the team.

At this point, with a fuller understanding, but not complete, here is my advice to the OP: You have a choice: give the splinter group a chance or not. They have become resistant to your requests for help, and are apparently trying to build a second robot. Things are getting worse rather than better.

So, my advice is: Make your choice. One choice is to shut down the splinter team. I don't like to do this, but sometimes, it must be done. The other choice, and the one I would choose, is to hold a challenge. Both teams produce their product. Give about a 1-2 day warning. Establish a set of criteria, to determine which is better. Substitute human actuation when necessary to replace a motor. The better design, as shown by the criteria, will go on the robot. Some sample criteria:
-feed rate
-finishability--can it be completed by ship?
-jamming, or lack thereof
-ease of integration
-fill in the blank here--you may have other ideas. Leave out number of people working on the project, though.

Make sure that the entire team knows what the criteria are and has a chance to see them. The best option would be to make them beforehand, along with a note about automatic choosing under cases of no-shows or possibly pressuring one way or the other. Majority wins, and the better design is built by the entire team.

After that, if you still have a splinter team working on a concept that the team doesn't support, they need to wrap it up immediately or leave the team to do it.

This method will give the splinter team a chance to show what they can really do. It will also give you a chance to convince them. Two designs at this time just is not good, and this would be the absolute final choice.

[dmoody92]

Ok, for the wheel, we currently have the "wheel" operational on a drive base that is motorized, with the eletronics mounted and a completed harvester. We are going to build a conveyor on the top and that is the last thing we have to do. The is auger team is much farther behind.

Also, it's not like we haven't made a choice. We have repeatedly told his team to stop working on it because we wouldn't have enough time to make and implement a back up plan. They decide that they have enough time and money that they can do this on their own, but now the mentor is trying to get more people for the cause...

[Betty_Krocker]

Ok, being a part of both types of groups, here is my insight:

A splinter group is usually driven by pride in one design. This happened to my team last year. The 4 most experienced students we had (myself included) wanted a shooter design. We KNEW this could be done and built in time and work. Certain people *cough* were in favor of one design which was the design out game mech dept. was forced to build. Being a fabricator myself, I took personal feelings and thoughts aside while I worked to build the team's design. It epic failed, and the shoot was amazing, needless to say those people against the shooter felt really stupid...

That said, being as it is your rookie year and you are the lead programmer, you need to RELAX not to say that you should stop everything, but as a programmer, the robot depends on you, and you need to not be stressed...

Whatever robot you ship, no matter how it turns out, you will have a killer time at Competition...
If you need help there, people will be more than willing to help so in the end you will be fine...

Like everyone else I am drifting...

So what to do now? Well you guys need to patch up the rift. Untied we build robots, divided we end the team (extremes but true)

Finally just remember "DON'T PANIC"