Re: mentor:student ratios, team mentoring, etc

[Daniel Powell <daniel@2kreate.com>]

Dan! Thank you.

Seems there are a lot of us Dan's going around. (I go by Daniel but am often referred to as Dan).

>Why do you thing that having a lead mentor would inhibit students from
>reaching out to the other mentors?  I don't think that student-mentors
>communication should be mediated by the leas mentor.

I'm going to run through two scenarios that we had run into at a repair shop that I used to manage. Keep in mind that it was ABSOLUTELY critical in this environment to have an inexperienced technician ASK QUESTIONS when they were uncertain about a repair procedure. So, this environment differed somewhat from the software engineering atmosphere where critical vehicle systems are not involved, but important parallels can still be drawn.

In both scenarios, we'll assume the following two things (for simplicity):

=> There are two mentors and one apprentice

=> There is a clash of personalities between one of the mentors and the apprentice that causes the apprentice discomfort (Maybe we can imagine a mentor who scoffs/scorns at questions).

=> The apprentice is new to team dynamics

Scenario 1:

A new apprentice is assigned directly to the mentor with whom he/she is not comfortable with. During their first interaction, the apprentice asks a question that seemed obvious to the mentor, and the response is interpreted by the apprentice as rude or degrading (even if it wasn't actually). Because the technician was assigned to the mentor, they are more likely to avoid asking important questions/engaging in the mentoring process to avoid discomfort, and by the end of the first week is frustrated, uncomfortable and most importantly has not asked critical questions of the mentor. The apprentice does not go to the other mentor to ask questions because he's been assigned to a mentor and does not want to offend his mentor by circumventing him.

Scenario 2:

A new apprentice is introduced to both mentors and told that he is free to ask either for help. He has the same experience with mentor 1 as he did in the first scenario. He runs across a critical issue and feels more comfortable approaching the other mentor. He goes and asks mentor 2 for help. It happens that mentor 1 is the specialist in this area, so mentor 2 (who probably knows that mentor 1 has less than ideal social filters and a temper) has a short conversation with both mentor 1 and the apprentice (in a software team this conversation would be an email to both parties/CC) simply saying "Hey, mentor 1, I noticed the apprentice is struggling with this. What is you input on how he should move forward?" and hands the conversation over to mentor 1. If the question that the apprentice had was silly or obvious, the 2nd mentor can help filter that out, or help phrase the problem for mentor 1.

The difference in time allocation isn't much, mentor 1 still handles the issue when it's in his expertise. Often times (in software engineering and automotive repair) mentor 1 is older, more skilled and less tolerant of stupid questions, mentor 2 is not a rookie, but not an expert and is more tolerant because he can still remember what it's like to be wet behind the ears. In essence, in scenario 2, the apprentice was still assigned to mentor 1. He just didn't KNOW he was assigned to mentor 1, to increase his ability to ask questions freely and comfortably. This subtle distinction helps increase learnability within a mentoring program (measurably in automotive repair - it decreases apprentice technician turnover within their first 6 months and more importantly decreases critical errors. 

Let me be clear: It may not be necessary or beneficial to apply these principals to software development teams because it ISN'T critical like it would be if the apprentice was repairing your mother's brake system. But, there is something to be said about being more comfortable learning and participating in the process. It may be worth trying on a small scale to see if it improves outcomes. It may turn out that it's not for other reasons, as you stated. 

ALSO worth noting, is that the discomfort with working with someone wears off quickly once an apprentice is used to working in team dynamics. In other words: if an new/rookie technician has already worked in team environments, it's likely that this wouldn't be as important. I noticed that with those who have no experience with teams, this piece is absolutely critical for the first 1-3 months.

Sorry if I drew that out far past the subjects' worthiness. Happy coding to all!

Daniel Powell

On Mon, Mar 19, 2018 at 12:56 PM, Daniele Nicolodi <daniele@grinta.net> wrote:

On 17/03/2018 00:11, Daniel Powell wrote:
> I wrote a blog post with some input about how to structure mentorship
> teams from my experience as a service manager in automotive repair (of
> all things). I put it into a blog post here:
>
> https://www.2kreate.com/index.html#Post-Mentorship

Hi Daniel,

I finally found the time to read you blog post [0].  I appreciate your
point of view.  Quoting from your blog post:

> I would, however, avoid assigning a mentor as a lead for a student
> in this format. It makes the barrier for reaching out to the other
> two mentors too high (especially for those who are relatively new to
> a team dynamic).

Why do you thing that having a lead mentor would inhibit students from
reaching out to the other mentors?  I don't think that student-mentors
communication should be mediated by the leas mentor.

I think that having someone responsible for the project, in the
"bookkeeping" sense, could be an advantage.  However, I'm mostly
familiar with the mentoring/supervising in academic context, and not at
all with the GSoC format, thus it may be the case that most things
should happen by initiative of the students and mentors are not supposed
to be actively checking over the progress of the project.

Cheers,
Dan

[0] You have a typo in the post: s/ass/as/