1 - I would reassure them that failure is a completely normal process of learning anything new. We, as humans, are bound to mess up somewhere and it’s completely natural to feel very enraged if something doesn’t end up our way. I would give any anecdotal experiences I have (asking if they are interested) and how I felt in the moment to how I moved on from it. If they are too frustrated to heed any advice I say (or see my words more as a lecture), I will suggest they take a short break to breathe a little. They may not entirely like or understand this outcome, but I would shortly inform them that taking a breather helps refresh their mind. For example, sleep refreshes the body, but to feel that full feeling of refreshment you would need sufficient hours of sleep and other factors. To get refreshment from this case, it would be good to have a snack break, socialize, and even relax for a minute.
*Personal philosophy: Self-care is essential towards any aspect of the self-subsets of the body like self-esteem in this case.
If they start to feel doubtful of their ability to contribute to the team, I would also reassure them that they may not be the only ones feeling like this. I would not ask other students to raise their hands and share experiences (sounds good in theory) because it puts them in a vulnerable position to share potential personal information and could create a conflict of comparison (of experiences, pain, etc). I would explain instances where I felt a sense of imposter syndrome (and quickly explain what imposter syndrome is/encourage them to look up more information if interested). I believe these types of students are just as vulnerable as the students who tend to be upset but are more willing to listen through any sort of outlet as opposed to shutting out. If they do shut out, however, I would focus more on themselves specifically and list achievements they have done with the team. As a mentor, I hope I can celebrate the little successes the team (as a whole) has made. These problems may stem from a student self-comparing themselves to other students (learning is not a linear path for everyone) or not knowing how to properly deal with their anger (with a heavy ambition to succeed).
2 - I would want to understand their perspective of why they thought certain objectives were of higher priority than others. While I (in this case: the technical mentor) would have more concrete infrastructure for what needs to be done first (due to experience from this course), the student can provide a solid argument if their reasoning is based. By based reasoning, I imply proper research (with or without links), a supporting argument with strong evidence, and perhaps experiences they had in the past (with or without FRC competitions). I would encourage team voting (with the majority, if not the whole team) for this case because I shouldn’t be the sole decider for how the robot will be built (despite my position). I believe this would foster a sense of initiative and involvement for those who wish to include changes after the initial student has proposed. I will be the mediator for this situation to make sure it doesn’t turn into an argument-based conversation with the team. I would not throw away the student’s ideas because that would be a form of discarding their innovations and just genuinely making them feel bad. If the idea is not exactly the best out there, I would be more than willing to provide/ask for some assistance first (“Hey, do you want some input that I have to make this idea slightly better?”) and then constructive criticism (“We can work on this specific component first, then lead with your idea with (adjustments), etc.”). By taking this approach, the possibility of the student solely looking at the bad ends of the constructive criticism will diminish. They will also be more likely to answer yes or give some sort of affirmative when asked a question instead of a demand (“Hey, your idea needs some work and here’s how.”).
3 - I will still gather the team around to observe the changes. I will, however, notify them that since we are under a high-stress break time before we set the robot out to compete, I will make some adjustments. I will briefly explain what adjustments I will be making (due to being under a time limit) and explain more about my decisions/adjustments after the competition. This is still very much the team’s robot so the specific components adjusted should be brought to their attention. If any one of the team members wishes to assist me, I will assign them small-risk tasks that won’t have a big impact if not done on time. If they suspect this and show any signs of doubt, I will reassure them that high-stress environments aren’t the best time to experiment and learn. It just creates tension in finishing a task, whether it is familiar or unfamiliar. I would also remind them that troubleshooting with a robot can be unpredictable (as they have already experienced) and not an extremely fast/correct fix even by myself. If my deduction of any one of the students finishing a task in 3 minutes was correct, I would also mention this point in a positive perspective (“I know you all are capable of getting this task done in 3 minutes if time was nice to us”). I would also want to emphasize more on the importance of team effort, as we all play a component in building the robot.
4 - A first (and slightly haphazard) course of action I would take is to go to each group individually and understand their perspectives. I would not try to reach a middle ground with both groups (physically in person) because this can cause arguments/escalations. Some of the main perspectives I wish to get out of both teams are:
- What drew you to this specific group (whether design/building team or shop meeting attendees)?
- How much contribution do you wish to put in (and they can explain why if comfortable)?
- What do you want to get out of this program/specific group they are in?
These questions do not directly imply the group they have tension with, alongside helping me deduce what type of conflict is arising between these groups. It could be a miscommunication issue where someone from the shop meeting group only visits due to curiosity about wanting to join or not (and the other team not knowing). It could be a personality issue of the build/design group judging the other group as unproductive due to their attendance. It can be various other issues not listed here at all (perhaps some unknown to me).
However, there are numerous reasons why this course of action is rather disorganized. In a realistic setting, I will only be mentoring for less than 10 hours a week and will not see the full story of everything. I will only have so little time to connect with the students that my judgment will be very skewed if tension arises. This first course of action creates a biased perspective if I were to try to intervene and reach a middle ground with each group separately.
A better approach to this would be to inform the instructor that I have seen tension rising and go from there. I trust that the instructor has better management of handling these types of situations. If the groups are disruptive to other teams around them, we (myself and the instructor) may have to sit with them to reach a middle ground.
5 - I would applaud the student on their devotion but also remind them that creating the robot is a team effort. I would then like to frame their ambitions as a chance to be a main coordinator/helping hand for the whole team (like a masked hero saving people in the background). If they question why they need to separate their workload from other team members, I will explain that other students will have the opportunity to learn concepts they haven’t seen before through the work they may be doing (and presumably already familiar with). I would also explain that giving up their portion of work is a huge, selfless act to the team members, helping them grow in ways they couldn’t do before. I would imagine they will be frustrated with any outcome of being told their work has to be split up, but I wish to paint them in a positive light of them still being productive. I would explain that their knowledge can help fellow members during the build season, having another role to play besides pure build/design (like one of leadership). I would also give anecdotal advice on how working in real teams doesn’t solely revolve around singular traits (“Any engineer/technician knows how to design and build. A great engineer/technician knows how to simplify and communicate the design/build to anyone.”). I will explain that this new role may be challenging and unfamiliar territory, but will help them greatly in any future career. If the team is sufficient to help, I will make sure to have tasks on hand for them to concentrate on or help develop other skills.
6 - This question is a hard one to answer because it hits me right in my soul of ambition being a double-edged sword. I would applaud the students on their ambition and devotion to wanting to improve the robot, but remind them that the robot is coming along very nicely. I would explain the concept of trade-offs pretty briefly, but use an example of how adding more components to the robot could result in depletion of material or time. This, in turn, would lead to an unfinished robot and we do not wish for that to happen. I would also sit down with the team as a whole and look over what priorities we have (presuming we made them early in the meeting stages). Some of these priorities specified for the robot design can be:
- Make sure we have a fully functional robot before competitions (hopefully furnished).
- The robot plays per the rules and does the appropriate tasks (not all) to score points.
- Has the proper subsystems needed for the robot to function (electrical, mechanical, design, material, etc).
- Much more that could be listed
I would go over the iterations of prototypes I have done with the team and explain how each subsystem came with a trade-off (material gathering to troubleshooting). Unless they come up with a based argument of how a specific component can be implemented under the timeframe we have, I will consider it assuming they are willing to assist me with their endeavors. For now, the current time that I am close to deploying finished subsystems, I will ask the team to assist me on this matter (high priority). I would still take an open approach to encourage their prototyping and design ideas, but let them know there is only so much we can do under a deadline. If we do have time, however, we can start looking at their interests and take in the team’s input (I would mention this as a possibility and motivator).