Quote:
Originally Posted by Jon Stratis
It sounds like you need to create clearly defined roles within your team - leadership, build team, programming team, drive team, outreach, business, awards, etc. You can then welcome everyone onto the team, but then have tryouts for different roles, focusing on the necessary skills needed for those roles. In that way, you can filter the students that maybe aren't interested in the robot itself into other roles, and keep them away from damaging the robot itself. But you do need to provide clear paths for people to take to get into a role if they really want it!
The past couple of years my team has had an issue with borderline excessive interest in one or two subteams, and declining interest in others. It can result in a lopsided team and not having enough for everyone to do within a single subteam. We haven't had to go to tryouts yet, but we have worked on encouraging students to try out/help out other areas to keep the team balanced. It's tricky to do!
|
Yes, I'm currently working on making clearly defined roles. Our team is especially builder-heavy (many people are only interested in building), which leads to overcrowding during our build sessions. What are your thoughts on clear;y splitting up the build team into smaller groups (chassis, arm, shooter, etc)? Thanks!