This chapter discusses mentorship, a concept important to open source maintainers interested in creating sustainable projects and communities. It examines what mentoring is, why it’s important, and how you might begin cultivating a culture of mentorship in your open source community.
Mentorship means different things to different people, depending on their situation, context, culture, and more. To some, for example, mentorship is a formal activity involving a schedule and agenda. To others, mentorship is an informal process among peers; it can even be a one-time conversation. If you ask people to define "mentorship," you will most likely receive wide-ranging responses.
That is what makes mentorship such an important and powerful concept: it is both universal and personal. It’s universal insofar as it has potential to be a positive experience for anyone, yet personal insofar as it occurs differently for every individual and in every relationship.
Therefore, one way of thinking of mentorship is the following:
Mentorship is an act, experience, and opportunity to share what you can, when you can, how you can.
Mentorship is important. It helps you, it helps others, it helps the community, and it helps the open source project.
Mentoring can be a personally rewarding experience. The help and guidance you offer can have valuable, lasting benefits. For example:
-
Experience the positive emotions of giving back.
-
Learn more about yourself.
-
Find knowledge gaps in your own thinking.
-
Learn something new.
-
Expand your world view.
-
Make a new friend, ally, or supporter.
-
And more.
Mentorship helps contributors navigating different stages of their careers or different life circumstances. Mentorship has the potential for positive impact (big and small, yet valuable just the same), whether it occurs among people in a specific project of initiative, in general as people get started with the project, and as people grow and advance in their educations and careers.
Mentoriship has a cumulative effect on community coherence and identity. It might begin between two people, when one person mentors another. But that person may mentor someone else in turn—and the positive ripple effect continues. It might even become a sort of "boomerang of help" that returns to you when you need a helping hand or some advice.
At scale, it helps contribute towards more inclusive, collaborative, helpful, and innovative communities.
Recall that mentorship is an act, experience, and opportunity to share what you can, when you can, how you can.
In an open source project, this can manifest in various ways. It can be informal, formal, peer-to-peer, mentor-to-mentee, and other variants. The relationship dynamics can also differ, such to one-to-one, one-to-many, and many-to-many. The how and when communication occurs also varies, such as asynchronous or synchronous. The kinds of questions being asked and the responses can also influence how mentorship occurs.
Another thing to keep in mind is how people mentor and the different roles they assume. Below are some type of styles (not an exhaustive list, there are plenty).
- Educator
-
-
Teach and inform on concepts, ideas, and more.
-
Help explain and clarify material.
-
Share knowledge and experiences.
-
- Encourager
-
-
Provide encouragement.
-
Remind them of their progress, accomplishments.
-
Fuel potential to keep doing great work.
-
- Listener
-
-
Instead of solely providing answers and guidance, actively listen.
-
Radiate solidarity and acknowledge that folks are being heard.
-
- Finder/Researcher
-
-
Discover questions/resources/people that can provide insights.
-
- Connector
-
-
Share resources such as articles, books, media, events, and programs. Introduce people to each other
-
In summary, it is beneficial to acknowledge that mentorship can go beyond traditionally providing guidance. There are various ways to mentor and in doing so, it provides valuable and lasting benefits for the contributors, open source project, and community.
Part of starting, or growing, a successful open source community is designing the community to be sustainable. This means the project needs to be able to reliably, and repeatedly, bring in new people and help them become ongoing contributors. Let’s talk about how mentoring new contributors is crucial to enabling a community to be sustainable.
If this matches your projects’s version of sustainable, then a mentoring program is absolutely crucial. It’s at the center of how to take a project from "three people who know and do everything" to make it something many people can contribute to in a self-sustaining fashion.
Self-sustainability is an important focus for a mentoring program. And don’t think anyone goes from "mentoring people" to "a mentoring program" by accident. Here’s the argument:
-
If we can agree that lowering the barriers for entry into a project is key to bringing in new people; and
-
If we can agree that people coming into a new project benefit from having one or more people they feel permitted and even encouraged to ask questions and learn from; and
-
If we can agree new people having lackluster or negative interactions with existing project members is likely to drive the new people away; and
-
If we can agree that having a person (mentor, friend) for new people to turn to is a way to prevent the driving-away and especially prevent silent segfaults (people just disappearing with no explanation);
-
Then we can see that doing mentoring with even a tiny bit of repeatable process support is going to yield better, more satisfying results than an ad-hoc process.
Once you agree that even a lightweight program is better than an ad-hoc process, we’re going in the right direction. With this in mind, here are a few absolute must-have elements to include in your mentoring program.
Even if it’s lightweight, write it down and give it an initial try.
For that first e.g. six months, get a handful of volunteers to try out the program. This gives time to work out the kinks in processes, and to attract more mentors for when you make the program more prominent.
When you have a process you have tried and tested once or twice, put up a "Mentoring" section on your project website and include links to all the elements of your mentoring program. Make sure people who have even the slightest inkling of getting involved in the project can look ahead and see how they are going to be taken care of as a new contributor.
After each full mentoring period (refer to time commitment, below), conduct a retrospective to learn from the mentoring period and improve the process iteratively.
It’s not just promising there will be a map and directions, it is showing the actual map and idea of what the directions will be.
Even people who are very experienced at mentoring benefit from having guidelines for how to mentor and work with mentoring subjects (mentees), mentoring ethics, and so forth.
As a deeper reference when creating a mentoring program, there is an upstream guide to mentoring itself. You can use materials from that project to create the elements your mentoring program needs.
Mentors have a special role of trust—the project trusts them to represent the community, and the mentees (mentoring subjects) trust the mentor to lead them down the right path. Mentors need to conduct themselves with an appropriate standard, and there needs to be a way to keep them accountable to that standard and report problems or abuses of conduct by mentors. Such a Code of Conduct needs to be visible up front and prominent for everyone looking at your mentoring program.
Not having a Code of Conduct for your mentors, or making it hard to find, is a warning signal to potential new contributors that this project should be avoided.
If your project already has a Code of Conduct, make sure it is sufficient to cover the mentoring program, and make sure all participants are aware of its existence.
It’s one thing to have a few mentors and to start a mentoring program. But to make it sustainable, the mentoring program needs to doing more than attracting mentors, it needs to be creating new mentors.
The core idea is to make sure that your mentors are also teaching explicitly and by example "how to be a mentor." Your mentors should be thinking overall and in specific instances, How can I help this person be successful at mentoring other contributors? That way new mentors are made of people who have had positive experiences as mentees and are also encouraged in their own mentoring activities beyond.
A new contributor who is mentored well can immediately turn around and offer similar mentoring lessons to other contributors, new and existing alike. Even the same day.
Whenever you are answering a question for a new contributor, how you answer that question is where mentoring comes in. You can answer in such a way that this new contributor feels empowered to share their new-found knowledge. If they take in the lesson of not just what was conveyed but how it was conveyed, they carry this simple lesson of mentoring forward with their own interactions across the project.
Unlike your mentors, you want the fewest demands and lightest burdens for your mentees.
This is information that should be prominent on your mentoring program webpages, and can cover:
-
In our project, here is how to find and/or approach a mentor.
-
What the work/effort commitment for a mentee is likely to be.
-
Clarify the relationship, e.g., a mentor is specifically not a friendship role; the mentoring may be time-bound (six months, etc.) or otherwise have a box once left means the mentoring has concluded; mentors are volunteers and deserve equal respect; mentors are held to a Code of Conduct that mentees should know and follow as well. And so forth.
-
What does a normal mentor/mentee relationship look like in this specific project.
You are looking for a balance where mentees know what is expected of them, while leaving space for the mentor to help grow that understanding of project norms, from technical to cultural.
For everything from people being stuck, through to disappearing mentors, to Code of Conduct violations, there needs to be a clear and obvious person or persons to contact.
This contact information and its purpose should be prominent on your mentoring program webpages.
This group will be one of the rare areas of your project that maintains privacy and a well-understood barrier to transparency for specific topics. Mentors need to be able to talk with other mentors to seek guidance; this group can provide that private space. It can also help with any sensitive matters that arise.
The governance for this group or role needs to have a clear and short escalation path to the highest levels of project leadership.
Mentoring relationships can last years or be completed in a weekend. Make a reasonable schedule, perhaps one that is tied to your release schedule or other rhythms such as specific conferences or events you organize around.
For some projects' experience, the six-month commitment seems to work well. It is enough time to get to know each other, talk through how to help as a mentor/be helped as a mentee, and then some months in the middle for the mentees to actually get feedback on real activities.
Especially if you are starting out, you want to attract mentors. If there is too long of a time and effort commitment, or if there is not clear closure to a round of mentoring, many potential mentors will not join or even inquire further about your program.
Making the time and effort commitment nebulous is like sprinkling mentoring repellant on your project. Be clear on what participants are getting into, and your mentoring program can be on a path to success.
This section was informed by a meeting of community managers, talking about their experiences around mentoring and new community managers.
In the early days of open source, projects did not have community managers. Collaboration among developers was a given, and if you were lucky, some people in your community enjoyed tasks other than software development, like tending to infrastructure, organizing events, or leading a marketing team. As open source has matured, there are many more projects created from within large companies, and these things are no longer a given. Increasingly, people inside those companies are designated the Community Manager or Community Architect, and are tasked with ensuring that projects run well as collaborative, multi-vendor efforts.
Much has been written here about what a community manager may or may not do—but if one thing is certain, it is that projects evolve, and the role of community manager evolves with them.
In the life of a project, a time may come when the original community manager is moving on—to a different job, a different role in the project, or just taking a back seat because of life.
During these transition periods, a new community manager may emerge in the project.
During this period, it can be tempting, as the outgoing community manager, to jump in and start helping the new community person come up to speed. The risk, however, is that you deprive the new person of an opportunity to make the role their own. They will certainly have a different conception of the most important jobs to be done, and a different skill set to bring to bear on the project.
As a mentor, it is important to strike a balance between being a resource, sharing relevant history, and saying how things have been done.
What is the best way for more experienced community managers successfully mentor newer community managers? How can you help them to be successful, allowing them the very valuable space to try new things, even if they will potentially fail along the way? How do you balance scoping the role, while allowing them to define the role in the way that they see fit?
One of the things that is most useful when you are coming into a new role is a list of the people with whom you will be working.
If there are stakeholders who might be able to help you, or people you will work with who have concerns about community goals, this information will enable a new person to come into the role and avoid any pitfalls or faux-pas.
As the outgoing community manager, one of the most valuable things you can do for the new community manager is to introduce them to people who you have worked with, to smooth the transition, and ensure that they don’t have to spend minutes explaining who they are and why they are turning up in places where they are not expected.
A common theme among people who have had bad mentorship experiences is the omnipresent micro-manager. One community manager described an experience where they took on a community role from someone who was stretched too thin. However, everything that they did in the role resulted in email correcting them and telling them how they should have done the task differently. As a result, they drifted away from taking on the role. One question more than any can make a person in a new role feel small and inadequate: "Why didn’t you just…?"
A new person in any role will do things differently than the person who went before. There can be a few reasons for that. Maybe they don’t know how to do it the way it was done in the past. There may be reasons which led to you doing things the way you did, but they’re unaware of the history. It’s also possible that they bring a different skill set and perspective to the role, and their way is just as valid and just as good.
Whatever the reason, avoid asking your mentee "why didn’t you…?"
You have to give the new person in the role the freedom to do things differently. Even if they make mistakes, it is important that they feel ownership over the role.
As a mentor, one of the hardest things is to watch someone struggle to do something which you have done in the past. That does not mean that you should completely abandon your new community manager. Instead of telling them what to do, ensure that you have good documentation for tasks they will need to do in the role, and point them at the documentation.
This gives them guided experience, while showing up any places where documentation is lacking and also giving them the freedom to tweak things along the way.
Ironically for the most public-facing people in a project, people in community roles can see their careers suffer for lack of visibility. More than one person mentioned seeing their careers suffer because their management chain was unaware of the work they were doing, or did not understand its value.
As the experienced community manager, one of the best gifts you can offer a junior community person is being a credible cheerleader for their work.
New community managers can get stretched thin, or can focus their efforts on tasks that do not provide a significant impact on the community.
As a mentor, you have an opportunity to help them channel their efforts on aspects of the role that provide value to the sponsoring company, in addition to benefiting the community.
You may also have the ability to communicate their successes in a way that will help their management chain understand the value that they bring to the project.
Guiding a new community manager through their first few months on the job can be a very rewarding experience. As the experienced person, you can help them be effective and successful, give them confidence in their ability to execute in a new role, and increase the amount of community knowledge in your company and in the industry.
What would the first 30 days of a mentorship program for a new community manager look like? You might try to:
-
Maintain a weekly one-on-one call so that they can ask you for advice and help as they feel the need.
-
Organize introduction meetings with five stakeholders across different functional areas of the project, to help them chart the waters of the project.
-
Identify three recurring tasks they will take over, and arm them with documentation on how you managed the activity.
-
Help them identify two high-value, high-visibility projects to deliver in their first month, and communicate their work when they are delivered.
Beyond the first month, you should be fading increasingly into the shadows, moving your one-on-one calls to every two weeks, and providing guidance on-demand only.
If you have done your job well, your mentee will be well on their way to making the job their own.
This chapter discussed what mentoring is, why it is vitally important to your open source project, and how it helps you and others. Then it described why and how to make a mentoring program for your community. Finally, the chapter concludes with why and how to mentor a new community manager who is taking a role you already are familiar with.