I have been working on the Apache http server for almost 20 years now. I've written 9 books about httpd, and spoken at more than fifty conferences. I'm a member of the Apache Software Foundation, where I serve as a board member and as Executive Vice President. I am responsible for putting on ApacheCon, both in North America and Europe, which is the official conference of the ASF.
Each of these things, I do because someone encouraged me to do something that I knew, deep down, I was incapable of doing, and then cheered me on as I did it.
Direct, intentional mentoring is 100% of the reason that I am where I am today, professionally and personally. I very literally owe everything to the people who have mentored me over the last 20 years. And over the last 5 years, I've very intentionally mentored some other people, to pass the karma on. Whether they're all aware that I've been doing it or not isn't really important. I have specific reasons why I think that this is worth doing.
Why?
There's three primary reasons that I feel mentoring is so important.
Magnify your impact
In 1997, David Pitts was writing a book about Red Hat Linux for Sams Publishing. He asked me to do a chapter about Perl and CGI because I was dabbling with that at work. Fortunately, the book is out of print, because my writing was awful, but that led to another writing gig, and now I have several books I'm very proud of.
In 1998, I complained about the documentation of the Apache web server, and Jim Jagielski encouraged me to quit complaining and do something about it. I started submitting documentation patches, and in September of 2000, I became the first person given commit rights to an Apache project without having ever submitted a code patch.
In 2000, when the first ApacheCon was being produced by the brand-new Foundation, Ken Coar encourage me to submit a talk. I didn't have anything to say, and had never done any public speaking, but he badgered me, and so I submitted a talk. That led to another speaking gig, and another, and now my office is festooned with conference badges, many of which I can't even positively identify.
These are the most notable mentors in my open source life. There are so many others, not least of which are Casey West, Paul Dupree, Ken Rietz, Elizabeth Naramore, Wes Morgan, Sally Khudairi, Earle Bowen, and many others that I'll regret missing as soon as I press publish on this article.
I mention these accomplishments not because I'm amazing, but because these people were able, by their generous investment in my life, to extend their impact into areas where they have no influence. They have accomplished things, through me, in places where they would be unable to do them themselves, due to lack of time, resources, or simply not having access to that part of the world.
Provide yourself an exit strategy
Some day, you're not going to want to do it any more. You're going to want to move on from this project and try something else.
I was told recently by a very wise colleague that the first thing that you should do, on assuming an important job, is to identify the person that's going to replace you. Some day, you're going to move on from that position, and much of what you've invested into the position will be lost unless you are actively taking steps to ensure that your impact outlives your own involvement.
Some folks, of course, strive to make themselves irreplaceable. They do this by hiding information, by ensuring that everything depends on them, and by actively scaring off anybody that might take over. Some people do this intentionally, while others do it instinctively, out of desire to protect their position. But by actively looking for your replacement, you create a culture of openness in which people won't be trying to oust you, so the other goal is accomplished, too. (Publicly documenting everything you do is another huge part of that, and an article for another day.)
By mentoring your replacement, you remove so much of the stress of carrying the entire operation yourself. You can begin to delegate things. You can spend more time thinking about the future, and less time fixing things that are broken that only you can fix.
And when the time comes to depart, you can rest assured that you're leaving things in hands that will continue your vision.
Leave a legacy that actually matters
Open source is code. Code gets refactored, forked, and deleted. When you leave that project, your impact will dwindle as your contributions are gradually patched away.
The time that you spend mentoring people will endure. It will stretch into other projects, other industries, and other decades. Every moment that you invest in another person will extend your impact a little further past your own direct influence.
Who?
If you're surrounded by a lot of people, choosing which ones to invest your time in can be overwhelming. Or, you may have a handful of people in your team who may be a possible mentee. Either way, here's how to choose someone to mentor.
Identify people who are passionate
Look for the people that work until 2 in the morning solving problems that they don't have to solve. Look for the people that keep working on their solution after everyone else says that it's solved. Look for the people that will talk your ear off about something that you absolutely don't care about, expounding on the tiny insignificant details until you want to choke them.
These are the people whose passion can be channeled. These are the people that are worth your time, because when that passion is targeted, focused, and nurtured, it will result in an unstoppable force for good.
Identify people that are working in the shadows
In any project, there are the people that are going to try to be where the spotlights are shining, keen on being the ones in the headlines. And then there are the people that are working behind the scenes to make sure that things keep running. Because they care that things keep running but don't care whether they get the credit for it.
These are the very people who make the best leaders, because the best leaders are as Nelson Mandela describes in his autobiography Long Walk to Freedom:
"A leader [...] is like a shepherd. He stays behind the flock, letting the most nimble go out ahead, whereupon the others follow, not realizing that all along they are being directed from behind."
The people that are just interested in getting things done make this kind of leader, because, even as a leader, they are focused on the results, rather than winning the accolades.
Identify people who are brilliant
Some people are clearly brilliant but are working on things that don't really matter, in the long scheme of things. They're playing games, or spending their time debating the finer points of license law, or picking fights on mailing lists. Sometimes, they're off working on personal projects that nobody benefits from but themselves. A little encouragement in the right direction, and that brilliance can be turned to the benefit of a larger group of people. Possibly that small personal project can become part of a larger open source community. Or perhaps they're writing great articles and how-tos on a personal website and can be encouraged to make their skills part of an upstream documentation project, benefiting a larger audience.
Everyone else
Yes, everyone else. Because you're going to pick poorly—you're going to invest your time and energy into people who pay you back slim dividends. And you're going to miss people that would have benefited from your investment. But in the end, the more people you invest in, the better chance you'll have that one of them will reward your efforts.
How?
Mentoring is really easy. Anybody can do it. Here's a few things you can do to give someone else a gentle nudge towards recognizing their potential.
Assign specific tasks
The most common thing you'll hear among people trying to find their place in open source circles is: "I want to do something but I don't know where to start." The very best answer you can give them is a specific task.
The people at OpenHatch have long encouraged projects to clearly identify "easy" bugs, and intentionally leave them unfixed do that beginners have something to work on.
I very intentionally break conference planning into smaller tasks, and then ask the Apache Community Development mailing list for people to step up to tackle one of those small tasks. This has an immediate benefit—I don't have to do it—and a longer term benefit—they're more willing to help with the next task, and the next event. See also the section above about grooming your replacement. This is how you find those people.
It's particularly important, even though it's hard, to be willing to skip a few of the things that you enjoy doing, and give someone new a chance to do them.
Encourage them to speak
Encourage people to submit talks to events. This is a great way to get involved in a project, because it gives immediate visibility to someone that cares about it. Start out by encouraging them to speak for five minutes at a local meetup or a lightning talk.
By the way, the Call For Proposals for ApacheCon is open.
I also find that the very best way for me to learn more about a topic is to commit to speak about it at an event. This forces me to dig deeper, think about what questions might get asked, and learn how to solve those problems so that I won't be embarrassed on stage.
Here, again, it's a great idea to have some specific suggestions. If you think that someone would make a good speaker, but they say that they don't know what to speak about, be ready to suggest a topic and even an abstract. Some people just need that little extra push to get up on stage, and giving some specific direction may be all that they need. Be sure that if they take your advice, you show up for their talk, laugh at all their jokes, intercept questions when they discover they can't answer them. Then, when they're done, encourage them to submit an improved version of the same talk to the next event. Give specific suggestions of how they can improve their delivery.
Encourage
And, of course, just encourage.
If you look at the statistics of any major open source project, you'll find a handful of people that produce the majority of the code, and a long tail of people who have one or two contributions, and then never come back. In many cases, that's because they had one complaint, and fixed it. In other cases, it's because their contribution wasn't acknowledged by anyone.
A simple "thank you for making the world a better place" may be all it takes to encourage someone to stick around for their second patch, and their third, and their hundredth.
This is the easiest, and by far most important thing, that any member of a community—open source or otherwise—can do to encourage community growth. Acknowledge everyone's contributions. Say thank you. Mention new contributors in your weekly newsletter like Stefano does. Send them a personal email off list thanking them and encouraging them to do it again.
When?
When should you mentor? Well, now, of course.
Don't wait until you're at the top of your organization, or in a position of power. There's always someone that will benefit from your mentorship, even if they are older or more experienced than yourself. You know something you can pass on.
It's never too soon (or too late) to start amplifying your impact on the world by investing in a few other people.
4 Comments