Last weekend at FOSDEM I gave my “Write A Better Manual” talk. I got a question afterwards that I’ve never actually received before:

We’ve done such a great job of attracting new members to our community that it’s causing a problem. Our lead developers are spending all of their time mentoring beginners, and no code is getting written. What do we do?

Once I got over my “I wish I had your problem” moment, we had a great conversation about concrete ways that you can address this problem. And, of course, it is actually a problem, because it can lead to the demise of your project every bit as much as not enough new community members.

Here’s some things that you can do, even if you don’t have exactly this problem:

Turn the beginners into mentors

Someone has just come to your community, and asks a question. It’s one of the questions that you get every day, like “how do I find my IP address?” or “how do I connect to a wireless network?” or “where is the toilet?”

Rather than answering the question yourself, ask the not-quite-beginner to answer it. This does many things at the same time. It saves you the time and trouble of answering. It indicates your confidence that this person is part of the team. It lets this person know that it’s ok for them to start mentoring other people. And the next time the question is asked, you won’t even have to say anything – they’ll just answer it. You’ve taken the first step to making a mentor out of the mentee.

Take shifts

Mentoring beginners is amazingly rewarding, but it’s also exhausting. You shouldn’t have everyone doing it, and you shouldn’t have the same people doing it all the time. Take turns. Even go so far as making a rotation schedule – one week on, 3 weeks off. Your mentors will come back rejuvenated and ready to start up, and will get “off shift” just about the time that it’s starting to be frustrating.

Know when to quit

Even if you don’t take specific shifts, mentors should be told that they can, and should, take breaks. Mentoring is incredibly important, but it’s only part of your “job”. Work on code for 3 hours for every hour you spend answering questions on IRC. Or something like that. You’ll find that if you set yourself a specific quota of mentoring time, you’ll look forward to it more, and you’ll be more effective at it.

If you’re not good at it, don’t do it

Finally, some folks just aren’t that great at mentoring. Either they’re not very patient, or they’re not great at communicating, or maybe they’re just too valuable at writing the code or the docs, and should stick to that.

These people should be encouraged to stick to what they’re good at, because, frankly, some people do more harm than good when it comes to talking to beginners.

Celebrate your problem

But, at the end of it, recognize that most projects would love to have the problem you’ve got. Celebrate your beginners. Bring them along. Eventually, they will “graduate” and become the core of your community.