Potential solutions to the imbalance of mentees/mentors

[detrohutt]

Summary (TL;DR)

I use the term participants to mean both mentors and mentees as a whole.
I use the term facilitators to mean members of the Mentorship Working Group.

1. Motivation

• The currently proposed forms of 1:1 and 1:many mentorship seem insufficient to me.

2. The Problems

• 1:many - Too much time demand, possible loss of mentors.
• 1:1 - Too slow, multiple years to work through current mentee pool.

3. The solutions

3a. Optimization - Filter out/triage low-ROI mentees

• This helps by improving the ratio of mentors to mentees.
• Mentees that are expecting general mentorship should be made aware they will not receive it.
• Mentees that are not prepared skill-wise to provide their intended contributions should be directed to learning resources and asked to reapply in the future.
• Mentees that show little enthusiasm or promise of being solid future contributors should be weeded out or at least de-prioritized by requiring some moderately difficult task upfront .

3b. Solution 1 - 1:1 && 1:many

• More mentors are retained/gained.
• This caters to personal preference, gaining more interest from all participants.
• This increases complexity, but I believe this complexity can be managed/reduced.

3c. Solution 2 - Shorter/varying/fluid duration

• Consider a 'fast track' for well-suited participants.
• Consider a queue-based dynamic-duration flow where mentees graduate whenever they meet their goal, allowing new mentees to be onboarded on a day-to-day basis.
• This increases the velocity of the initiative and chances of overall success.
• This increases complexity, but is worth the cost if the complexity can be planned for and mitigated.

4. Conclusion

• These solutions are not 100% ideal, but I believe they are as good as they can be given the situation.
• These solutions will minimize the stressful bootstrapping phase; onboarding help sooner, and preventing burnout of the facilitators.
• I want to help any way I can.

5. Addendum (May 5, 2018)

5a. Preface

• The mentorship program is very important but in a precarious situation.
• I really want to see it succeed so I'm drawing attention to any potential threats to success.

5b. Counterpoints

• It'd be wise to take advantage of the extra time certain participants will be able to dedicate.
• Certain domains/areas of mentorship can be completed in under 6 months, freeing up valuable mentor-time.
• Having the mentorship program cycles coincide with Node release cycles would be nice, but not at the expense of making people wait unnecessarily and potentially losing them altogether.
• Big goals are important for the ecosystem, but the focus can be switched to big goals after the backlog has been dealt with.
• I think there is a sweet spot of worthwhile and manageable complexity to be found to keep the project adaptable and not overly rigid.

5c. Importance of dynamic durations

• This increases velocity and morale (for both participants and facilitators).
• This reduces frustration/loss of mentees on the waiting list.
• This increases the chances of this initiative and Node itself reaching self-sustainability.
• This avoids tensions/pressure on facilitators from waiting mentees, an ever-increasing backlog, etc.

5d. Interpersonal considerations

• Programmers tend to overlook "people problems" and focus too much on technical aspects.
• Projects involving people tend to have hidden complexities, so avoiding known complexities may just present unknown complexities later.
• I'm concerned 6-month durations/waits could lead to a toxic environment that will be hard for the small initial group of facilitators to handle.

1. Motivation

I've been following this repo for the last few weeks and watched the last couple of meetings. In today's meeting, there was a split between the ideas of 1:1 and 1:many style mentorship. IMO neither is ideal in its currently proposed form.

2. The problems

The danger with the 1:many approach (as I mentioned in #43) is it could place too high of a time demand on mentors (as I believe @dshaw mentioned today). This could lead to some mentors backing out, leaving an even worse imbalance.

The obvious shortcoming of the 1:1 approach is that it will take much, much longer to get everyone mentored, assuming 6 month cycles. Even if with a large increase in the number of mentors each cycle (and realistically only a fraction of mentees will want to become mentors), there's a minimum of a few years to get just the current group of mentees "graduated".

3. The solutions

Taking all these things into account, one necessary "optimization", and two specific solutions come to mind. Both solutions are essentially compromises, but I believe that in a non-ideal situation non-ideal solutions must be considered.

3a. Optimization - Filter out/triage low-ROI mentees

ROI means return-on-investment, or how much value is received compared to the effort put in.

This will help universally as it improves the ratio of mentors to mentees. There are two metrics I'd use to determine a low-ROI mentee: intentions and level of interest.

Misguided intentions

As has been mentioned in the meetings, there are mentees in the current pool who are expecting general mentorship as opposed to help getting involved with Node.js specifically. The solution here (IMO) is to make it clear to them that this will be very Node-centric while catering to their current skill level (anyone can help write docs!). Potentially (but I'd recommend caution) it could be explained that the mentors can provide or point to resources for learning. But IMO people who aren't capable (technically/skill-wise) of providing the kinds of contributions they intend to make should be pointed to something like Free Code Camp and asked to come back when they're more prepared.

Low level of interest

People who have only a casual interest in being mentored are less likely to make up for the effort invested in them with their (probably also casual) contributions. IMO the first cohort should be hand-picked to be the "most likely to succeed", possibly through pre-existing GitHub track record contributing to other projects. Preference should also be given to those who express interest in becoming mentors in the future.

It's easy to fill out a form, and that's why there are currently hundreds of mentees enrolled. It's harder to learn new things, put in sustained effort, and work with other people (soft-skills). There's a simple solution to weeding out people who aren't all that interested: ask them to put in some effort upfront.

Even asking them to introduce themselves would probably be enough to weed out some people, but I'd recommend something along the lines of requiring a short entrance essay (like most colleges do) on why they want to do this, what they expect out of it, etc. It'd also be useful to require them to take part in some group activity like helping design/brainstorm the potential group projects that have been mentioned. The group thing would be hard to quantify though, so that may or may not be feasible. These are just ideas off the top of my head. Better specific tasks could be worked out later.

These requirements should be met prior to beginning the matching/pairing process. Anyone failing to meet the requirements forfeits their place in the current cohort and may reapply to the next.

3b. Solution 1 - 1:1 && 1:many

Different mentors/mentees (I'll call them participants as a whole) have differing amounts of free time. By enforcing a strict minimum time investment, mentors with less time to invest are alienated. It's like taxes. The higher it's raised it, the more people are going to move on.

Pros

The upside here is less loss/ more gain in interest from mentors.

In addition, personal preference is a factor. Certain participants would prefer a 1:1 mentorship, while others prefer 1:many. Giving them the choice makes all participants happier.

Distracting but entertaining GIF

Cons

This increases the complexity for the Mentorship WG members (I'll call them facilitators) in implementing the program. As programmers we know that complexity is evil. But we are also adept at finding ways to reduce it. I won't pretend to know the specific answers here as I'm not directly involved in the WG, but I suspect the members could come up with some appropriate countermeasures. I'd be happy to join the conversation if I can help. One general piece of advice is to find ways to leverage the participants as much as possible to help them act as their own facilitators.

3c. Solution 2 - Shorter/varying/fluid duration

Contents retracted after clarification

I wasn't following this group when the 6-month duration was decided on so I'm not aware of the reasons behind it, but IMO it's too rigid and too long. Mentees are going to have different levels of pre-existing knowledge and participants who spend more time actively involved in the process need less time to reach their goals.

Consider Person A and Person B:

Person A is new to GitHub and created their account just to join this mentorship program. Likewise they have minimal skills in programming.

Person B is a veteran programmer with dozens or even hundreds of merged PRs to smaller repos and simply has never contributed to Node and doesn't understand the more rigid processes surrounding PRs (I'm in this category).

It doesn't make sense to me to put both of these people in a 6-month mentorship program. Honestly, unless the intention is to teach people technical skills I don't really understand how it takes six months to teach them to make PRs in this ecosystem. I know the members of this group are all intelligent people, so I'm sure I'm missing some context.

If it's at all feasible (even in some limited capacity as a compromise), I recommend some level of relaxation on this prescribed duration. A 'fast-track' for people like Person B with smaller goals or more pre-existing knowledge seems like a doable compromise to me. Perhaps certain mentors would like to take a group of such people since they'd not need much hand-holding (time investment).

Another possible way to implement this is to have a 'rolling cohort' (described as 'fluid duration' above) with people constantly coming into and graduating the program. Mentees would graduate once they reach whatever goal they and their mentors decided on (whatever they felt they needed to be comfortable contributing to Node).

One implementation could be this:

There is a queue of mentors available. A 1:1 mentor is assigned (or ideally, proactively finds) a matching mentee, works with that mentee to the completion of the goal, then returns to the queue for another mentee.

A 1:many mentor is assigned (or gathers) a group of mentees around a group goal, helps them all complete that goal as a group, then returns to the queue to form another group.

Pros

This could rapidly increase the number of mentors and simultaneously decrease the backlog of mentees, which would combine to greatly reduce the time needed to reach 'critical mass' where the mentorship program (and hence the Node ecosystem) becomes self-sustaining. This is huge. As a nice organic benefit to this, the best future mentors would graduate (and start helping) the earliest, giving a really solid 'early-game' boost to resources (people on hand).

Cons

The cons are basically the same as for Solution 1: added complexity. I feel like this solution adds less complexity than the other overall. Mainly there's just a queue or some other flow mechanism to be maintained and/or moderated. This could be mitigated by offering a specific path of mentorship (kind of like a college major) for Moderation. As moderators are trained, they can help moderate the queue, taking the burden off of the facilitators.

4. Conclusion

As I said, these are definitely compromises, but I think that's all that can be hoped for under the circumstances. Beginnings are hard. No matter how this initiative is implemented, there's going to be a lot more facilitating to be done than there are facilitators to handle it. At least with these compromises, that 'bootstrapping' period will be much shorter, with new mentors and moderators becoming available potentially in days or weeks instead of half a year. I think it's very important to keep the velocity up so facilitators don't start burning out. If they burn out, the initiative will fizzle out.

As I mentioned in #38, I want to act as a force-multiplier. I'm a decent enough programmer, but I'm just one programmer. Improving the efficiency of the mentorship program means faster, more effective onboarding of hundreds or thousands of programmers (and other important roles), many better than myself. As such, if there's any way I can help with this initiative (besides opening overly long issues lol) I'm more than happy to.

5. Addendum (May 5, 2018)

Having received some clarification on things, I'd like to address a few points from the below comment I hadn't taken into account and give my thoughts.

5a. Preface

I think in terms of long-term impact on the future of Node.js, this mentorship program is the most important thing happening right now. I really want to see it succeed. I dislike playing devil's advocate, but with such a small group of facilitators, I think the future of this initiative is in a precarious situation, and I feel the need to draw attention to potential pitfalls that threaten to derail the program.

5b. Counterpoints

The following are all valid points. However, I don't believe they are universally applicable. I think each has exceptions that could be capitalized on to mitigate the issue at hand.

Mentorship is a lengthy process as mentors and mentees only meet a few times per month

Some mentors will be willing and able to meet more than once or twice a month and some mentees have more time to work independently as well. Determining the people that fall into this category ahead of time and pairing them together would make better use of their time (like hyper-threading on a CPU, less dead space). The mentor could move on to other mentees, and the mentee (now graduated) could move on to other goals.

Mentorship goals are by nature a little lengthy (joining a certain WG, or contributing to a certain area in code etc)

mentees with goals to join working groups and initiatives will need a duration of at least 4 months to become accustomed to the process, meetings, people, and hence become effective.

These are specific to certain domains. I'm sure there are areas people want to be mentored in that would not require this amount of time (contributing to documentation?), and again, any mentor-time we can free up can be leveraged to work through the backlog of mentees more quickly.

6 months work nicely with the release schedule of node ... which is the duration of which mentees can have a goal to become part of bringing it to the LTS stage.

I understand the appeal here but I'm not sure the payoff is worth the cost. I don't think there's a risk of losing any mentees if they don't get to contribute to LTS on their first go, and under the current plan, a lot of people probably are going to have to spend 6 months just waiting for the next cycle, not getting to contribute at all.

setting a 6 months goal indirectly mandates the mentee to set a decent sized goal. Big goals are good to have in order for the mentorship program to have the most impact on the node.js project.

This is true in the long-term. But in the short-term and due to this "imbalance" issue, I'd argue it's more important to get the most people possible contributing at all.

Many mentees who have to be left out of the first round will get frustrated (or move on to other open-source projects out of boredom) if they have to wait 6 months, especially if they feel like the long wait is due to a flaw in the program's design that could have been avoided.

IMO once more people are contributing and there isn't a huge backlog, then big-impact goals should definitely be a priority, just not at the cost of losing lots of potential contributors early on.

While dynamic times solve many issues, my limited experience tells me that simplicity is much better than having lots of options.

I totally agree, but there is a large spectrum between "lots of options" and "no options", and I think there is a sweet spot to be found. Complexity has to be managed, but some complexity is worth the cost, especially if it can be reduced to an appropriate level through discussion and planning.

5c. Importance of dynamic durations

The payoff of dynamic durations can't be overstated. It would vastly improve the momentum/velocity/morale of the initiative and reduce the frustration/loss of mentees on the waiting list. Most importantly, it would increase the overall chances of the initiative succeeding and reaching self-sustainability rather than fizzling out due to tensions/pressure on facilitators from waiting mentees and an ever-increasing backlog, etc.

5d. Interpersonal considerations

As programmers I think we tend to overlook "people problems" (emotions, morale, etc) when planning. We tend towards focusing too much on the technical aspects of a project.

In my experience (and especially when it involves people) what seems simple in the planning phase turns out to have hidden complexities in the implementation phase. So by trying to avoid certain known complexities that can be planned for, other unexpected complexities may arise when it's much harder to do anything about them.

As a specific example, the "simplicity" of static 6-month durations IMO could easily lead to the complexities of a toxic environment, especially for the small group of facilitators, and because it's a small group, it'd be harder to plan for handling unrest in a large group of people than it'd be to plan for a mechanism for addressing those peoples' concerns ahead of time.

[Bamieh]

This is awesome, you illustrated the issue really well, thank you!

The idea of having both is a little intimidating for me, especially for the first round.
Group mentorship requires us to have some sort of cohort for the program, which we tried to avoid.

A middle group might be to have some goals as "1 to many" like joining a certain WG or initiative etc. And some goals are "1 to 1" like learning and contributing to a certain area of node code (c++, javascript, enhancements, tests, v8, tooling etc).

I chose 6 months duration for the following factors:

• Mentorship is a lengthy process as mentors and mentees only meet a few times per month. I have to highlight that mentoring is not teaching, it involves guiding people to where to find resources, and provide context in the areas of interest so the mentee can move forward.
• Mentorship goals are by nature a little lengthy (joining a certain WG, or contributing to a certain area in code etc)
• mentees with goals to join working groups and initiatives will need a duration of at least 4 months to become accustomed to the process, meetings, people, and hence become effective.
• 6 months work nicely with the release schedule of node, check it here https://github.com/nodejs/Release. for example, node 10 will reach LTS in about 6 months, which is the duration of which mentees can have a goal to become part of bringing it to the LTS stage.
• setting a 6 months goal indirectly mandates the mentee to set a decent sized goal. Big goals are good to have in order for the mentorship program to have the most impact on the node.js project.

While dynamic times solve many issues, my limited experience tells me that simplicity is much better than having lots of options.

I labeled this issue so we can have it discussed in the next meeting.

[detrohutt]

Thanks for the fast response, and the additional context. Everything you listed makes a lot of sense. I'll revise my ideas to take these things into account.

Would it be possible for me to be an Observer at the next meeting? As I understand it, @mhdawson and @bnb are going to be having me join their meetings but I'm not sure when that will be or if this meeting is included in theirs.

[Bamieh]

@detrohutt meetings happen every two weeks, the commcomm meetings happen on thursdays while mentorship meetings happen on fridays the day after, both at the same time (4 UTC). You can follow the node.js calendar to get notified on the meetings. Also we always open issues for the meeting agenda some time before the meeting

[detrohutt]

@Bamieh I have permission to attend then? Or should I open an issue requesting approval to be an Observer?

[Qard]

Another possible approach would be rotating sync availability. For example, a mentor could take on 4 mentees and give each a week out of each month to have greater availability for sync meetings. That could mean one meeting each week, or more--whatever the mentor is able to commit. When a mentee is outside their sync availability cycle, they could chat via Slack or Twitter and get an async response when the mentor has time.