Quote:
Originally Posted by yank
We are in a similar situation. Recently, we've had a huge increase in the number of sign-ups- more than we can accommodate with the resources and space we currently have. Many of these people do not contribute (and are not truly interested in robotics), and on numerous occasions, cause damages to the robot. We then have to reverse these damages, costing us time and resources.
The question is: how can a team be both a welcoming learning environment and a competitive, efficient, organization?
Maybe tryouts are not the answer, as they might make things too exclusive. Perhaps a better solution would be to change the organization structure of the team?
Any advice is very much appreciated. Thanks!
|
We also put a cap on total students to match our mentor / shop resources plus provide meaningful content for all on the team. The students have to apply for the team including consent from the parents for team expectations and time commitments. Teacher recommendations plus good standing with school attendance and grades are the only filter used. There are no try outs. We expect to lose a few students once they start training. Attrition is figured in to the application selection process.
Once on the team, the students can select and try different sub teams during fall training sessions. The trick here is keeping the sub teams balanced to team needs. (We don't have a great answer for this.) Our target is to have sub teams of 3 to 4 students that are lead by a mentor or returning student leader. Small groups with tasks to accomplish keep all involved and provide some buffer for meeting absences.
Also, sub teams do not necessarily equal one discipline. For instance, mechanical is usually split into 4 groups - 3 that prototype and construct - 1 that does CAD. The sub teams are items like chassis, scoring section 1, etc. However, during the first week all teams may be prototyping different version of the same scoring section. The electrical team usually prototypes mechanical as well or may be tasked to create test systems for the programmers. I oversee the big picture to make sure the sub teams are productive and flex resources as needed. Our sub teams report on progress made usually at the end of the day.
CAD team is also responsible for design coordination between the sub teams, keeps the master parts list, and controls the weight budget.
Bottom line, we are a team, not a club. "Welcoming learning environment" doesn't equate to anyone "interested" in my view. Team members need to contribute. Mentors need to figure out how to make that happen.
David