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
  • Optimal Team Size
  • Team Leads
  • Team Roles
  • Summary
  • Teams Contributed to this Article:

Was this helpful?

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

Member Allocation and Management

PreviousOrganization Structure and LongevityNextHow *Not* To Run a Team

Last updated 12 months ago

Was this helpful?

Often overlooked, member allocation and management structure is something that can make or break a team, and may determine how much fun and experience members of a team will gain.

Optimal Team Size

This section talks mostly about a high school or middle school VRC team. VEXU team sizes can range wildly from a couple to 50 people depending on their objectives and should be evaluated on a case to case basis.

Optimal team size for a high school VRC team is 4-6 people. This allows at least 1-2 people working on software and mechanical aspects at a time. This begs the question, why not more?

The issue with team sizes such as 8 as common in larger organizations, is that there tends to be too many people with not enough things to do (too many chefs in the kitchen). This becomes an even larger issue when evaluating a team based on the design award rubric, which directly contributes to the design award and excellent award.

With these sections requiring that teams have "All students answer questions independently", and that "students were assigned to tasks based on their skills and availability", this becomes much harder to explain and show if there simply are not enough tasks at all times for all students to do.

Team Leads

Team leads are somewhat of a controversial subject in robotics teams, as they have the potential to cause a large amount of strife within a team. Because of this, we cannot recommend team leads on the team level as team leaders tend to dominate team decisions unless the team lead(s) is the only competent person on the team with experience (which is also subjective at best).

However, if a team does require a lead (such as in the case above), the best way to do leadership is from a bottom-up approach where the team as a whole talks through decisions and the lead is there to drive that conversation, as opposed to a traditional top-down leadership structure where the team lead is the final say in everything and their opinion reigns supreme.

At the end of the day, the engineering design process must be the driving force behind the teamwork, not the leader themselves.

(Definitely easier said than done)

Team Roles

None of these roles should not be used to restrict people into specific responsibilities or allow the ideas of one role override another, but rather be used as general labels to better figure out how to organize information about the team during interviews and divide work up. With this in mind, multiple people can share one role.

Technical Roles (Mechanics, Programmers, etc.):

Technical roles are relatively self explanatory. The main two being mechanical engineers who are responsible for building the robots, maintenance, and coordinating with the software engineers who are responsible for figuring out where sensors need to be mounted and programming both the drive code and autonomous.

Since the programming and building of a robot may happen at different times, the same group of people may be used for different roles during each phase of the build process. It should also be noted that all members (whether they are on software and mechanical) should be involved on the entire design process.

Support Roles (Notebookers, Drivers, etc.):

Similarly to the electrical role mentioned above, these roles can be done by members with less technical responsibilities or during their downtime. Notebookers are a must have throughout the build process and programming process, and are best done by the ones building and programming at the time. However, if properly explained to others, people who aren't directly programming or building are able to also notebook as well.

Driver roles are somewhat of a controversial topic as well, as different members all may want this role. There is no set in stone solution to figuring out who should drive, but professionalism and the lack of personal emotion with regards to the team's decision process is key to keeping a team dynamic together. The best people to do this are the ones who both have the most amount of down time during the programming phase for the robot, and come and stay for meetings the most since this will give them the maximum amount of time to drive.

Summary

Member allocation and management is something that does not have a cookie cutter solution for each situation. It must be adaptable depending on various factors surrounding a team, such as level of experience and number of members among others. The only thing for certain is that establishing a working system for a robotics team that is both flexible and appropriate for the situation as early as possible is key for a team's success.

Teams Contributed to this Article:

This idea is very much related to the , which describes the addition of each additional unit (team member in this case), continuously having a decreasing usefulness to the team, until that usefulness becomes negative and is detrimental to the team. Click the link embedded above for more information.

Some other roles may exist such as electrical engineers, who are there to prevent , maintain wiring, or even mechanical maintenance on the robot. This could be done by members only interested in either programming or building, during the phase where they may not have as many responsibilities.

(Purdue SIGBots)

👑
Law of Diminishing Marginal Utility
ESD
BLRS
Team Management Related Criteria, Interview Section