Getting Mentorship Right in Open Source


Thanks to pdurbin and moongazer in #openhatch for the original discussion, and pdurbin again for some good edits to this post.

I was party to a great discussion on IRC today about the disconnects in expectations that can make creating great mentor/mentee relationships difficult. This post is an attempt to capture some of my own thoughts and correct some misconceptions.

A Mentor's Perspective

I'll begin by explaining what mentoring looks like from the mentor's perspective. This is something most prospective mentees don't usually think much about, because they haven't yet gotten to this stage. Understanding your mentor's needs and concerns can make the process of getting good mentorship make more sense.

A good mentor is busy. The people who make the best mentors are people who aren't just competent at what they do, but the combination between a top performer, a good communicator, and the type of personality who is themselves always learning. This is a recipe for being busy, all the time.

Good mentorship is labor intensive. Mentoring costs a mentor time and energy. Because good mentors are busy people, these resources are already at a premium. Too often, mentees don't understand that mentorship is, on the part of a mentor, an investment of a precious resource.

The time and energy a mentor spends on a mentee is taken from his or her own work. Because good mentors are so busy, and mentoring so labor intensive, it naturally follows that resources for mentoring come from the reserve the mentor has for his or her own projects, goals, and responsibilities.

Mentoring others is essential for ambitious people. If we don't mentor, we don't have a reliable source of successors. Thus, we either have to drop responsibilities on the floor, allowing things we cared enough to build, fix, or nurture to die, or stay in the same roles forever instead of evolving and growing ourselves. Mentoring solves this by creating a pool of people we can trust to hand our work off to when we move on, or when projects and organizations grow in scope.

Mentoring is how many pay it forward. OSS isn't new any more. Many contributors have built fulfilling hobbies and even careers from the foundation of our open source learning experiences. Some repay that benefit to the community by providing learning opportunities for those who come after.

A Method to Mentoring

Good mentor-mentee relationships do "just happen"...once in a while. However, the need for good mentoring in many fields is greater than what will crop up due to chance. There is a method to making these relationships happen.

Step 0: Common Ground

The first step in getting yourself a good mentor is to meet enough senior people in your field to "click" with someone. This means attending conferences, corresponding with authors, joining IRC and similar venues, and really participating were you can be seen.

I met some of my early mentors by stumbling on to IRC and USENET, participating in discussions, and asking for help from people involved with the projects I was contributing to.

Peter Thiel picked up his aide-de-camp Blake Masters after Masters attended one of Thiel's lectures at Stanford in 2012. Masters took detailed notes from the class, and circulated them far beyond campus. Ultimately, Masters and Thiel worked together to turn the material into a book.[1]

Often, formal mentoring programs do a worse job of this kind of matchmaking than informal professional networking, because they presuppose an investment by mentors without any pressure on mentees to give back. Additionally, they'll usually make a bad match rather than fail to match someone.

Step 1: The beginning is up to the mentee.

This is an especially important point to drive home today. One of the core expectations in Open Source communities is that new people will periodically show up and start doing things. Unfortunately, many of the young people looking for Open Source mentorship have grown up in a world without pick-up games of this or that, dominated instead by organized activities with registrations and applications before anything happens. Often, new contributors don't contribute because they can't figure out where the gatekeeper is they should get permission or assignments from, when we don't believe in gatekeepers at all!

I cannot emphasize enough that beginning a mentoring relationship is in the hands of the mentee, not the mentor. It is up to the mentee to:

  1. Find a mentor you "click" with, who makes you think "I love how this person thinks about $subject."
  2. Court their mentorship by doing work they will care about, and take a "work first" attitude toward being a mentee.
  3. Reach out to your prospective mentor. Understand that a mentoring relationship is built in stages; don't try to make it happen all at once.

Step 2: Work first.

Beginning the relationship with work on the part of the mentee demonstrates to the mentor that this mentee is a good investment, rather than yet another beggar trying to get something for nothing.

Remember: you are asking a mentor to take time away from their own work and give it to you. A wise mentor won't do this for everyone who asks--they'd fall down from exhaustion--instead, a wise mentor will invest in those who show good follow-through, and will give back to the mentor's activities. This lets the mentor know that the resources they are investing will actually result in learning, and also serves to offset the cost of being a mentor.

Concrete examples of this include:

  • Taking great notes from a talk or presentation the prospective mentor gives and adding value to it by putting the content into a more easily shared form, translating it, or doing a case study about how you put it into action yourself.
  • Fixing a few bugs or updating documentation for a project the prospective mentor maintains.
  • Hanging out on IRC, Mailing Lists, etc. for the prospective mentor's projects, and contributing to discussion, answering questions.
  • Helping triage issues in the queue for the prospective mentor's project.
  • Find something the prospective mentor has written about, try to apply it, and write up a blog post or article on your experience, perhaps reaching out to the prospective mentor to let them know you did it, or for a quick review near the end of the process.

Step 3: Growing the relationship.

One you gain a mentor's attention, expect that work on both of your parts will be needed to make a mentorship relationship work.

Regular communication is essential. Whether you correspond by email, have regular phone calls, or catch up via IRC in the course of working on a project together, mentor and mentee should always know when and how the next regular communication is coming.

Having a shared project is the most effective basis for long-term mentoring relationships. When a mentee devotes time and effort to work that matters to the mentor, this provides both needed labor for the mentor, and a problem set for the mentee with which the mentor is intimately familiar.

It's important for the mentee to understand that having a mentor is not having an instructor. In an instructor-student relationship, the instructor's primary work is the progress of the student, in fact they are paid specifically for this process. An instructor is in command of the student, to some degree, and is charged both with teaching and with evaluating.

A mentor, by contrast, is a colleague of more experience than the mentee. A mentor can offer guidance and help with problem-solving, but they are usually compensated by the mentee's contributions of time and skill, and are not charged with grading the student. The only measures that matter to a mentor is whether they feel the relationship is worthwhile, and perhaps when the time comes, what they are comfortable delegating to the mentee.

Below, I lay out a description of the evolution of a mentoring relationship, but please don't take these stages as rules. This is merely a model that I find fairly reliable to play out. There are others just as good, and I deviate from this often, playing mostly by ear.

  1. Matchmaking... The first thing is to form a relationship, get to know one another. This can happen in person, or through correspondence, whatever. Establishing mutual interests and a personality fit is usually pretty natural for both parties.

  2. Coaching... Some arms-length coaching tends to be the beginning of a mentoring relationship. This is one of the lowest-overhead forms of mentoring. By "coaching", I mean a form of mentoring where the mentor offers the mentee suggestions on reading or practice, and the mentee will follow up with questions or concerns, or requests for advice, to talk through with the mentor. A wise mentee will take special care not just to pick up chances at skill-building, but to get hold of the culture and history of the discipline. This is especially important in open source communities, as we draw from so many cultures and backgrounds that our shared history and culture, communicated through time in science fiction, technical writing, April Fool's jokes, and more give us needed common ground.

  3. Close-in Mentoring... This is the point where the mentee has taken up a role in one or more projects of the mentor, accepting delegation of tasks and working some coaching into the fringes. The mentee, at this stage, is expected to have the maturity to undertake some self-development and exploration, mostly leaning on the mentor for new challenges and for feedback when they find themselves stuck. A close working relationship means that much of the mentoring just flows from project-based interactions.

  4. Succession Planning... A mature mentee will eventually be included in the mentor's succession planning. Building leadership--technical or social--in those below them is every mentor's job. We shouldn't allow ourselves to become a bus factor[2] of one for any project, and additionally some of our projects or organizations will grow to a complexity where more than one-person leadership is needed.

Attracting the Right Mentee

A word now for prospective mentors, on finding the right mentee or mentees.

I personally believe in having more than one mentee whenever possible. This helps one to avoid the failure mode where one becomes over-invested in another person's path, prone to providing unreasonable levels of direction or even pressure. It feels like your one mentee weighs more heavily on your own reputation and abilities, where that same person making mistakes or going a different way than you'd hoped is far less stressful for the mentor if they are one of a few mentees.

Having an incoming pipeline of possible mentees involves getting out there in the world. Sending your writing, code, or other works out into the world often isn't enough of an invitation. Give talks, go to conferences, seek out events where you'll be exposed to people who aren't as far along as you are. Or, if you struggle with those sorts of social things, try to talk a colleague in your or an adjacent specialty who thrives in these environments into keeping eyes open for you and doing a bit of matchmaking on your behalf.

Find opportunities to coach multiple people in a broad way. For example, if you do a regular monthly chat or meetup, you can start to get to know regulars who share your interests and give a bit of advice here and there. Based on how those interactions go, you can decide where to invest more time and effort.

Conclusion

While the value of good mentorship for the mentee is often extolled, too seldom is it mentioned that creating and maintaining a mentoring relationship requires more of the mentee than showing up and asking a mentor to take them on. It is a good thing that the best mentors ration their time: because the world cannot afford to lose its most skilled people to mentoring duties entirely. We need them working at the things that make their mentorship valuable.

Being a good mentee means taking some initiative to find a mentor who is a good fit for you[3], and to provide value to the mentor first, as a way to establish the relationship. Then, maintain the relationship by working on yourself, and by contributing to the mentor's work to offset the cost of mentoring a bit.


  1. Zero to One: Notes on Startups, or How To Build the Future by Peter Thiel and Blake Masters. ↩︎

  2. "Bus factor" rather uncharitably describes social failure points within a project or organization by counting the number of people who would have to be hit by buses and killed before the project or organization would be in peril of total failure. ↩︎

  3. It's worth mentioning also that many people start looking for a mentor before they know entirely what their own interests are. This is okay: do work while you're figuring things out. If you don't find the work challenging enough, or rewarding enough, and you can't shake it out with help from your mentor, you may need a different mentor or a different line of inquiry. ↩︎

OSS mentoring


Additional Posts