Respectfully, I don’t think that SNACK MAN is just a sub role. SNACK MAN is probably the most important person on any team, as they help keep team morale high and are the most skilled at getting snacks. If my team didn’t have a SNACK MAN, I doubt we’d still be a team.
6 Likes
Sorry if I offended anybody, that is just the only way I have ever known it. I will use ‘backup driver’ instead.
Great choice! Other terms, “secondary driver”, “co-driver” (like co-pilot if you have two controllers 
)
3 Likes
snack man dubs. i would say that the notebook is really overlooked (at least for my team) so just try to make sure someone is doing it.
i never gave an example of how the roles are distributed on my team, so heres one
Member one (me)-
Team Captain, notebooker, scouter, and driver
Member 2-
Coder, co captain, scouter, and drive team member
Member 3-
Notebooker, builder
Member 4-
Builder, designer,
Member 5-
Builder, driver, notebooker.
Everyone distrubuted work pretty well together, so we often share all roles
This is what my team (IQ Team) Has:
Driver
Builder/Designer
Programmer
Notebooker (Although, we all do the notebook)
Parts Coordinator
Data Collector
Researcher
Runner (Runs to the match area and see if a match is coming up)
Snack guy/Cheerleader
My team shares these roles so all of us can get experience and work together!
(My team is a 5 man team)
1 Like
My team has roles assigned very loosely, with the exception of notebooker who is almost exclusively me until I force other people to help.
Our team members are:
Driver/Builder/Designer
Back-up Driver/Builder/Designer/Programmer
Builder/Designer/Pit
Scout/Notebooker/Sometimes-Builder
Everyone else is a combination of snack guy, parts boy, person-who-puts-stuff-away, and sometimes a builder, depending on what we need at the moment.
I would like to offer my experience on this.
Now I started VEX IQ in late October 2023, so keep that in mind.
We never officially assigned team roles, we applied for specific roles but we never really had official roles. This lead to a lot of “oh I don’t need to build I’m a coder”. This was pretty disastrous, and there was a lot of confusion. I would recommend you not only assign roles officially, but make sure everyone is on the same page about what each role does.
Now this might be my personal opinion, but the driver should be the person who knows the robot the most. I have had times where people who haven’t really been active in the building/coding process have wanted to be drivers and it hasn’t ended well.
The driver should ideally have perfect knowledge of the robot, knowing what works, and what doesn’t, and above all, be very, very calm.
That being said, there is nothing excluding the driver from holding other positions. My builders bias might be showing but I think the builder will have the best knowledge of the robot, but in my opinion, driver should not be a separate role.
In my experience, there is usually a separate schedule for everyone in the team. My suggestion is just to make sure everyone knows what the goal is.
I’m sorry I couldn’t give a more helpful answer for that, in my experience most people just work two or more roles
1 Like
Well, from what I hear, there are 2 ways people handle this:
- Use the driver as an assistant builder
- Build the drivetrain, and have the driver drive it around while the builder builds each mechanism at a time (then one-by-one adds each to the robot for the builder to train on).
As for coders, they can pseudocode the robot for autonomous and tune it later when the actual robot is ready, and/or be another assistant builder. Notebookers are usually doing the notebook the whole time.
For builders, I personally am always tuning our robot, working on a mechanism rebuild, or doing a little experiment
How My 2-man Team Handles This
I am the builder and driver, and my partner is the main notebooker and coder.
My partner would help out with building (especially during a comp crunch, but she usually has other commitments) , but usually stuck to notebooking.
2 Likes
My team has roles, but they’re mostly informal. Some people have more knowledge on certain subjects, like programming or building, but we don’t strictly stick to only doing certain tasks. We all do notebook and build/design, the people with experience programming do programming, and the driver is just the person with the most practice driving. In general the only meetings we schedule for specific people are programming meetings, because programming is more specialized then everything else. This makes sure everyone knows what’s going on in other parts of the process and helps us collaborate better.
3 Likes
My thinking is all team members should contribute to the overall growth of the robot - meaning more than one person can help design, build, code… However, it is important to have a team lead for each role to assure all aspects of robot is managed and documented. How that looks like will look different for every team - make sure to document it all and discuss as a team so everyone is well versed in the whole robot …
5 Likes
We usually just have everyone do 2 things or sometimes three so everyone has something to do
I agree.
Motivation and teamwork is key. Team members who are often successful find something to hone and then they hone it. For example one member can watch Fusion 360 tutorials and find a genuine interest in CAD while the other learns C++ and spends time to understand how templates work as inspiration to make their own. creating a modular system can enhance the design process build cycle dramatically without needing to rely on having the physical parts available. And over time CADing a robot would not only be quicker but yield better robot designs and equally less money spent.
To be frank, VEX isn’t really a sport that requires a team member to fulfill only one role but finding a genuine interest to enhance the design process can prevent burnout and entice more members to join the team.
4 Likes
Our teams roles were:
- Project Manager
- Coder
- Driver (More than 1)
- Builders (More than 1)
Hope it could help!