Robolyst Robolyst
← All guides

Recruiting and onboarding members

Recruiting is a September problem that becomes a May problem. A team that takes in six students and keeps two is not a team that recruited badly. It is a team that onboarded badly, and the difference is entirely in the first month.

8 min read

Where members actually come from

Posters produce almost nobody. The channels that work are the ones with a person attached.

  1. Current members bringing a friend. This is the single biggest source on most teams, and it works because the friend already has someone to sit next to.
  2. A teacher who recommends specific students. One physics or CS teacher naming five names beats a term of announcements.
  3. A demonstration. Drive the robot at lunch, at a club fair, at a middle school. Watching it move does the persuading.
  4. The middle school you feed from. A team that runs a workshop there in year one has rookies queueing in year three, and it counts as outreach.
  5. Siblings. Unglamorous, and reliably about a tenth of most rosters.

What to say at an interest meeting

Be specific and be honest, in that order. "Robotics club" recruits people who already wanted robotics; a concrete description recruits everyone else.

Say what the season actually is: when it runs, how many hours a week, when the competitions are, and what it costs. Say that there are jobs that are not building (programming, documentation, outreach, finance, media), because that sentence is what keeps the students who assumed this was not for them. And say the deadline is real, because a team with an immovable competition date is more attractive than a club that meets sometimes.

Do not oversell. A student who joins expecting a hobby and finds a January build week leaves in January.

Give every new member a real job in week one

The fastest way to lose someone is to have them watch. New members who spend three sessions holding a part for somebody else conclude, correctly, that they are not needed.

Find work that is genuinely useful and genuinely doable on day one: wiring and cable management, cutting and drilling to a drawing, photographing the build for documentation, timing cycles during practice, running the parts inventory. Pair them with someone who explains rather than takes over. Who does what on an FTC team is the map of jobs to pick from.

Onboarding is access plus context

A new member needs two things in their first week, and teams reliably provide neither.

Access. The team calendar, the chat, the documentation, the parts list, whatever the team runs on. A member who has to ask someone for every link is a member who stops asking.

Context. What the game is, what the team decided to build and why, what is happening this week and what happens next. Twenty minutes of orientation, given once, saves a hundred interruptions.

The four-week test

Look at your roster four weeks after recruiting. Anyone who has not yet done something they would describe as theirs is on their way out, and you have about a week to fix it.

The fix is not a talk, it is a task with their name on it and a deadline. Ownership is what converts an attendee into a member.

Recruit in January too

Most teams recruit once, in September, and then spend the spring short-handed. A second, smaller intake in January works well. Competition season is the most persuasive time to see the team, and mid-year joiners can be pointed at outreach, documentation and scouting, which are exactly the jobs a stretched team is dropping.

They also become next year's experienced members, which is the actual point.

Recruiting is really succession

Every year a team loses its seniors, and the ones that survive are the ones where a younger member has been shadowing each critical job since November. If your programmer is a senior and nobody else has touched the code, you do not have a recruiting problem next year. You have a team-existence problem.

Name the understudies deliberately, and see handing your team over for what to do with them in May.

Related