Tag Archives: community

What does a community manager do

Last week I took some long-postponed vacation time and missed Stormy’s blogging prompt. But this particular question needs answering.

What does a community manager do?

Whenever people ask me what I do, I find myself struggling for words, because being a community manager is a daunting mishmash of interrelated tasks that range from marketing to HR to event management to journalism to … everything else.

During the Obama years, the term “community organizer” was bandied about, and that comes close to what a community manager does. And then there’s the confusion around the term “manager”, because I’m not a manager, and I don’t manage the community.

So what do I do?

Well, it’s a bit of this and a bit of that.


A major task of community management is to be the lead cheerleader for the community. I’m the community manager for RDO, and so it’s my job to promote RDO to the various audiences that might care.

In the case of RDO, that includes the larger OpenStack community, cloud operators in the general IT work force, and also internally to people at Red Hat who need to be informed about what’s happening in the “upstream” community, and how it affects our “downstream” product, Red Hat OpenStack Platform.

To this end, I manage our Social Media presence, post updates to our mailing lists and blog,  make announcements on IRC, and so on. I also show up at conferences and answer questions from attendees, put together presentations to tell people about what we do, and speak at events.

Event planning

At Red Hat, we have an actual event planning team, and they are awesome at what they do – booking facilities, shipping stuff around, planning and setting up and tearing down the physical booths at events, coordinating and communicating with all of the people that will attend.

I don’t do that.

But I plan and coordinate events that my part of the community will show up to. I plan small social events around the main events. I make sure that those events work with the schedules of the people that I’m responsible for, and encourage them to come and bring their friends.

And I help out with small regional meetups, providing swag, as well as helping with (i.e., funding) travel and lodging for speakers that might not have budget to do that on their own.

Make personal connections

A major job of the community manager is to become an expert on the community members. Who knows what. Who is willing to speak on a particular topic. Who has the connections to make things happen.

Then, when a question is asked, or when someone has a need, it’s my job to connect them with the right person that can help them.

So … kind of like first-tier support, triaging problems, solving the ones that I’m able to, and referring to second-tier support those problems that are beyond my expertise.

There’s also some mentoring that goes in here – helping people new to the project know where to fit in, and where to find the information they need.

Look for stories

I look for stories of people using our project, and tell those stories to the world. In this part of the role, I’m the journalist, looking for ways to tell the story about how our project makes life easier. Much of this is amplifying stories that other people are telling. And then some of it is going out and gathering the stories, and then finding ways to tell those stories.

Everything else

While I don’t write code for the RDO project, I do a little bit of everything else – whatever people need done, I try to fill in, or find the right people to do those tasks.

So, that’s why it’s difficult to know how to answer when people ask me what I do at work.

Too many beginners

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.



Living in community: Curbing your passion

I’ve had a very frustrating set of interactions over the last 3 days, on an open source community mailing list. Doesn’t matter which one, because I think that these things are universal.

I said “here are some ways we can make things better.” Or, at least, that’s what I thought I was saying.

Several people heard “everything is broken, and it’s your fault.”

At the end of several very heated email conversations, it became clear to me that we all agreed on (almost) everything, and were getting hung up on that initial statement. It wasn’t even that the things that I was proposing were opposed, it was that the way that I presented them was perceived as criticism of what people had done for the last few years.

Email is notoriously bad at conveying nuance. This is amplified in a multi-cultural, multi-lingual community.  Here’s some practical things that I took away from this conversation – most of which I should have already known

Suggest improvements. Don’t focus on shortcomings

Pointing out breakage is easy. Proposing solutions is where the real work is. Now, sometimes, you need someone to say “this is broken and I don’t know how to fix it.” Those situations are very tricky. Tread lightly.

Focus on what needs improving, not on who made it that way

This sounds easy, but is really hard. There’s always someone who spent hundreds, or thousands, of hours, making the thing the way that it is, and so when you point out that the thing isn’t perfect, that person might take it personally. I honestly don’t know how to avoid that, and this week has shown that very clearly. But I can look back and identify some of the things I did poorly, and apologize for them.

Curb your passion

This one is unintuitive. We need to be passionate about our community. But sometimes when you’ve been pondering something for a few months and arrive with all of that passion, people are more likely to mistake that passion for anger, criticism, and so on.

Yes, some people need to get thicker skins. Don’t read everything I’m saying as that we need to pamper everyone’s bruised feelings. But when people aren’t looking in your eyes, it’s easy to take passion as an attack. We’ve all done it.

I’ll close with one of my favorite quotes from Confucius, who said, “There is honor in the email not sent.”

Yes, he said that. I was there.

Read your email twice before you send it, and delete half of them unsent. This will lead to a better universe, and fewer three-day shouting-fest email threads.



In a talk I attended earlier this year, Shaun McCance mentioned, as though it was established science (which it is) the 90-9-1 principle of community participation. I’ve thought of it frequently since then, to set expectations and to keep myself sane.

The idea is that in any community effort, 90% of the people are going to sit around saying that it’s a great idea, but not actually doing anything about it. 9% of the people are going to work casually on it in their spare time, as convenient, and between them will do a huge amount of the work. Then 1% of the people – usually one or two dedicated people – will pour themselves into it wholeheartedly, putting every spare moment into making it a success.

Note that it’s not the exact numbers that matter here, it’s the undeniable fact that you can’t expect everybody to work as hard as you do on everything. It’s all too easy, when doing anything on a volunteer basis, to look around and get frustrated, discouraged, even angry, at the 90%. Understanding that this is the normal, expected, even healthy way that communities operate, can help you refocus on what you can (and can’t) do in any given effort.

Sometimes (most of the time) it’s ok to be in that 90%, and you don’t need to feel that you’re not pulling your weight. However, if you’re in the 9% or the 1%, it’s not reasonable to get angry with the 90%. They have other things to do, and are likely the 1% on something that you’re not helping much with.

By the way, here’s a couple of resources about this notion:

This article claims that the concept is dead. Note that this article appears to be someone just making up new numbers to illustrate the same concept. What’s important here, folks, isn’t the exact numbers, but the general concept. Way to miss the point. (This article also appears on dozens of sites in various different forms.)

Wikipedia claims that it’s a feature of Internet culture.

Here’s an actual statistician doing scientific analysis, rather than me making up numbers.


Skippy posted some thoughts about FTIC which I found intriguing. About as close as I get to FTIC is, like Skippy, the folks with whom I interact via IRC. Although I keep in fairly close touch with Maria via AIM as well.

We tried, briefly, the text messaging thing. That was before either of us realized that text messages are billed PER MESSAGE, and the bill at the end of that month was rather startling. Presumably all the cool kids have unlimited text messages on their cell phone plans.

I’m also reminded of this quote:

I don’t own a cell phone or a pager. I just hang around everyone I know, all the time. If someone wants to get a hold of me, they just say ‘Mitch,’ and I say ‘what?’ and turn my head slightly.

Mitch Hedberg (1968 – 2005)