Team Mentorship Question

[Andrew Schreiber]

Originally Posted by Boomtownblues

Hello,

I apologize in advance if this is in the wrong subforum.

In 2007 I was on a FIRST Robotics team back in Chicago. Since then I've graduated with an undergraduate ME degree and I'm working full time now at an automation company.

I'd like to get more into youth STEM education and I've been hoping to mentor a FIRST team. However, I'm not really sure where to start.

For a newbie mentor, would you recommend starting in mentoring FLL teams or jumping straight into an FRC team? What should I consider when mentoring any team? Any tips in general?

Thanks

07 Alumni represent?

Anywho, I jumped straight into FRC without any problems but I never really stopped being involved. I was fortunate enough to be able to include FRC and college at the same time. Since graduating college I've also picked up an FTC team and been involved with various FLL tournaments. Personally, I struggle to mentor FLL because I find it very difficult for me to communicate with students that age. If you work well with that age group of children I highly suggest getting involved there. If not I suggest looking into either FTC or FRC. The main trick is remembering you aren't a student any more. Sometimes you have to let the students make something that will fail just to learn why.


Things to consider:
You're new at your job, don't let FIRST interfere with work or having a normal life.

FIRST is awesome but having a balanced and happy life is important.

If a job can reasonably be done by a student you should let them do it if they are interested. (If they aren't interested try to get them interested)

These are children and they are impressionable. Act accordingly.

These kids sit in school 7+ hours a day they don't want to be lectured at. Treat them as equals whenever you can. Get their input. Whenever possible have them form hypotheses about how a system will perform and then test it. Then evaluate why it did or didn't work and how to improve it. (This all goes out the window when safety is involved)

Be supportive. As a programmer all too often the mech people blame us for everything, half of my job is being there to take the annoyance of people blaming code for things. The other half is pointing to the students whenever things go right.