Comment on page
Member Allocation and Management
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.
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.
Team Management Related Criteria, Interview Section
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.
This idea is very much related to the Law of Diminishing Marginal Utility, 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.
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)
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.
Some other roles may exist such as electrical engineers, who are there to prevent ESD, 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.
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.
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.
Last modified 1yr ago