Mentorship Philosophy

This one goes out to all the mentors out there…

I’ve spent a lot of time meditating on mentorship lately. Specifically in regards to:

  • What lessons am I trying to teach my students?
  • How do I convey these lessons?

I have a pretty good idea on my philosophy for mentorship, and took some time to outline it here:
http://jvengineering.blogspot.com/2010/11/mentor-philosophy.html

I’m wondering… what is YOUR mentor philosophy?
What lessons are YOU trying to teach your students?
How do YOU convey these lessons?

I’ve seen elements of this discussed in the past, but I thought it was an interesting topic to rehash in more detail. Lots of people talk about this sort of stuff in reference to other discussions, but rarely directly.

Discuss… :slight_smile:

-John

Wow John, excellent post, lots of great insight for a “young mentor” like myself.

I’ve said this to enough people I’ve worked with in FIRST over the years, that I guess you could call it my “mentor philosophy.”

FIRST is not just about learning, nor is it just about having fun. It is about learning that this stuff is fun. A mentor’s job is to teach this principle.

And I agree completely that everything follows from there. If I ask myself why I solve problems…its because I have fun doing it! And If I can show students that, then they’ve started down the right path.

I try to do this, first and foremost, by making it clear that I’m having the time of my life working on robots! Sports fans watch their team celebrating like crazy, and follow this behavior. Students can see an engineer having a great time solving a problem, and will follow.

I try to also give students as much firsthand experience doing the actual problem-solving as I can, by leading them towards answers, rather than giving them. Say, for example, I see a prototype, and have a suggestion for improvement. I don’t say anything just yet. I’ll back up a minute, and go through a thought process of “now, what triggered that idea in your mind?” Then, ask students leading questions about the problem (“Is it working quite as well as you would like” “Where might you be losing energy?” “What type of device could you use to increase torque” “Is there any reason you couldn’t use that?”) based on the process that I went to to find my idea, until someone goes “aha!” Sometimes, they’ll go aha! the way I did, sometimes it will be a different, and possibly better, solution. Either way, that student just got the joy of going “aha!”

And just as I talk in questions, I try to get students to ask “why,” “what could be done differently,” “could you do it this way?”, etc. constantly. Because asking questions will lead them to answers. Discovering answers will lead to problem solving. Problem solving leads to having fun with problem solving. Which is what we’re after.

In a nutshell, my philosophy is to “trick the students into figuring out that engineering and problem solving can be fun”. I try to do that by instilling a real desire to win in the competition, which hopefully makes them have a real desire to solve whatever problems are required to make the robot have a competitive advantage. Somewhere along the way they’ll realize how fun it can be to solve complicated problems. I hope that experience will make them realize that education gives them the tools to make a life out of problem solving.

Anyway, that’s the cliff’s notes version.

Excellent description John. I loved it. :slight_smile:

I cannot speak on behalf of a professional mentor, considering I do not have enough experience to state a possible philosophy. I have, however, thought about this topic before; Saying that, I have some thoughts as to what I personally (other people learn may think otherwise) think a good mentor should consist of, from a student standpoint.

*Material should be presented in a simple manner, and then later into further detail. You should not overload students with intermediate information, otherwise students may get too confused easily.

*Showing through example I feel is an efficient way of learning. Programming for example, it may be wise to show the students the entire code, how its written (the basics of programming), and then another day try to have the students write their own code. With examples, students can see physically how to do something, and it may be easier to follow than verbally describing the steps in order to complete a task.

*Learning should be fun, I do agree, but to a certain extent. Many teachers that I have learned a lot of information from have been strict and on point with their schedules, but they make the material fun. With making learning fun, you can reach out to kids, as previously stated, and tell them the true importance of what the material is. Students may also intake information better if it the environment is exceptional. With solely lecturing information, students may get bored easily, and won’t express the interest that mentors may desire.

These are my thoughts. This is just my perspective.

Wait, what?? We’re supposed to be inspiring the students? I’ve had it backwards all these years.

this is a philosophy that I was taught as a student on a team. As a mentor now I still follow these four steps.

  • Mentor Does - Student Watches
  • Mentor Does - Student Helps
  • Mentor Helps - Student Does
  • Mentor Watches - Student Does

each student is going to need different times for each step, but try and have as much conversation(fum) as possible well working with the students.

Powerful thread here John. Thanks for starting it. I was struggling with how I wanted to answer this last night, so I slept on it. Then this AM, while searching for something else I stumbled upon a file I put together a few years back called “Pauschisms” which are quotes/excerpts taken from the late Randy Pausch’s book and presentation titled The Last Lecture.

In general, and very honestly, I’ve come to learn that it’s my life’s work (regardless of what I might get “paid” to do) to inspire and enable dreams for as many people as possible on this planet in the most efficient way possible using the talents and energies I possess. With that in mind, some Pauschisms that heavily influence my mentoring…

Chapter 3 – “…when there’s an elephant in the room, introduce it.”
Chapter 4 … “Just because you’re in the driver’s seat, doesn’t mean you have to run people over.”
Chapter 5 … “Anybody out there who is a parent, if your kids want to paint their bedrooms, as a favor to me, let them do it. It’ll be OK. Don’t worry about the resale value on the house.”
Chapter 7 … “You’ve got to get the fundamentals down, because otherwise the fancy stuff is not going to work.”
Chapter 7 … “When you’re screwing up and nobody says anything to you anymore, that means they’ve given up on you.”
Chapter 9 … “So what was Kirk’s skill set? Why did he get to climb on board the Enterprise and run it? … there is a skill set called “leadership.””
Chapter 9 … “I don’t believe in the no-win scenario.”
Chapter 11 … “The brick walls are there to give us a chance to show how badly we want something.”
Chapter 11 … there are right and wrong ways to say “I don’t know”, “I need more information”, etc

In thinking about the mentorship philosophy, I determined first what it is not. It is not coaching. Coaching is directing a person or team towards a specific goal or purpose, using skills to achieve that goal or purpose. Mentoring is different. It is working with a person or group in ways that help the person or group develop in setting goals and striving towards success. Success can be in the forms of bettering oneself, clarifying goals/life goals, building a strong foundation on which to continue to grow and develop. Mentoring doesn’t necessarily end when goals are achieved but can continue on by evaluating achievements and developing new goals. To me, it has potential of spiraling upwards through different levels of growth and development.

Tools used in mentoring would include communication, respect, goal setting, aha moments, and recognition of growth and development. Sometimes, the recognition does not come until later but it usually always shows itself. I think of the WFFAs and WFAs as proof of that.

Good thread, John. I hope you have many many posts from our valuable mentors.

Jane

I love FLL. But I’ve always been a little confused by the coach designation in that program. To me, there may be some coaching that happens in the course of mentoring, but they are different.

And FIRST then lumps the titles “Mentor/Coach” together for various purposes. Like they are interchangeable.

Anyway, I agree. They are not the same. Thanks for bringing this up!

I’ve got some input on mentoring, but would rather learn from others right now so will be following this thread closely.

I understand the coach comments, but all of my best coaches (sports, mostly) in life have been mentors. All of my mentors have not been coaches, though … anyway back to the thread I want to read more from others here… :slight_smile:

John, I imagined you dropping your arm like the ref at a prize fight when you commanded us to “discuss” :slight_smile:

Philosophy:

  • convey the excitement and rewards of engineering by by trying to be a great engineer for the team
  • try to set the bar high, because the best students will meet it
  • try to support the students who are new and learning

Lessons:

  • winning isn’t everything - trying to win is the important thing

  • by saying “we are trying to win” we are saying that we commit to preparing ourselves to win

  • when we prepare ourselves to win, we must: be on time, support the team by doing our role, practice, work hard, and get good grades (A’s not B’s)

  • if we have prepared ourselves to win … we have won

  • it may not be fair, but people who don’t know you will judge you by your grades

  • if you have below a 3.0, I can’t hire you

  • come back and see us so we can hear stories about what you have done

I would like to say that although I am not a mentor, I agree with all that has been said on this thread, particularly the parts about mentoring not being coaching. If all FIRST mentors and advisors followed this, students would get more out of the experience and teams as a whole would improve.

I tried to answer this question as a first year trying-to-figure-mentoring-out person, and realized I don’t really have it well articulated from that standpoint–especially the “how” part. So then I tried to answer it as a former student and go from there. I’ve been blessed with some great mentors, and that question was a lot easier.

What lessons did (do) I get from my mentors, and how?
I think the biggest one, though certainly by no means complete, is simply how to get inspired and grow up. I probably sound pretty young, which I am, but I do feel a lot older psychologically than when I started FIRST. (I started significantly younger than my age psychologically for another reason.)

As for how they did it, maybe they’re just subtle - those sly dogs - but I feel like they didn’t really go into it with a specific structure or even conscious goal. And I honestly don’t think it would have worked if they had (any less subtly). I was just looking for role models. Show me what a great project manager looks like, and let it bite me when I get it wrong. (I’m a big believer in learning from failure.) Stand up a be a great engineer and let me work next to you.

So now for the other side. Based partially on what I got, what am I trying to teach my students?

  • Get inspired about something. Do what you love and love what you do.
  • Learn, accept, and grow from failure. In fact, do it often and early.
  • Learn and grow a little everyday.
  • Enjoy solving problems and striving for improvement.

How do I convey this?
I’m fuzzier here. Role modeling as best I can, definitely. Other styles, I’m not really sure. I’m ok at explaining material and do so a decent amount, but that alone doesn’t seem to meet the definition. I’m not sure at this point. I am, however, learning–students make excellent teachers. :wink: Ask me in a couple years. (In the mean time, we’ve got plenty of veterans who really don’t need my help anyway.)

EDIT: If anyone’s interested, I started a thread asking this question from the student side: Lessons from Mentors.

John et al,
I think there is a big difference between mentor and teacher. I admire the teachers out there for the work they do everyday. Teaching is an efficient and effective method of transmitting a large amount of information and checking that the students have retained it. Mentoring is different in that the process is not very efficient, sometimes it is ineffective and the checks are largely self imposed by the person being mentored. A good mentor realizes that the life of anyone that they meet is forever changed. That change can be good or bad but it is the responsibility of each person to try and make that change a good one. Mentors make the greatest impression when they are living what they are teaching. Whether that is imparting engineering principles or simply a way to work with others. A mentor knows that each of us is different, that we learn at different rates, using different techniques. A mentor sees the obstacles and works around them to help the mentored learn something new. For those mentoring in First, it is imperative that we realize that a student in an 18 year old body is going to act like a 12 year old every once in a while. We need to remember that so much information is pushed at our students that they will forget what they learned last year and will need some retraining. A mentor will need to know when a question is a better path to learning than a lecture. They know that sometimes, it is necessary to just walk away for a few minutes to leave the student alone in their thoughts. Above all, we must remember to award success, encourage learning, and find real answers to questions even if unrelated to the project.
One of the greatest moments as a mentor came when I was a Webelos Scout leader. We had bought the boys tool box kits. My assistant and I felt that the boys needed to push themselves a little so we announced that we would not be showing them how to assemble the tool box. We would provide hands to hold parts together and demonstrate tools use but would not go beyond that. We had one boy who was very stressed that he would not be one to finish the project. We encouraged him to read the instructions and perform each step. When the evening came to an end he brought his toolbox over and informed us that he had no more parts. I asked “Does it look like the picture?” and he replied “yes”. Then I told him, “I guess you are done.” He replied “This is the first thing I have ever done that I didn’t screw up.” There was a genuine change in his face, a pride, a knowledge of self worth. It is times like that when you know you have connected somehow.
In the big scheme of things, life is a path you travel. People are coming at you from every side. Some are bumping you onto a deadend path, some are bumping you onto long and hard path, some are turning you around to retrace your steps. I have been very lucky that the bumps that I have received kept me on a pretty straight line. I thank God for that every day.

I’m pretty limited in my mentor abilities, so I focus on one main idea and one secondary idea.

My main thing is to teach problem solving. How to look at an abstract task (like the game) and come up with multiple possible solutions. How to weigh each solution to come up with the best suitability. Once that solution is underway either as a proof of concept / prototype how to test it to see that it’s working. And when it doesn’t work as expected how to diagnose and resolve the issue. And once the solution is in place and it breaks on how to decide what’s broken (diagnostics) and how to fix it. In short, I’m trying to create a new wave of Sherlock Holmes (minus the meerschaum pipe). Problem solving is a life skill that pays off over and over.

Secondary to that is the concept of “if you do it right the first time, then you don’t need to go back and do it again”. Everybody says “I’ll go back and fix it later”, but that time never comes. Part of doing it right the first time is thinking through the design, the process steps and what the final product needs to look at. The two key elements are “Hope is not an Engineering Strategy” and “neatness counts”.

“Hope is not an _____ Strategy” is my favorite Mad-lib. Works for most things: Design, Engineering, Project Management, etc. I try to push for less hope more know. If you know what you are doing and why you are doing it, less chance that it will be wrong and you’ll need to do it over again. Thinking is easy. Doing stuff on paper or in a CAD package takes less time than making a new one. Thinking the steps out means work happens in an efficent manner taking less time and effort.

“Neatness counts” covers “measure twice, cut once”, “measure with a measuring device” and “no, to the nearest 1/2” isn’t good enough". Sloppy work means that you either don’t know what you are doing (no design) or you don’t understand why it needs to be right (transmissions to the nearest 1/2" don’t work well) or you don’t care (why are you here?)

One other thing that I do bring is a level of enthusiasm. I love what I do for a living, I love working on robots from design through build and programming and into the competitions. It’s fun. Every night I ask my roboteers three questions: Did you learn something? Were there any safety issues? Did you have fun?

Nice video just posted to youtube the other day about Mentors…