How does your team handle incoming new students?

Every team has a different process for how new students who have already decided to join the team are trained, made part of the group, assigned to a sub teams, etc.

Some teams I’ve spoken to have a “JV” and “Varsity” system where veterans work on the current seasons robot physically while the new students build an EveryBot and learn the basics from the veterans. Then they “Graduate” to the “Varsity” team after they know what they are doing.

We don’t do that ourselves, instead in the past we have a series of workshops and anyone who attends those is qualified to work on their subteam and if they miss a workshop they just get trained during regular meeting time to the same standards. Those used to be based around FIRST Badges + extra home brew trainings but it’s time for a new system.

So what does your team do? Do you feel it works well? What do you know doesn’t work well from past experiences?

Thanks in advance!

1 Like

My team currently has “advertise our open shop night at the club fair and hope for the best”. Hopefully, we can improve that for this next season.


We have a club fair where we advertise our club. Our school hosts a few events where folks can attend and see what clubs there are. Also generally my tip is to get those who would be interested in middle school. Do some outreach programs to local elementary and middle schools, and demonstrate STEAM ideas (eg block programming, puzzles, etc)


(This is mostly copied from an earlier post of mine)

Our school hosts multiple extracurricular fairs for incoming students every year, and we always make sure to have a stand at each one. Sometimes we even bring along one of our robots! We also hang up flyers around the school and have admin send out reminder emails about our annual interest meetings. We also sometimes have people join because of a friend who recommended the team to them or etc.

During preseason we meet a couple times a week after school, with the focus of our pre season meetings being on training new members. We have each of our subteams host a small workshop on a skill, and then people can go around to different lessons as they choose. We like having our pre season meetings after school because it’s easier for prospective students to check out the team. We usually have our new teacher sponsor supervise these meetings.

During build season we meet from 5-8 PM every weekday and our workshop is open on the weekends too. We have no minimum attendance requirements so our members come in as often as they can/want too. We generally lose a fair amount of people in the jump from preseason to build season and that is something we are trying to work on.

We generally try to have new members talk to our student officers/veterans and we give them a basic overview of the work our team does with robotics. Usually we have new members come in groups. At the beginning of each pre season meeting we have the entire team come together as a group and our student officers announce their plans for that meeting so people know what activities are available that day.

As I mentioned earlier, we usually have each subteam host workshops for prospective members at our pre season meetings, where we teach them the basics of robotics and frc knowledge. We attend an off season comp during pre season every year so our new members know how competitions work before build season. This is also when we try to introduce them to the idea of scouting. The last thing we do is host a parent info session/potluck dinner towards the end of pre season to give out info about build season and our plans for the year.

We take new members throughout preseason. We generally don’t take much people during build season or post season, because we don’t get a lot of recruits during that time and it can be hard for them to contribute when we don’t have time to train them during build season.

I personally think our plan of each subteam hosting their own workshops helps a lot because new members can have a hands on experience with each part of robotics and figure out what they most want to do. We don’t require new members to have any prior knowledge because we teach everything they need to know and that information is a central part of our flyers and recruitment campaign. I had no interest in being on the programming team (even though I had a lot of prior experience) until I stuck around for some of the workshops and realized the passion I had for something I never thought I could do.

There are some flaws with this plan, which we are currently in the process of fixing. For example, we lose a lot of people in the jump from pre season to build season so this coming school year we will be increasing the meetings more steadily as we approach winter.


First, up front, we pick a capacity for how many students we’d ideally like to have on the team.

The core “so you wanna join the team?” event is our open house. We post on our website & social media, and try to spread via word of mouth and school announcements. The open house is four hours total over two nights during our normal meeting times, and (with very few exceptions) is a minimum requirement for joining the team.

Of recent, we treat it like a two way interview. Students and mentors both show off what we do as a team, and try to get to know the new folks as best we can. As long as new prospects (and their parents) are interested, they’ll leave us their contact info. We’ll also get a general “what are you interested in” feel. Then, as a mentor team, we collect all feedback, and announce the team roster the next weekend. From there, offseason training starts.

We’re contemplating trying something new for training this year: First year students will join into a “software” or “mechanical” track. In both, fall training will focus on the rudiments of tool usage, and for the first year they’ll be largely expected to execute on concrete tasks using those tools. During the build season, we’re hoping that’s enough experience to get them more into how to design a good robot. Then, as a second year student, they’ll have the opportunity pick a sub-specialization - either continue sw/mechanical (and help train new students), or do more training themselves to learn electrical systems or using CAD to express design ideas. The ultimate goal is to split up what is traditionally very complex and “but when will I ever use this?” training into multiple years, with a more concrete onboarding path.


We run a series of “camps” during the summer months (prototyping, CAD, controls, etc). We require every prospective member (new or returning) to attend at least 1 camp to be eligible<1> to be on the team. Usually there is both a beginner level camp and and “2nd level” camp. This year we are structuring the second level’s more as individual projects than “everybody do this” kind of camps. Team members are selected in the fall. Once someone has made the team they start working with their subteam. Typically they start on the simpler tasks, and as they gain more experience move on to more involved tasks. Our goal is that they can do pretty much any task in their subteam by the end of year 2 because starting in year 3 we are expecting them to take a more leadership/teaching role.

This has served us well in maintaining institutional knowledge within the team.

<1> among other requirements

1 Like

We have several “Hey, you want to join?” events, including one where we sell stuff at a park event (this doubles as a fundraiser!). After this, most students go into our rookie FTC team. From there, they can either do one more year of FTC or do FRC. In that rookie team, most people find their specialization, but some people switch. Occasionally, people join straight into FRC, or do nearly nothing in FTC but get really involved in FRC. Generally, we let pretty much everyone participate in whatever they like.

Actually this is really simple. We are not just co-workers with the team, but also friends in normal life. We are adding new members to our team. we do activities together (even really simple activities are enough), we spend our time chatting in the workshop and most importantly, we do it by having fun. they are gradually warming up to us and they want to become more active in the team. We leave them free to choose their fields and teach them the job during the robot building process.

Ah. Team Size. We are struggling with this. I think most people here would agree that participation in FRC is an immensely valuable thing. To deny it to a student is hard. You are withholding something that will make their life better…potentially much better.

But there are physical limits. Shop space size. Enough mentors to supervise and teach. Budget. (sub question: how many to take to tournaments…we are rural and ALL events involve pricey transportation and hotels).

You could use fees to sort it out. But do you want to penalize families who are economically disadvantaged? No, I thought not.

Ability tests? Well I’ve seen students who were not that great in year one and superstars a year or two later. And vice versa. There can be things going on outside of Robotworld…

There is no ideal solution. Our team grew quickly post covid. We peaked at 36 last season. Three or four drifted off as we just did not have the resources (see above) to formally teach. We only graduated four, so something has to change.

Tentative plans are:

Continue the low profile. We recruit primarily from our middle school farm system. Zero advertising at HS level although walk ons and friends always welcome. The farm system btw is all team created, not FLL/FTC/Vex stuff at all.

General build and software slots will continue to be “open” and we’ll regard those as teaching programs. Specific roles that need specialized skills will have testing. Drive team. Most of the jobs in media/pr. Don’t make the cut? Entry level roles still available elsewhere.

On my watch we won’t bump people off the team because they are having an off year (see above) or if they are hard working but have modest abilities.

There are longer term plans under consideration. The 111/112 model of having two FRC teams, one for younger member and one for older ones is intriguing. We’ll be doing a parallel middle school program essentially building with KoP (and maybe adding Everybot parts from this year’s tote). This could be scaled up to two teams in the short run but once rookie grants ran out the expense of having both units would break us.

Too many students. Not the worst problem to have but still a problem.


I made a “on boarding” task for my students on the programming team on our github which got everyone spun up pretty quickly this year.

About 5 years ago we started attracting more students than we could fit. Here are some of the strategies we have employed:

  • Creation of an Associate Member role. This fits those interested in robotics but unable to commit to 20+ hr/week Jan-Apr. They mostly participate on non-tech teams (fundraising, outreach, graphics, website, etc).
  • We started an FTC team. This fits those that can’t commit to the intensity of FRC but still want to do technical stuff.
  • We’re actively promoting the two other FTC teams in our county (we are the only FRC here).

Not for us either. We don’t care if you come in not knowing which end of a screwdriver to hold. Commitment and Gracious Professionalism are our yardstick.

1 Like


Good thoughts but in our case not immediately helpful. There is essentially zero FTC presence in our part of the world. The “home brew” middle school programs take up the slack and in our experience do a better job of prepping for FTC. Our entire student leadership came up through this system.
And we’ve had non ideal results parking less motivated people into the general media/pr/business world. It became a social hangout and source of distractions.
Thanks for these (and all other) suggestions though. We learn from our experiences good and bad and keep on adjusting. It just takes a while to “outgrow” your early days. We used to be a scrappy community based team of about 18 students. Now we have to keep the school system happy. They’d like us to open the doors wide. Heck, we’d have 50 kids but would not do a decent job at that level.

1 Like

I would not describe our Associate Members as less motivated. Typically they are exactly the opposite, they are highly motivated in so many things (robots, sports, debate, bands, orchestra, etc) that there just aren’t enough hours in a day for them to give us 20-30 hours a week during the school year. Non-motivated doesn’t make the team.

Oh, I understand. I was describing our experiences. OTOH we sometimes have members of a very Junior status step up massively. Our two build leads this past season were Freshmen. At one of our two tournaments we had a Freshman and an 8th grader running the pit. And running it flawlessly. HR is always an inexact undertaking!

Interesting how many posts describe recruiting and selection activities. I read the OP’s question as more about training and onboarding. Maybe I misread it.

In any case, here’s my input on what I think is being asked:

We offer mentor-led workshops in the fall for manufacture/build, CAD, and programming. These are open to all team members, not just new members. These are held once per week for each topic. We usually get about 8-10 sessions completed between the time our team selection is done and the end of school for the year. Content is mostly on the introductory side each season. Veteran team members who attend still pick up some new things as well as build depth by helping or explaining to the novices. Participation is not a requirement for being on the team, but is strongly encouraged. Those that can’t put in the time or lose interest usually self-select out of the team sooner or later.

All students must complete safety worksheets each season. For manufacturing/build students, those must be complete before about week 4 of the fall workshops for them to continue with the workshops. For students in other disciplines, they must be complete before build season begins.

During build season, training occurs by doing. New members work with veteran members or mentors to accomplish tasks. We don’t have a big enough program to run a novice team and a veteran team.

We don’t have skill or ability tests, but new manufacturing/build students must work with a mentor when first using power tools (chop saw, band saw, table saw, drill press, mill/drill, lathe, CNC router). When they have demonstrated safe and correct operation they are then granted the ability to use these machines independently. We regularly ask students if they have questions or need help with power tools, especially if they are performing some operation which is less common.

…assigned to sub teams…
Our recruiting material includes information on sub teams and students are asked for their preferences when they apply to the team. Mentors look at counts of sub team interest for new and returning students and make a first-pass sub team assignment for each student with a goal of balancing student interest and mentor availability. If any student would not be on a sub team of high interest after this pass, we would talk to those students to get more information about their interests and provide more information about sub team options. We try to shuffle where possible and as early as possible to get the best fits.

…made part of the group…
This just happens with time. It’s amazing to see the difference between the full-team camaraderie at the fall kickoff meeting and the end-of-season celebration dinner. We don’t do anything formal like icebreaker exercises or a team outing to a ropes course or anything like that. Mentors usually ask new students to work together in different groups to help them get to know each other and build skills. Eventually, mentors try to group new and veteran students together on tasks to have more team-wide bonding and expand skills further.

I don’t expect that any of this is particularly unique or especially effective. It has worked acceptably for us given a 20-30 student team and 3-4 heavily involved mentors and another 2-4 that are occasionally involved. I’m also interested in hearing about other approaches and success or lack thereof.

1 Like

Our onboarding is similar, but we start in June. During the summer, at a minimum every potential member (new or returning) must either attend (or teach) a summer camp (CAD, Manufacturing, Graphics, etc), must attend an outreach event (eg the Country or State Fair), must attend a sponsor visit, and must attend the twice monthly team meetings. They also fill out a brief application form (what subteams they are interested in, etc) and have a brief interview with team leadership.

The local university generously allows us to work out of their shop, as a result any of our members who work in the shop (which ends up being most of them), must pass the same university safety program that the university students do.

Member selection happens at the end of the summer. During Fall Semester most of our students are off mentoring local FLL teams. Then, of course, Jan-Apr happens…

Typically the 1st half of one of our meetings is learning based (team culture, what subteams do, etc) and the 2nd half of one of our team meetings is a hands-on exercise (a kahoot, build something, etc). During Summer and Fall these are often geared towards building team camaraderie. For example last night’s was:

Divide into 6 teams, take this piece of aluminum foil and build a boat that floats the most pennies, also name your boat, and write and read to us a paragraph about why your boat is the best. And teams must be mixed new/returning members. You have 5 minutes.


We used to do something similar in my Mechatronics class as an ice breaker. I gave them office supplies instead but we still made boats. They got a note card, 2 popsicle sticks, 2rubber bands, a paper clip, 1 foot of duct tape and I think maybe 2 straws if I was feeling generous (the straws can hold air and be super bouyant if you tape the ends closed)

I got the idea from engineering design challenges we would do at The Robot Garage. There we also did straw bridges, spaghetti towers and Zipline gondolas. They all had the same purpose of getting the kids into groups, working and thinking outside the box. All of those worked really well but I don’t like spaghetti towers because of the cleanup needed.

All of them require you have them explain what worked and what didn’t and why