Selecting members for a FTC team

[Monochron]

We implemented a team-size limit this year and here is an overview of what we did.

THE REASONS

Thus far we have been opposed to limiting our team size because it didn't really fit with our goals, but we made the difficult decision to do it this year. Our reasons were 1) that the number of interested students interested were more than we can reasonably fit in our shop area. Last year physical access to our tools was something that we had to constantly manage and noise levels just from conversation were too high. 2) The number of interested students was more than we are currently able to manage with our mentors and student leaders. Last year during build season a lot of great students stopped showing up because we weren't able to provide them with work to do. And a lot of uninterested and unmotivated students hung around barely putting forth effort.

That second reason got to me a bit. We were losing great bright students because MY leadership wasn't strong enough yet.

OUR PROCESS

So then we had to come up with "requirements" for joining the team. Our core goals are to inspire any type of student (regardless of prior interest or ability) towards interest in STEM and so we didn't want to prevent students from joining based on skill or ability. We decided to allow all students to join at the start of the year, but to only admit them to the final team if they had reasonable participation and initiative. Early on we settled on an optimal team size of 30. In October, we decided to bump it up to about 40.

To formalize this we took inspiration from some other teams and set two criteria: attendance and "micro-homework". We called it "micro-homework" because the intent wasn't to measure ability, but to require outside action - action that requires very little work but does require initiative to get it done. The first micro-homework was basically "I'm going to send you an email, respond to it by next meeting". You would be surprised how many freshman simply aren't ready to reply to emails. As the year progressed we focused the micro-homeworks on more useful tasks (ie. read this page from 254's build blog and answer two questions, etc.) but kept the level of difficulty relatively low.

Throughout the time we kept students up to date on their scores and even built a web widget where they could log in and see their own scores but not the scores of their peers. This allowed them to manage their own progress as well as contest any errors.
Before the threshold was imposed (ie. "cut-day") we spoke personally with each student who was below or near the 40 student cut-off. We asked them if there was anything we could help with and tried to have a "real" conversation about why we were doing this and where they stood. On November 1st we sent emails out to everyone individually telling them their final status.

LESSONS LEARNED

Good:

1. This system made students value being a part of our team much more. It cut down on loafing, improved student engagement, and implicitly embedded the idea that participation and effort is required. (We can "tell" students that effort is required all day, but they don't really know what that means until they work on real projects)
2. We don't really have anyone attending just for socializing but we still keep the mood light enough that people have fun.
3. Students are now used to doing work for the team outside of meetings.

Bad:

1. If you do a system like this, keep the duration shorter than we did. Do NOT have the period last from August to November. Many of the students who we had to let go loved the team, were making friends, and cared so much about being a part of it. We wanted to make the period long so that we could see real separation in the "scores" and so that we could really trust our results. Asking students to leave after they had been involved for so long though, was the wrong decision. Causing students that much pain and tears from not being able to be involved with a STEM team was truly awful. I think it is my single biggest regret in my years with FIRST.
2. Our system of micro-homeworks and attendance did a reasonable job of rewarding students who were passionate and filtering out students who were not. However, it definitely seemed to reward students who excel at "book learning". Students who probably get straight A's. This is partially a good thing, though we hoped that students who may not excel in school, but who have plenty of drive and passion would rise up as well. We had around 15 students with 100% scores and that may have skewed things as well. Re-evaluating the contents of the micro-homeworks might help.
3. This may be relevant to less teams, but because we are a Charter school, some students chose to come to our school in part because of the team. The prospect of not getting to participate (after choosing our school over others) is very negative. We as leaders need to be proactive about making sure that our school reflects the fact that we have a limited size. We were good about that messaging at our team meetings, but prospective students NEED to be aware of this before they commit to the school.

So that is how we ran our size limiting this year. We will probably do something similar next year (our space isn't growing), but we are definitely going to change some of our methods based on the info above. Please ask if you have any questions, or suggest better ways to do things, we are definitely interested

[Jon Stratis]

The big thing to take away is that there needs to be a reason for limiting the number of people on your team. It's easy to see a sudden large increase in student interest as a problem, but it all depends on context. A team of 10 students doubling in size presents different problems than a team of 60 doubling in size.

I would encourage any team looking at a significant size increase to consider what they may be able to do with such an increased size. More people means you can increase your outreach efforts, build a practice bot, allow students to focus on a single area of the team instead of being stretched to cover multiple areas, or take on additional challenges that you haven't looked at before (animation contest, website improvements, FIRST Parody, etc).

Of course, there are teams that are already fairly large and already doing all of that. At that point, adding more people can pose serious problems in terms of space constraints in your build space and in terms of how much any individual student can do. Every team has to decide for themselves where the balance lies between including students and providing the students with the best experience. Too many students, and the level of involvement and benefit can start to decrease. Too few, and students can get overworked and burned out trying to do everything. So, in determining the number of students you'll have on the team each year, you also have to determine the team goals, so you know what to spend your time on.