HELP. Team's Decision Making Process

[kht5586]

Hello,

I am a second year member of Team 5586, The Bond Brigade. Last year we were rookie all-stars out of the Wisconsin regional, and we were division finalists/rookie all-stars from Curie division.

This year, we began our design process alright, but soon, it became bogged down with unnecessary politics and arguments (Of which I was a large part). Most of the team wants to go with either a "Assist Bot" or Defense Breaker. I feel like the team just doesn't realize that we have the capabilities to build a strong competing robot and just wants to rely on getting picked for making someone else more efficient, rather than for being able to score on our own.

After doing some math, the breaker was given a score of 61, the shooter was given a 41, and the assist bot got a 60. Then a member of our team called for a vote between the breaker and assist bot, and it went 6/8.

I just felt like the team was doubting that we could actually go back to worlds off of a good robot and that they thought we HAD to rely on a "better" team picking us. They want to shoot low, while I feel like we should shoot high. People have lost track of the fact that "Design is not a democracy, the best ideas are not often the most popular".

Any advice would be welcome.

[MrForbes]

How much effort would it take to build a robot that is capable of both the breaker and assist roles?

It could be that you are wasting time by thinking that it's an "either/or" situation.

edit: I'm glad to see that your numbers show that shooting is overrated...that's my gut feeling this year.

[Kyle Heaton]

Sometimes it may seem like the team doesn't know what it is doing, but you have to trust them.

The season will strain the team, and if everyone isn't all in of the same design, then the team won't do well.

Personally, I would suggest that the team reconsider their options(We are still only at the start of Week 1 of Build), decide if this is: What they want to do, and what they think will win.

At the end of the day, it is a team effort, and if the team wants a defense breaker bot, then the team needs to all agree that this is the course of action you will take, and that everyone needs to be 100% into the idea.

[Anthony Galea]

Isn't it true that if you won Rookie All-Star at the championship, you get to go back next year?

[kht5586]

Originally Posted by 3175student17

Isn't it true that if you won Rookie All-Star at the championship, you get to go back next year?

I don't believe so, I know you get to go back every year if you are a chairman's winner at worlds.

[lark95]

Originally Posted by MrForbes

How much effort would it take to build a robot that is capable of both the breaker and assist roles?

It could be that you are wasting time by thinking that it's an "either/or" situation.

I would strongly consider the possibility of performing more than one role. If all goes well then you will have a very capable robot. However if later in the season you realize that you can only complete one role or only need one role then you can pick the better of the two, instead of choosing one now and finding it was the wrong choice.

[Jon Stratis]

We had a similar divide my team's second year. After seeing a competition and seeing how advanced some of the robots are, it can be intimidating the next season. We solved the problem by coming up with an iterative design- we had a design that could quickly and easily be stopped at multiple points and compete as is, with each additional stage adding capabilities towards that "do everything" robot half the team was afraid to attempt. In the end, we got it all done, were alliance captain's, and finalists at the Minneapolis regional (in fact, our robot out-scored any other individual robot on the field in the finals, we just couldn't quite get enough as an alliance for the win).

[Kevin Sevcik]

On the other hand, there's something to be said for knowing your limits. This year is going to be especially rough on teams that bite off more than they can chew. Having two robots or finishing early is going to be important so you can get that critical driving practice of traversing your chosen defenses. If you finish your high-goal shooter on stop-build and you don''t have any driving practice, you're going to get smoked by low-goal robots that finished early and have been on the sticks for several hours already.

[bEdhEd]

Have you considered using weighted objective tables?

Our team actually has an opposite "problem." EVERYONE is on board with the same idea, but our mentors have to play devil's advocate and propose opposing ideas for the sake of the team not losing sight of the advantages of other designs and getting tunnel vision. We don't want to end up so fixed on a bad idea that it would be too late to change plans during the build season if we find out that our tests show less than stellar results.

[rich2202]

Design with flexibility in mind, and prototype.

For each design assist, defense, breaker, figure out what attributes you will need.

The drive train of a defending bot can be much different from a breaching bot. High mobility is what you want for a defending bot. Tank treads, or something similar, is what you need for a breaching bot.

Shooter can be put on either bot.

A defending and assist bot can be very similar. A lot bot (get under low bar) can both defend and assist.

Right now (the next few days), we are focused on what is needed for various capabilities, and let people go prototype what they want. After prototyping, then you figure out what you have, and what you can combine into a robot.

[MrJohnston]

The way I see it, winning alliances will need to have both shooting and defense breaking abilities... It is also possible that a bot that specializes in gathering balls and delivering them to allies in the courtyard will have a place.

In other words, your team can be successful with either primary focus (shooting v. damaging defenses). As others have suggested already, stronger teams will have secondary and tertiary purposes so that their bots can better adapt to different alliance team members and ever-improving understanding of the game play.

So, your team has not made a "poor"choice by any stretch - nor is there anything wrong with your suggested strategic approach. Instead, this is something that our (really large) team often struggles with: How do you make a decision (despite the fact that it will not be unanimous) and still move forward? There are two keys, I believe: 1) Before starting any discussions, there needs to be an agreed-upon process in place for making a decision. Many different models will work for this, but the key thing is to have something in place that ensures that a decision will be made. and 2) Everybody on the team must be ready to abide by and support the decision, whatever it is.

So, I would suggest, that if your team followed a set process - but you disagree with the final decision - that you recognize that the team is going in a different direction and your place is to support the decision to make it as successful as possible. It could be that you recognize needs for the game that go beyond your team's current thinking. If this is the case, looking for ways, in the design process, to suggest your ideas as additional functions - but never in such a way that it would undermine the direction that the team is going.

[philso]

I would second Frank's advice to use weighted objective tables for situations like this. My son teaches this to the more advanced FLL teams he coaches and mentors.

I would also strongly advise against voting. Voting is good if every participant is truly making their own decisions, independent of how everyone else votes. Often, people are voting for what their friends chose rather than evaluating the facts and making their own decision.

[ToddF]

Originally Posted by kht5586

I just felt like the team was doubting that we could actually go back to worlds off of a good robot and that they thought we HAD to rely on a "better" team picking us. They want to shoot low, while I feel like we should shoot high. People have lost track of the fact that "Design is not a democracy, the best ideas are not often the most popular".

Any advice would be welcome.

Your most valuable resource during build season is time. Because time is finite, you must prioritize robot functions by point power. I would suggest that you take an evolutionary approach. Your ball scoring mechanism subteam first gets a working low goal shooter, then works on scoring high goals. The one that goes on your robot is the one that is more reliable on bag day. At your second competition (if you have one) swap out the first mechanism for the second one, if you have perfected it after your first competition.

So, you don't choose one or the other. You choose the higher priority to do first, then work on the next higher priority. The more time you invest, the further down the list you will make it. Even last year, having won both of our regionals, we did not complete everything on our list of priorities. But, we did complete the highest priorities.

In almost every game, you will find that incrementally adding features to your robot will result in more and more effort expended for less and less value (measured in points). The key is to recognize which features are the most valuable and prioritize those tasks the highest.

[lark95]

Originally Posted by philso

I would also strongly advise against voting. Voting is good if every participant is truly making their own decisions, independent of how everyone else votes. Often, people are voting for what their friends chose rather than evaluating the facts and making their own decision.

This is very good advice. Not every member a team has the same experience or knowledge level. On our team all of the major decisions may be discussed by the whole team but the final decision is up to the team captains and a few very good SME's. The captains are also the ones responsible for a bad decision. This helps to keep them on track and focused on what is best for the team not just what they might want.

As a team captain myself i feel that this works very well.

[pntbll1313]

JVN has a great outlook on this.

Originally Posted by JVN

Voting is not an engineering process. We will never vote on a design.

Voting isn't a logical choice. You should be weighing the pros and cons of each decision. Someone with experience should be leading this discussion. Hopefully you can find tools to help you weigh the costs/benefits of each decision you are making so that you can arrive at the best decision. Make sure to factor in your resource limitations when you do this!