Mentoring Tips and Tricks

FIRST General Forum
1

Ok CD, I’m a young guy who has had the fortune of getting to work with some simply phenomenal people during my time in FRC. And now I’m trying to be half the mentor they all were for me.

I’ve sort of characterized mentoring into 3 major types:

Doing - Actually do the work. Design the solution, make the part, do the code and then explain it later.

Show - Walk the student through the solution to the problem. Basically stand over them as they design and suggest (obviously) that a particular solution might work better or that the current solution won’t work.

Asking - Asking loaded questions intended to develop critical thinking and problem solving skills. Rarely give an answer but encourage the students to explore and find the answer for themselves.

I’m currently struggling with mentoring an FTC team because I don’t know when to do, when to show, and when to ask. Really, it is something I’ve always struggled with and would like some guidance on what others do.

2

I think you’ve obviously figured out that it will require all 3 to be an effective mentor at some point. I think a lot of it for me is gauging the situation and recognizing when it is necessary to escalate through those 3 types of mentorship. I say escalate because I think ideally you’d like to just ask and let them run with it, but to get the most out of the program, you are going to have to be taught how to do something, sometimes inception won’t work.

I try to avoid doing whenever possible, but realistically it will happen. Some examples that I tend to do somewhat often are getting things apart/together, removing press fits, fixing a broken tool/machine or fixing a broken CAD. Rarely however are these done in a strictly “doing” mentality. Its usually more of a directed showing. Not necessarily breaking down each step, but letting the student watch what I do and hopefully they pick it up after a few viewings.

It takes a while to really feel it out and determine what the best course of action is. I’m sure its different for FTC, FVC, FLL, FRC or whatever other activity you may be doing as well.

My key piece of advice is to just sit back and observe while asking directed questions until you feel things are stalling. If the project is slowing down, try to push it over the hump by jumping in here and there.

-Brando

3

You always want to keep challenging the students to be better. Keep things just a little harder than they can handle. You will be surprised at how they will step up to the challenge

4

My big concern is that they have a competition Saturday and I don’t want to see them get discouraged.

5

Don’t be afraid to step in and take charge when needed. I’ve seen many successful teams with strong driving mentors, and I’ve seen many lackluster teams with mentors who sit in the background. Of course there’s probably also a number of counter-examples. Personally, as a mentor I like to see results. I am not the mentor who asks questions all day long without ever providing answers. That does not lead to results.

I believe that when it comes to quality, good work comes from good examples. If you let students entirely run the show, yes they may come up with something decent on their own but it would probably rarely be of the quality it would be if an experienced mentor showed them better methods or designs. Very few people every got smart and experienced all on their own. It helps to show them certain ways to do things, and why their ideas may not work, or may be better implemented by some other means. To me, it’s not smart to just let the students do whatever they want and only be a mentor when they call on you. You’ll see more success my taking more of a leadership role.

The show part is critical when it comes to manufacturing methods and tool usage/safety especially. I would have never learned to run machine tools from someone just asking me questions or doing it for me.

The do part is fine, but make sure what you’re doing is supplemental rather than replacing student work. There are certain things I believe students don’t absolutely need to be involved in every aspect of. Also, sometimes there are not enough hands to go around, and the mentor doing things can be a big help.

For a specific example of mentors stepping in or not, let me talk about the 696 minibot from this prior season. We let it be an entirely student-run subsystem of the robot. And to be brutally honest, it failed rather miserably. The students did not understand the Physics involved, and were all new students to the team without prior experience. There was very little mentor guidance. To prove a point to myself and others that a fast efficient minibot could be designed and constructed easily with minimal difficulty, I went and built one on my own one night, and brought it in to show the team. They had no perception that it could be so easily done until seeing it. They were not familiar with things like strong magnets, and removing gear heads from motors. It was too late for them to change course on their plans, but we ended up using my minibot on several partner teams’ robots with great success, and ended up winning the Coopertition award. This was a great experience for the students in working to install a minibot on other teams’ robots when their own had failed. They got to work with teams from other countries even who hardly spoke any English. Did the students learn how to build a great minibot on their own? No. But did they learn that it could be done and get a new spark of inspiration to wipe out the discouraging failure of their own? Yes. Did they learn more than if I had done nothing at all? Absolutely.

Whatever you do, just ask yourself “would the team still function without me, or would it collapse?” If it would collapse without you, you’re doing to much yourself without showing others. If it would still function without you, you’re doing it right. It needs to be a self-running machine.

6

I’ve been working through the same issues as Andrew, and I still don’t have many of them figured out. I graduated college, showed up to a meeting, and basically got “oh hey, you can be head coach now!”

I’m still working through the questions Andrew posed, and I’m very interested to read the responses of more seasoned coaches.

What I will add to what Saddrag posted, about: “It needs to be a self-running machine” is that recruitment of good students is key. Once you’ve got a few good students you can take a step back from doing a lot as a coach, but I think it’s important to step up and develop a successful robot if the student involvement isn’t there that season.

7

Start by asking, but remember they don’t always have the persistence or resourcefulness developed in college. Switch to showing with some asking if necessary, that’s just fine. Doing only as a last resource - don’t let them fail.

I define “not failing” as they have an inspected, moving robot at competition. Anything beyond that, they need to work for.

8

::rtm::
No seriously,FTC has a mentor manual, and it is pretty good (though I do expect Andrew to take issues with Item 6* on the 12 principles of being a mentor).
I had to double check the manual as I had it stuck somewhere in my head that FTC mentors were actually forbidden to do, and could only ask/guide. I could not find it in the recent mentor manual.

*Extra Super Mentor Search Function Bonus:
Andrew is on the record in a thread alling out Item 6 as a “tool”. In the same thread, a really cool mentor mentions that Andrew & friends should do a white paper on the topic that initiated the use of Item 6.

Proof that Andrew has made huge improvements from the previous thread to date could be the hosting of a very recent webcast. While not exactly a white-paper, it probably will reach more students/other mentors than a white paper would.

**I will pass on some greenie rep to anyone who is able to find links to the topics I mentioned.

9

I remember that thread… Should I really be encouraging people to find threads where I’m a jerk? Eh, what the heck, I can always do with a good reminding of my mistakes.

You’re right though, I do take issue with 6 as I do still feel that, for some students, sarcasm is a great teaching tool. It breaks the ice and helps to move from the Teacher role into the mentor role. However, for some students it is terribly detrimental. I know when I was a student sarcasm would sometimes get through to me.

Ike, you’re thinking of FLL where mentors are forbidden from doing.

Twelve Basic Guidelines for Mentors

  1. Be a mixture of best friend, honest guide and coolest teacher.
  2. Avoid the temptation to do the work or to deprive team members of the chance to discover the right the answer on their own. Mentors should guide a team without directing it. This creates the best learning and growth experiences for team members.
  3. A Mentor’s behavior and attitude can and will influence how a team chooses to respond to the environment around them throughout the season and at events. Demonstrate and encourage Gracious Professionalism™ at all times.
  4. Foster discussions between all team members and groups. Discussions are critical for effective brainstorming and strategy
    development.
  5. Patience is a necessity. Practice it, especially with the most trying of students.
  6. Never use sarcasm while teaching or helping someone. A good Mentor never resorts to sarcasm and anger to hasten the process of learning.
  7. Mentoring is a two-way street. It is as much a job for a teacher as it is for a learner. Practice both with equal humility.
  8. Never let students indulge in fruitless activities during learning hours. Find something to teach in all activities and try to make every activity an educational experience.
  9. Infuse enthusiasm in every activity and part of the challenge. To spur creativity, mix humour and a passion for learning and discovery.
  10. Get involved in technical and non-technical experiences. Be supportive to students in both regards.
  11. Be the team’s best cheerleader, enthusiast, leader, and friend. Happy teams win many accolades and learn the most.
  12. Forging relationships and gaining friends are far more valuable experiences than participating on an unhappy team and gaining meaningless trophies
10

Back to the original posting:

It wouldn’t be a leadership thread without me plugging a really good book that one of my students gave me:
Tribal Leadership

This book talks about various stages of development that you go through, and gives a lot of good hints on how to guide the student/person into higher levels of leadership. While not directly covering the Do/Show/Ask principle, it does cover items that should help you gauge the students leadership level, and what kind of challenges you should throw at them.

Some general guidelines on Do/Show/Ask might be:

Do when they have absolutely no clue.
Show when they simply don’t know.
Ask when they are up for the task.
After they succeed, let them lead.

This little Rhyme covers 4 levels. If I have no clue how a computer works, I need you to do some stuff in order for me to be inspired, and thus gain the drive to learn.
If I just don’t know how, but have a basic interest and some awareness, then showing me how to do something is appropriate.
The asking strategy really only works when there is enough understanding that some guided questions will get me there. This tends to work best when a student has already worked on this type of thing before, and either forgets or the task really only requires some additional structured thought. If you try the “ask” whne they have no clue, they will be very frustrated.

The last item is often the toughest for mentors to do. This is when you drop the reins and let them lead something. Not every student will get to where they are ready to lead, but the ones that do need that challenge. This can also be difficult as you are now asking a student that is very good at something to “not Do”, but to “show” and allow the other student to Do. Frequnetly this is also a hick-up that College mentors that do not take time off from FIRST have trouble with. They themsleves have often been the do-ers. Often they were great doers. If their mentors did not ask them to “Show” and thus start them on leading, then they have difficulty in skipping the steps required to have other students become leaders.
In tribal leadership, this is the jump from Level 3 to Level 4.

Besides Tribal Leadership, there are a lot of other leadership books out there that talk about different levels of leadership, and they all tend to follow the samekind of pattern:

  1. Be in a starting position with a desire to learn.
  2. Learn, learn, learn.
  3. Practice what you learn and begin to excel at it.
  4. Teach others what you learned.
  5. Teach others that are good at stuff to teach others.
11

There’s no easy answer. I do all 3, with the goal being that we figure out how to do stuff together, and as they learn more, I do less and less. I consider myself part of the team, and as a team member, I am here to help the team do well, I’m not only a teacher. The way I see it is that if you’re doing it right, then it IS a struggle to know just what to do.

Welcome to the club.

12

Maybe I’ve missed it, but here is something I rarely see mentioned when talking about what makes a great mentor.

Mentors need to be constantly learning.

There is always going to be some aspect of running a robotics team that a mentor has the potential to learn; writing a business plan, coaching on the field, the psychology of managing large groups, the details of how CAN works, whatever.

I spend a lot of my free time talking with other mentors, reading CD, experimenting, learning how others deal with issues. That way, when it comes time to inspire the student, I am ready.

If you think you know everything, you don’t. Although some of the posters here on CD come pretty darn close on some subjects. There is always something new to be learned and you should take the opportunity when it is available.

13

I distinctly remember reading in an FVC guide something along the lines of “Don’t build the robot for them!”. Not a rule but a suggestion. I’ll have to find it.

14

I’ve seen similar passages in VRC materials - one in particular alludes to a mentor’s hands in his [sic] pockets where they belong.

15

This reminds me of JVN at IRI several years ago, standing near the 148 pit, facing a student. He had his arms folded across his chest, one eyebrow was raised, and he shot a faint glance in the direction of the 'bot. The student turned and began fixing some problem that I couldn’t see.

That was a mentoring moment.

John is very likely the author of the passage Taylor mentioned above.

16

As just about everyone has said, it takes a bit of all 3… And quite honestly, the difference in preference between the three can easily be the biggest point of contention between mentors (even mentors on the same team!).

The most important aspect is to figure out what works for your team and your students… and your interaction will probably be somewhat different with each student. Some of the typical “types” of students I’ve seen:

  • The student who doesn’t really need any direction. If they’re in charge of subsystem X, you know they can design and build it without much help, and when they need help, they’ll ask. Generally speaking, with this type of student, you’re working almost on a peer level with them in discussing solutions to problems.
  • The student who is capable, but lacking in direction or confidence. This type of student can “do” it all, and once they have a blueprint of what to build, there’s no question that it’ll get done. However, coming up with that blueprint is difficult, and making the decisions to solve any issues along the way is difficult. With this type of student, you tend to ask more questions than anything else, and help to show them how to make the decision, without actually contributing to the decision.
  • The student who is still learning. Any good FIRST team is going to have students who are still learning (like new members). They often need to be shown how to do things and how to use the tools. It isn’t all about showing, however - you use showing as a path towards letting them do. Typically, I’ll show someone how to do something, then have them do it. This works well if you have to make multiple identical parts, or do the same operation multiple times on the same part, or have plenty of scrap around you can use for examples.

These loose definitions are mostly student-centric, and don’t really address first point in the OP - doing. Doing, for us, is a last resort. We go to it if something simply takes more skill than the students posses, or it would take too long to train them (like welding. We rarely use it, when we do it’s on a very small/limited portion of the robot, and we don’t really have the facilities to teach it safely, so one of the mentors does it), or it would simply take too long for them to do (this last one mostly centered around producing identical parts from CAD, as prior to this fall we didn’t have any students interested in CAD).

Last year, a couple of my students actually commented on a “change” they noticed with me. Previous to that, they had teased me a little that my favorite saying was “I don’t know… what do you think?” - basically, trying to get them to start brainstorming solutions instead of just handing one to them. However, they noticed last year that I had almost stopped doing that with them - they had progressed to the point where they knew everything they needed, they were able to frame their questions correctly, identify the issues, and reason out why possible solutions they considered wouldn’t work. Thus, they had “graduated” from needing directed questions to working on a more peer-like basis.

One last example before I go… A few weeks ago, we were making a small change to our minibot in preparation for an off-season competition. Not a big deal, just moving a limit switch and changing how the limit switch worked. However, in order to do that a small bracket needed to be made to hold the limit switch in its new location. The student working on it had never used the break or shear we had in the build space. So, I showed her how they were used by making something that approximated the needed bracket. I helped her work through making her own based on her measurements, and when we got it over to the minibot, we found out it didn’t quite fit. We talked about why and what went wrong, and she was able to go back to make a second one without much help. After that was finished and she got it in place, we found out it didn’t quite work - the limit switch wasn’t sticking out far enough, something she recognized. So, she went back and made a third one. The whole point is, with this one example, you can see the progression a student can make in just a couple of meetings from needing to be shown how to do something, to being able to do it but needing to talk through the problem solving/design decisions, to being able to troubleshoot and fix it herself.

17

Forgive me for bumping my own thread but, during the cours of looking for another old link, I happened acros a link discussing at what point FIRST mentors go to far. Obviously it does devolve into the usual finger pointing that “successful teams are all mentor built”. I did think there were some good posts in there though.

http://www.chiefdelphi.com/forums/showthread.php?postid=364625