As the title implies, I’m wondering how teams usually find technical mentors, as that’s a major weak point of our program at the moment.
A bit of background on our team – Our team is a community team, started in late 2018 because I had experience on another FRC team, and wanted to make “the FRC experience” more accessible to students in my area. For our first year, we functioned mostly without mentorship, as our “lead coach” in the system moved around 45 minutes away, and was frequently out of town. After the season, we put out several notices on CD and other platforms and found a few amazing individuals, however, no direct technical mentorship beyond some code review.
Going into our third season, I’m not entirely sure how to go about finding technical mentorship, which seems to be one of our biggest weaknesses as a program, as the students on the team are really motivated to improve, however without guidance, it’s a lot harder for students to learn and grow. I’ve been trying to fill that role as best I can, by teaching myself using online resources and passing on that knowledge, however, our team’s grown past the point where I’m able to effectively teach all the new members across sub-fields. Does anyone have any ideas or suggestions as to how one might effectively find guidance?
Two thoughts on stuff that I didn’t see covered in the old topics… both related to getting folks in the door:
Parents of students is, IMO, a good group to look to, especially starting out. Lots of parents like to spend time with their kids. Lots of them have some form of professional knowledge. It’s a double edged sword, because these mentors will tend to leave when their student graduates. It means the team has to do more work to preserve the “tribal knowledge” that gets built up in a few years. But, it’s nice for those mentors, since they don’t walk in to an expectation of “never leave!”, and can contribute as they feel comfortable.
Another thing to consider is your local sponsorship base. Sponsorship comes in many forms - my employer provides the ridiculously generous sponsorship of not making me take vacation days for my time away from the office for regionals. Not all sponsors can do this, but it’s worthwhile to mention to your sponsors that you’re not just looking for money or parts - sponsorship can be in the labor of their employees (even in tiny amounts). Merely having a manager say “hey, I saw this program we’re sponsoring, seems really cool, you guys should check out volunteering for them!” is often enough to get some professionals interested.
Finally, I’d definitely emphasize the “no commitment or experience needed”. Yes you definitely do want folks to have a consistent time commitment you can depend upon, but anyone who’s worth having around will figure that out themselves. The experience too - the specific technical knowledge of the program can be learned. It will be learned too, over many years.
Not really, because they are adults with knowledge and experience. They know a lot, just in other areas. Newish students usually know little about how things work, how to make things, how to run a project, etc. Professional mentors come with a lot of this knowledge. You just have to get them up to speed on building competitive robots.
+1 on this. Nearly 100% of our mentors are or were once parents of students on the team. They’ve come to love the FIRST experience so much that they’ve stuck around for years after their kids graduated.
Definitely agree. I personally tend to assume new mentors will be better at self learning. Especially for software folks, week 1 is generally a lot of just chatting with them about their past experiences, likes/dislikes, preferences, etc… and tossing the FRC & WPI doc pages at them. Ya do this parallel ramp of of showing the physical robot, so they can see the end goal, at the same time as they start to read the docs about the details of how we get there. Hook them with friendliness, let them start to learn at their own pace, and watch them as they do. It’ll inform how rapidly you can dump info on them in future weeks, to “get” the new mentor to the point you need them at during the season.
There will be some parallels to new students, though. Definitely assume that there will be a ramp-up period. Pair them off with someone experienced to help show them the ropes, where stuff is at, how the team has historically worked.
Indicate what things are flexible or liable to change, and what’s pretty much set-in-stone. Talk through what other people on the team are already doing. This will help them draw a boundary around what their job role is, and let them morph themselves into the shape of the missing piece on the team.
An underutilized market for FRC mentors is tradespeople (and makerspaces). By and large, engineers don’t build things, where as your local carpenter/electrician/welder has a lot of experience “making it work” - a skill many teams would benefit from having. Additionally mentor who is experienced with various tools (CNC, yes, but even things like woodworking) can be worth their weight in gold.
No, just because they don’t have expertise in an area, doesn’t mean you treat them like students. Our best technical mentor isn’t an engineer, but instead a hobbyist, who is a city planner by trade. He knows how to make sure things are getting done, and is really good at problem solving, even when it comes to more technical issues.
Parents aren’t part of any decisions being made where their child is involved (ie dean’s list, driver). Another thing that I think helps is having the parent work on something different than their student.
I’ve mentored with parents who are very “pro-my-child” and parents who treat their kids like any other student/treats every student like their kid.
Absolutely! Especially after the first engineer (or even a non-engineer who’s mastered @JVN or @AriMB’s design calculators), having a pro at actually building or fixing things is key. 3946’s first CMP qualifying team had the following near-full-time technical non-programming mentors: a pneumatics tech (and former union electrician); an A/C tech; a US Navy ship’s mechanic; the son of a master carpenter and hobbyist; and me (not an engineer, but I understood JVN calculator by then) as mentors, and this combination really helped make it happen. OBTW, everyone I listed had a son or daughter on the 2014 team.
Our lead programming mentor for the first few years showed up out of nowhere our rookie year. I actually work with him now professionally, but have somehow never asked him how he hooked up with the team.