What would you do when your teammates have some different opinions?
It’s very common question, but in different situations, there’s different answer.
Is there any way of thinking that is more beneficial to this problem?

1 Like

Rap battle? Hot dog eating contest? Shunning? Trial by combat?

Real answer - attempts should be made to understand the position of each party. Figure out where the other side is coming from and figure out why. Sometimes this resolves the conflict. Otherwise, I find bringing data to discussions helps alleviate conflict. When all else fails, bringing in outside folks to the discussion and asking them to help may be useful as well.


First, we need to understand that not everyone is going to agree on everything. What fun would it be to never have anyone critique your ideas?

However, I feel like depending on each situation, different things are necessary to help alleviate conflict. For example, if it’s a small dispute on which button design to use or something, I’d get your leadership team to help them choose because it’s more of a greater good/team decision. But if it’s something more serious like a fight about how someone is behaving inappropriately, that should be handled by a mentor. There are cases where it’s honestly just better if an adult handles it, especially if it’s serious.

I know some teammates may not like each other, they may disagree on things, and that is perfectly ok! In times where those issues occur, remind them of how we are a team, what gracious professionalism means, and how treating each other with empathy helps them and everyone around them happier and less toxic.

FIRST has these great philosophies like Gracious Professionalism and Coopertition for a reason that makes it so unique. Making sure everyone on your team remembers this could help establish an environment where teammates know how to approach conflict in a more open and positive way.

1 Like

The first thing is to hear out the opinions–and NOT criticize differing opinions.

If we’re talking about engineering opinions, the normal method is to talk through the options and pros and cons of each option and opinions. After which, if there’s still no consensus (or there’s even more sharply divided opinion), there’s other methods to come to an agreement–the normal favorite appears to be weighted objective tables, but I’m sure that opinion will be contested by the proponents of “but we VOTE on everything!”.

And I’ll say that I tend to use the “discussion” model at least once a week. And I always start with “I think that’s possible” and follow up with some form of “But how are we going to work with X, Y, and Z issues that I can think of quickly?”

If we’re talking about what might best be called “political opinions” or “personal opinions”–things that aren’t related to engineering–I usually find the best thing is to say that “this is my opinion, yours is different, and I think it’s best that we agree to disagree on this.”

The important thing across both is HOW you approach the discussion–the wrong approach will tend to divide the team worse than not tackling that discussion at all.

1 Like

When you are debating between different design options, there are a few things that can help:

  1. The evaluation should be objective - Develop your objective criteria before you start debating the merits of the design. Common objective measures that are easy to evaluate are cost, weight and size. There are other objective measures that are trickier to evaluate, but should be considered like how much of the teams’s time would be spent building it, how many points of failure it has, the speed of that thing in performing its function (how it contributes to cycle time goals), whether it is something that fits within the team’s experience (i.e we build something similar before). Many teams also apply weighting factors to each of these criteria. Then apply a rank score to each of the various designs and see if there is one that has an obvious advantage over the other.

  2. Evaluate the design, not the person - While each design may have a champion (the person who thought of it, or the person who spent time developing it in CAD), it is important that the evaluation of the design is not an evaluation of the person. This means that a) the person who is the champion should not get too invested in or emotionally attached to their idea and b) the evaluation process should be careful not to use terms like “your design” when referring to each idea.

  3. Recognize the value that the champion brought to the debate - Often times, it is difficult to really evaluate a design until it is reasonably fully developed. This may mean that someone spends a lot of time CADing a design idea that ultimately gets rejected. It is important to make sure that the person who put in all the hard work is recognized for that work even though that work may ultimately end up in the recycle bin. That person likely gained a lot of CAD experience through the process, so ultimately, it was not wasted. But more importantly, they contributed to an ultimately better outcome by being able to present a design that was fully baked that gave everyone a clearer view of the idea so that it could be more fully judged.

  4. Allow impartial parties to help in the evaluation - on our team, one of the roles that the mentors are allowed to participate in is the design review. Our job is to ask questions to a) help the students think of things that they might have overlooked and b) help the students think about and better defend the designs. We like to also give the drive team members an opportunity to provide their input. These students are the ultimate “customer” of the design (as they are the ones who are going to have to make it work on the field). Many times, those drive team members were also working on one or more of the designs, but we ask them to put on their “drive team buttons” and think about the design options in light of the match strategy and to play out a match scenario in their head with each of the options in terms of which one they think will contribute to a winning strategy.

  5. Ultimately, we are a team - We go back to our season goals and give the team a chance to decide which design best contributes to our season goals. The final decision is made by voting as a team if there is no obvious winner from the previous steps in the process.


Strive for consensus all the time. Or have a dictatorship - preferably a dictator that takes everything into account and makes good decisions. One or the other, reducing power struggles is generally a good thing. I’d advocate for consensus, but ymmv

Prototypes are also good data points. I think the common thread here is, everyone has to understand the rules of the system, everyone ideally agrees with the system, and the system works and evolves with those involved.

Is this about your team’s (7636) post event performance evaluation? FRC Science Park Taichung 5G Pilot Regional (2020) - The Blue Alliance

As much as engineers sometimes like to make fun of managers, you’ve hit upon one of the most critical and non-trivial parts of the job role. Handling conflict is a huge skill with lots of nuance.

This more or less hits the nail on the head for me. Step 0 - is the contested subject critical for the team moving forward (ex: should we build a swerve drive or west coast drive)? If so, you have to resolve the conflict. Alternately, if it’s not critical, you have the flexibility to find a way for the difference to exist and the team continue working, well, as a team.

For conflicts that have to be resolved, in a perfectly healthy team, I dislike voting. I prefer concensus. Basically, everyone has to be at least willing to move forward with a decision. Doesn’t mean everyone thinks it’s the best option, doesn’t mean everyone’s hopes and dreams are perfectly satisfied, just means everyone is willing to support the decision and work toward making it the best it can be.

Every team member has a “hold up!” button they can metaphorically press to force the team to stop and discuss something. But, it’s a powerful button, so team members have to be careful when they actually raise an issue.

There are less healthy decision making processes where folks either aren’t willing to ever go along with a decision, or purposefully make decisions without involving the appropriate other folks. In these cases, I tend to say it ceases to be a team decision making problem, and becomes and individual participation issue that has to be addressed with the individual. Talk to them about expectations and try to understand why they are so blocky. At a certain point, it … May … Involve kicking them of the team. But, that’s pretty extreme, and should only be done well after they’ve made it clear they will not participate in the team decision making process.

All this assumes you’ve got at least one person who can be the facilitator of these discussions - coordinate the ideas, and get the concensus. They have to be someone that everyone trusts - that’s more key than someone who is “good” at anything else.

Side note: religion, politics, best food… All these things are definitely worthy of discussion. However, the key is that it’s unlikely you will be able to get everyone on the same page really quickly. This in turn means, there will be at least some time where you have to work together with disagreement on things that are, frankly, important. Sometimes this means concrete guidelines on what’s able to be discussed during team meetings. Sometimes this means team mission and vision statements that clarify how the team treats and handles these issues. Sometimes it means taking a purposeful stand to try to reconcile beliefs. Always, it means listening and understanding others, their points of view, and their biases. It means being willing to work for the good of the team over the good of self.


When it comes to engineering decisions, 6502 has always favored the hackathon strategy. When two different people have an idea for a mechanical system, in order for it to be considered by the team, both get to build their version either on their own or with the help of a small team. Then, the performance of each is quantitatively measured, and the best person wins. This rarely ever actually happens though, as we usually talk through strategies and make a decision as a team first.

1 Like

Depends on the issue – if it’s a technical issue, we usually default to subteam lead or team captain (me!), since experience is usually what’s important here, and try to explain why the decision is being made the way it is. If it’s a team management/structure issue, we usually have really long group meetings until a consensus is reached