Selecting members for a FTC team

[yank]

To everyone on a school FTC/FRC team:

How does your team select its members? Do you have try-outs of some sort or are students free to sign up if they are interested?

[Devlin Moody]

We have signups to see if people are interested and they can just come, check it out, and stay if they end up liking it. We don't have any form of tryouts.

[dirtbikerxz]

Originally Posted by yank

To everyone on a school FTC/FRC team:

How does your team select its members? Do you have try-outs of some sort or are students free to sign up if they are interested?

Anyone interested is allowed to join. What roles they are allowed to have depends on their interest/skill.

I would advice against having try-outs to even join the team. The point of FRC (in my opinions) is to teach the kids that might have no skills, new skills. By having try-outs to even join the team, you are immediately discouraging anyone who might think that they "know nothing about robotics" from even thinking about joining the team.

[Cothron Theiss]

Originally Posted by yank

To everyone on a school FTC/FRC team:

How does your team select its members? Do you have try-outs of some sort or are students free to sign up if they are interested?

What would be the purpose of your tryouts? What would cause a student, in your evaluation, to not make the team?

EDIT -

Originally Posted by dirtbikerxz

The point of FRC (in my opinions) is to teach the kids that might have no skills, new skills. By having try-outs to even join the team, you are immediately discouraging anyone who might think that they "know nothing about robotics" from even thinking about joining the team.

+100000

[cadandcookies]

Originally Posted by dirtbikerxz

Anyone interested is allowed to join. What roles they are allowed to have depends on their interest/skill. I would advice against having try-outs to even join the team. The point of FRC (in my opinions) is to teach the kids that might have no skills, new skills. By having try-outs to even join the team, you are immediately discouraging anyone who might think that they "know nothing about robotics" from even thinking about joining the team.

I think it depends greatly on the purpose of your "try-outs"-- I know a number of teams who have done an interview process not as a method of excluding people from the team, but in order to give students the valuable experience of submitting an application and interviewing for a position (which almost all of them will have to do at some point). Within a broader robotics program, it can also help to find out what a student is looking to learn or get out of their experience, and what program might be a better fit for them.

[GeeTwo]

I agree that the main question is WHY are you thinking about tryouts?

We have had tryouts for three years now. Why? In fall 2014, we had over 100 students interested in joining the team, and nowhere near enough room, tools, or other facilities for that. This year we moved into a smaller space.

We have a number of challeenges/stations for each applicant to complete over a number of sessions. Challenges are set and administered by mentors and veteran "varsity" team members. Our first year tryouts was at least three weeks long, now its down to two. Quite a few students don't finish (stop coming); those are easy. If we still have too many at the end of tryouts, we go through the score sheets. We score applicants on both abilities and attitude - in separate questions. We use the attitude scores to select the team members, and the abilities scores are mostly only used to identify targets to fill a too-small department.

It's a bit late to use our methods for FRC this year - our first tryouts were in November, but we've moved it earlier (Oct 10-22 this year) to give the team more time working together before build season. It also takes several weeks to set up the challenges before you get started.

[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.

[yank]

Originally Posted by GeeTwo

I agree that the main question is WHY are you thinking about tryouts?

We have had tryouts for three years now. Why? In fall 2014, we had over 100 students interested in joining the team, and nowhere near enough room, tools, or other facilities for that. This year we moved into a smaller space.

We have a number of challeenges/stations for each applicant to complete over a number of sessions. Challenges are set and administered by mentors and veteran "varsity" team members. Our first year tryouts was at least three weeks long, now its down to two. Quite a few students don't finish (stop coming); those are easy. If we still have too many at the end of tryouts, we go through the score sheets. We score applicants on both abilities and attitude - in separate questions. We use the attitude scores to select the team members, and the abilities scores are mostly only used to identify targets to fill a too-small department.

It's a bit late to use our methods for FRC this year - our first tryouts were in November, but we've moved it earlier (Oct 10-22 this year) to give the team more time working together before build season. It also takes several weeks to set up the challenges before you get started.

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!

[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!

[yank]

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!

[ElliottB]

on 45 we let whoever wants to join, join. If they then want a lead position later, they would have a "try-out" of sorts to prove themselves in that role. We have had a lot of growth starting last season, but haven't had a lot of opportunity to train and well... inspire new students. We started an FTC team im on to compete in preparation for the FRC build season, but haven't had a large turn out.

[Jon Stratis]

Originally Posted by yank

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!

When we build, there are typically 1-2 students that focus on each mechanism, which leaves a few as "floaters" to help out where needed. That sort of focus helps to ensure the mechanism moves in a consistent, well defined direction - when you start swapping "ownership" between different people, it can cause chaos and significant rework as those people have different ideas about what the final product should look like.

Keep in mind that splitting up this way does require good communication within the team. There will be interface points between the mechanisms that have to be clearly defined so they work together. There will be space requirements to ensure different mechanisms don't interfere with each other. You need to ensure you meet your weight budget for each mechanism of your robot will be overweight. When you run into communication issues between the subgroups, you'll end up needing to do rework to make things workout properly!

We find it's helpful to have a wrap up, or show and tell, at the end of each meeting. It's not long (maybe 10 minutes out of a 2-3 hour meeting), but it gives each group a chance to talk about what they worked on, what issues they ran into, and what they anticipate needing from the other groups.

[D.Allred]

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

[yank]

Originally Posted by Jon Stratis

When we build, there are typically 1-2 students that focus on each mechanism, which leaves a few as "floaters" to help out where needed. That sort of focus helps to ensure the mechanism moves in a consistent, well defined direction - when you start swapping "ownership" between different people, it can cause chaos and significant rework as those people have different ideas about what the final product should look like.

Keep in mind that splitting up this way does require good communication within the team. There will be interface points between the mechanisms that have to be clearly defined so they work together. There will be space requirements to ensure different mechanisms don't interfere with each other. You need to ensure you meet your weight budget for each mechanism of your robot will be overweight. When you run into communication issues between the subgroups, you'll end up needing to do rework to make things workout properly!

We find it's helpful to have a wrap up, or show and tell, at the end of each meeting. It's not long (maybe 10 minutes out of a 2-3 hour meeting), but it gives each group a chance to talk about what they worked on, what issues they ran into, and what they anticipate needing from the other groups.

The show and tell idea is great! I will definitely try it out. Thanks.