LogoLogo
  • Welcome!
  • Mission Statement
  • Contributing Guidelines
    • Embed CADs in Wiki Articles
  • VEX Worlds Livestream Archive
    • VEX U
    • V5RC High School
    • V5RC Middle School
    • VIQRC Middle School
    • VIQRC Elementary School
    • JROTC
  • ⚙️Hardware
    • Design Fundamentals
      • Gear Ratios
      • Internal Forces (Stress)
      • Torque
      • RPM
      • Center of Mass
    • Introduction to VEX Parts
      • Structure
        • C-Channels and Angles
        • Fasteners
        • Retainers
        • Gussets and Brackets
        • Bearings
        • Plate Metal and Flat Bars
      • Motion
        • High Strength Components
        • Gears and Sprockets
        • Traction Wheels
        • Mecanum Wheels
        • Omnidirectional Wheels
        • Flex Wheels
    • Robot Decorations
      • Part Dyeing
      • Metal Coloring
      • License Plate Holders
    • Lifts
      • Double Reverse Four Bar (DR4B or RD4B)
      • Four Bar
      • Scissor Lift
      • Six Bar
      • Other Lifts
      • Best Practices
    • Shooting Mechanisms
      • Catapult
      • Flywheel
      • Linear Puncher
    • Drivetrains
      • Tank Drive
      • Mecanum Drive
      • Holonomic Drive
      • Designing a Drivetrain
      • Best Practices
    • Pivots & Joints
    • Pneumatics
      • Best Practices - Pneumatics
    • Intakes
    • Flip Out Mechanisms
    • Defensive Mechanisms
    • Misc. Building Techniques
    • VexU
      • Common Manufacturing Techniques
        • 3D Printing
        • Laser Cutting
      • Custom Manufactured Parts Library
      • Commercial Off The Shelf Parts Library
  • 👑Team Administration
    • New Team Resources
      • Creating The Team
      • Gaining Interest for Robotics Teams
      • Attending Competitions
        • Elimination Bracket
    • Team Dynamics
      • Organization Structure and Longevity
      • Member Allocation and Management
      • How *Not* To Run a Team
    • Team Finances
      • One-Year Team Financial Breakdown
      • Funding Your Teams
    • Hosting Competitions
      • Live Streaming
      • Tournament Manager
        • Competition Electronics
        • Creating a Tournament
        • Tools
          • Field Set Control
          • Connecting Mobile Devices
          • Connecting Raspberry Pis
        • Match Control
          • Inputting Match Scores
          • Inputting Skills Scores
          • Inputting Scores on TM Mobile
        • Displays
        • Alliance Selection
      • Additional Event Partner Resources
    • VexU Organization Management
      • Getting Started in VexU
      • Team / Personnel Management
      • Volunteering At Local Events
  • 📚The Judging Process
    • The Engineering Design Process
      • Test and Refine
    • The Engineering Notebook
      • Segments of the Notebook
      • BLRS2 '23-'24 Engineering Notebook
      • Integrating Inventor Models into Documentation
      • Engineering Notebook Rubric Breakdown
    • The Interview
      • Interview Rubric Breakdown
    • Using Notion for an Engineering Notebook
      • How to Setup a Notebook
      • How to Create Entries
      • How to Export a Notebook
      • Purdue SIGBots Notion Template
        • Game Analysis
        • Identify The Problem
        • Brainstorm Solution
        • Select Best Approach & Plan
        • Build Log
        • Programming Log
        • Testing Solution
        • Tournament Recap
        • Innovative Feature
  • 🖥️VEX CAD
    • CAD Programs
      • Inventor
      • Fusion 360
      • Solidworks
      • OnShape
      • Protobot
    • Making a Chassis
      • Inventor Chassis: The Basics
        • Installation
        • User Interface Overview
        • Dark Mode
        • Assemblies
        • Placing Parts
        • Navigating CAD
        • Changing Visual Style
        • Grounding
        • Connecting Two C-Channels
        • Modifying Existing Constraints
        • Toggling Visibility on Existing Parts
        • Completing Half of the Chassis
          • Inner Drive Channel
          • Bearing Flats
          • Motors
          • Wheels
          • Sprockets
          • Spacers, Washers and Standoffs
          • Spacers Cont.
        • Creating Mid-Plane
        • Mirroring
      • Inventor Chassis: Best Practices
        • File Structure
        • Subassemblies
        • Wheel Subassembly
        • Origin Planes
        • Cross Brace
        • Drive Channels
        • Simple Motor iMates
        • Replacing Simple Electronics
        • Completing Half of the Drive
          • Bearing Flats (Best Practice)
          • Wheels
          • Powered Gear
          • Spacer Boxing
          • Spacers, Washers and Standoffs (Best Practice)
        • Model Browser Folders
        • Mirroring (Best Practice)
        • Model Browser Folder (Right)
        • Main Assembly
      • Fusion 360 Chassis
      • Solidworks Chassis, Chain, and Custom Plastic
    • Remembering The Best
      • 62A Skyrise
      • 400X Nothing But Net
      • 2587Z Nothing But Net
      • 365X Starstruck
      • 62A In The Zone
      • 202Z In The Zone
      • 5225A In The Zone
      • 169A Turning Point
      • 929U Turning Point
      • 7K Tower Takeover
      • 5225A Tower Takeover
      • 62A Change Up
    • Scuff Controller
  • 💻Software
    • Odometry
    • Path Planning
    • Robotics Basics
      • Arcade Drive
      • Tank Drive
      • Joystick Deadzones
      • Curvature (Cheesy) Drive
      • Subsystem Toggling
    • Organizing Code
      • Code Style
      • Code Styling Guide
      • Writing Good Comments
      • Version Control
    • Control Algorithms
      • Bang Bang
      • PID Controller
      • Basic Pure Pursuit
      • Flywheel Velocity Control
      • Kalman Filter
      • Take Back Half (TBH) Controller
      • RAMSETE Controller
    • Competition Specific
      • Operator Control
      • Autonomous Control
    • C++ Basics for VEX Robotics
      • Basic Control Flow
      • Enumerations
      • Namespaces (::)
      • Multiple Files (C/C++)
    • VEX Programming Software
      • PROS
        • OkapiLib
      • vexide
      • Robot Mesh Studio (RMS)
      • EasyC
      • RobotC
      • VEXcode
      • Midnight C
    • General
      • Stall Detection
      • Register Programming
      • Sensors and Odometry in Autonomous
      • Embedded Programming Tips
      • Debugging
      • Bit Shift
      • Bit Mask
      • Autoformatting
      • Finite State Machine
      • Data Logging
    • Object Recognition
      • Red Green Buoy
      • AMS
      • OpenCV
      • OpenNI
    • 🤖AI in VRC: Pac-Man Pete
  • ⚡VEX Electronics
    • V5 ESD Protection Board
    • VEX Electronics
      • VEX V5 Brain
        • V5 Electronics Observations and Issues
      • VEX Controller
      • VEXnet and V5 Robot Radio
      • VEX Battery
      • VEX Motors
    • VEX Sensors
      • 3-Pin / ADI Sensors
        • Encoder
        • Potentiometer
        • Limit Switch
        • Bumper Switch
        • Accelerometer
        • Gyroscope
        • Ultrasonic
        • Line Tracker
        • LED Indicator
      • Smart Port Sensors
        • GPS Sensor
        • Rotation Sensor
        • Vision Sensor
        • Optical Sensor
        • Distance Sensor
        • Inertial Sensor (IMU)
        • 3-Wire Expander
    • V5 Brain Wiring Guide
    • Legacy
      • VEX Cortex
      • Power Expander
      • VEX Motor Controller
      • VEX Cortex Wiring Guide
  • General Electronics
    • General Topics
      • External Boards
        • ASUS Tinker Board S
        • Arduino
        • Beagleboard
        • Leaflabs Maple
        • LattePanda
        • Meadow F7 Micro
        • Netduino
        • ODROID-XU4
        • Pandaboard
        • Raspberry Pi
      • Analog-Digital Converter (ADC)
      • Bit-Bang
      • GPIO
      • I2C
      • Jitter
      • Line Noise
      • List of Tools
      • Output Drive
      • Power Consumption
      • Radius Array
      • Resettable Fuse (PTC)
      • SPI
      • Slew Rate
      • Stalling
      • USART
      • UART
      • 5 Volt Tolerant
      • DC Motor Basics
Powered by GitBook
LogoLogo

This work is licensed under a Attribution-ShareAlike 2.0 Generic License

On this page
  • Weekly Rotation of Team Roles
  • Changing Drivers Every Match
  • Keeping the Same Robot Between Seasons
  • "The Adult is Always Right"
  • Banning Alumni Mentoring and Visits
  • Indicators that Policy is an Issue
  • Teams Contributed to this Article:

Was this helpful?

Edit on GitHub
Export as PDF
  1. Team Administration
  2. Team Dynamics

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.

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:

PreviousMember Allocation and ManagementNextTeam Finances

Last updated 11 months ago

Was this helpful?

Another issue is the fact that design year to year may vary greatly. Different games may have different obstacles and hazards for robots to climb or navigate across.

(Purdue SIGBots)

👑
chassis
BLRS
Sample Tank Drive by Xenon27 on the VEX Forum
Simpler X-Drive - Codec
"The Adult is Always Right" in Practice