How *Not* To Run a Team
Policies that sound great on paper, but play out terribly in real life!
This article is intended to guide and advise newer advisors or coaches on policies that sound awesome on paper but when put in practice, play out terribly for one reason or another. Please heed the warnings in this article and prevent your team from succumbing to the same fate that these real policies have had on certain teams.
All if not most of these policies have been tried on a team in Southern California, and if you are a mentor who has implemented these policies we highly encourage a reconsideration of these policies.
Weekly Rotation of Team Roles
Why this sounds great on paper:
Rotating team roles (programming, notebooking, mechanics, etc.) is something that might be very tempting for a mentor to do as on paper. The reasoning behind this policy is that each member gets to touch the robot in various different ways that having one role wouldn't.
Here's an illustration of what this could look like:
| Week | Member 1 | Member 2 | Member 3 | Member 4 | Member 5 |
|---|---|---|---|---|---|
1 | Programmer 1 | Notebooker | Mechanic 1 | Mechanic 2 | Electrical |
2 | Electrical | Programmer 1 | Notebooker | Mechanic 1 | Mechanic 2 |
3 | Mechanic 2 | Electrical | Programmer 1 | Notebooker | Mechanic 1 |
In Practice
Instead of depth in understanding for each role, each member is suddenly lukewarm at each task.
To understand why, let's break down what each member is forced to do:
Only be a certain role the fraction of a time while they are on the team. The amount of time each member is allocated with this role is (1 / N), where N is the number of team members on the team. To illustrate this, let's take a team of 3 people over the course of 4 weeks with the programmer bolded:
| Week | Member 1 | Member 2 | Member 3 |
|---|---|---|---|
1 | Programmer | (some role 1) | (some role 2) |
2 | (some role 1) | Programmer | (some role 1) |
3 | (some role 2) | (some role 1) | Programmer |
4 | Programmer | (some role 2) | (some role 1) |
As demonstrated above, the Member 1 must wait 2 weeks before being the programmer again. On a 6-8 person team, this can be 5-7 weeks. For somebody to stop working on something for a large amount of time like that and then pick it back up much later is incredibly hard, and unrealistic to how an engineering firm would work. We must remember that as mentors and engineers one key tenet of what we do is preparing students for industry and college.
Furthermore, not each member is cut out or willing to do each task. Forcing somebody out of their comfort zone as a coach on a certain task is not ideal nor does it lend to an enjoyable time for either the team member or the team as a whole.
It should also go without saying, having students be lukewarm at each role also reduces the competitiveness of the team as a whole. The separation of responsibilities between team members also becomes blurred when roles are switched regularly, especially at competitions where each team member's role determines what their chaotic day looks like. Switching their set of responsibilities between competitions reduces efficiency in doing these tasks and causes confusion.
What Should Be Done Instead
If your goal is to allow students to switch roles or get a general understanding of different types of engineering disciplines, here are several things that can be done:
Encouraging students to take a different role each season until they find the type of engineering that they prefer.
Having students teach each other, but still have dedicated roles with a separation of responsibilities.
One thing that goes without saying, is that mentors should be encouraging of these roles being developed on each team rather than forcing them unnaturally onto each group.
At the end of the day, when a high school student becomes a university student, they aren't going to be majoring in "General Engineering". Finding a specific discipline within the broad field of engineering and then focus it down even more is invaluable in their high school years for choosing a specific major. By forcing kids to have breadth instead of depth, they are less prepared than their peers who have become incredibly skilled or interested in one specific discipline.
Changing Drivers Every Match
Why this sounds great on paper:
To avoid team drama with drivers, some mentors or team leaders may opt to change their driver every match. The idea behind this is so that every member gets the same amount of time driving and thus nobody is truly the "main person" in the spotlight when they go up and control the robot.
Plus some parental pressure may also influence this change to occur.
In Practice
In both VRC and FRC, a driver on a team ideally has had the most time and effort put into driving the robot outside of the technical aspects of it. This comes down to somebody who has good perception and has gotten a lot of time drive practicing the robot before the competition.
By forcing each team member to rotate the driver each match, the same issue with rotating team roles becomes apparent. Each driver has 1 / Nth (where N is the number of the members on the team) of drive practice in the most ideal situation. In most circumstances, you end up with somebody with no drive practice driving for a qualification match. It goes without saying that this is less competitive than having one person with the entirety of the drive practice time.
This is even more of an issue when it comes to the driver skills challenge, where dedication to practicing a set routine is paramount for success.
What Should Be Done Instead
To address the "fairness" aspect of driving, there should be no glorification of driving the robot. It should be seen as a responsibility that somebody has to take and dedicate many hours to in order to be proficient with the robot. Another thing to mention, is that drivers tend to not be glorified anyways on the field of competition as the centerpieces are the robots.
Driver tryouts and strict regiments for drive practice should be established on each teams to make students empirically pick the right member to drive. This can be done with a pre-established course or skills run and should be done as soon as the robot is fully functional 2-4 weeks in advance to the competition so that enough time is allocated for drive practice.
As mentors, it's also important in this case to have a heart to heart with students that may be upset about not being chosen to drive. Dealing with rejection and decisions that do not align with ones ideals is a fundamental part of an engineer's development.
Keeping the Same Robot Between Seasons
Why this sounds great on paper:
Keeping the same robot between seasons means that disassembly of the robot isn't necessary, and parts can be saved between seasons. It also means that all work (programming and building) the chassis and other subcomponents can be kept between seasons!
In Practice
This is a terrible idea for many reasons, as reality really hits hard against this policy.
For starters, mechanical fatigue and general maintenance tends to get worse the longer you keep a robot around. Shaft collars inserts wear out, screws get loose, and after competitions metal tends to be weaker. For this reason, some teams (time willing) will do rebuilds (not redesigns) between lulls in competitions to prevent mechanical wear and tear becoming a major issue.
Another issue is the fact that chassis design year to year may vary greatly. Different games may have different obstacles and hazards for robots to climb or navigate across.
Here are a couple of examples:
Even if the games might be similar enough, the tolerances, foundations, and mounting points for different subsystems between games are crucial for success in robotics. To modify an existing design with intended features will always be harder and less competitively effective than building a purpose made design from the ground up. This also robs a learning opportunity from newer team members who do not have the chance to build a chassis from the ground up that year.
"The Adult is Always Right"
Why this sounds great on paper:
As an adult mentor or coach, you're always right! Especially if you have an engineering degree. Besides, the kids are there to learn from you and your hard dedicated time. Therefore, you should always have the final say.
In Practice
As a mentor, the most ideal situation is to form comradery and trust between you and your students. Talking down to students does not do anything constructive and only creates animosity that can't be solved in the short term unless there is a massive change in behavior.
If anything, students are even less likely to be willing to try new things or be open ears to new ideas due to the animosity.
By shutting down short term discourse, you are killing long term relations and good will. Maintaining good relations with current members means willing alumni who are willing to come back to mentor and/or donate.
What Should Be Done Instead
Effective mentorship can be achieved by promoting a collaborative environment where students feel valued and respected. It is paramount to foster an atmosphere where students feel comfortable sharing their thoughts and ideas without fear of judgment by legitimately considering their ideas instead of becoming defensive from the get-go just because there is opposition to your idea.
That being said, the kids aren't perfect. There is a balance to reach with talking down on them and being too passive, especially because mentors aren't perfect either.
Banning Alumni Mentoring and Visits
Why this sounds great on paper:
Alumni come into the classroom and socialize with students too much, it's annoying and sometimes they seem to reduce the amount of time students are spending working on their robots by conversing and talking with them. Therefore, banning the alumni (who are adults and probably should have something better to do anyways?) is a necessary step to ensure that students stay concentrated on their robotics.
Another issue is that we don't want current team members going off and mentoring other teams, they are wasting valuable time doing that and might be taking their parts. Let's just ban current team members from doing that too.
In Practice
While it's reasonable to tell alumni to visit less if their visits become too frequent (or ban certain ones for professional or safety reasons), banning alumni as a whole from visiting is a net detriment to an organization, both middle and high school.
Each alumni, no matter how many years detached being willing to either mentor, donate, or talk to children can be an asset to the organization. Showing current students how current activities on the team can lead to life changing results and entire careers can be incredibly motivating and insightful for the tumultuous years of college and beyond that are just ahead of them. As long as their technical insight and mentoring are within "student-centric" bounds, this insight is invaluable for students.
What Should Be Done Instead
Rather than outright banning alumni, a structured alumni visitation schedule should be implemented. This allows alumni to share their experiences and expertise in a controlled manner that minimizes disruption. Set specific times for alumni to engage with students, ensuring these sessions are focused on mentorship and learning.
At the end of the day, clear cut and respectful communication for what is expected of the alumni is important for maintaining good relations and allowing those who want to visit do it in a healthy manner. Expectations should be set outright and be flexible for those wanting to help and visit.
The same applies to team members who want to go off and mentor younger students. This is not only invaluable for students who might join your organization later, but also the students who do go and serve to mentor. Nothing reinforces knowledge as much as teaching said knowledge. Furthermore, the reputation of a team is tightly coupled with their outreach activity.
By having team members who are willing to go out and mentor, this creates a general sense of positivity towards a team at competitions which may come in handy during alliance selections or judging. In fact, most coaches have to go out of their way to convince students to go out and mentor other teams or do other forms of outreach.
Indicators that Policy is an Issue
The biggest indicator of a policy being an issue is a sizeable amount of students going off to form or join private teams at the end of a season, especially if you are a public school team.
In essence, quitting members of a public school team are saying: "We would rather take a substantial financial burden than stay on the a public school team that is cheaper year to year".
Other indicators may be students not wanting to talk with a mentor and being overly rebellious.
Teams Contributed to this Article:
BLRS (Purdue SIGBots)
Last updated
