This article was originally written for http://superuser.openstack.org/articles/leadership-open-source-community/. I will be publishing a more detailed version shortly.
Leading a community group, it turns out, is completely different to being a manager. I learned this the hard way; I made mistakes, started (and continued) arguments, and sometimes, when faced with a large hole, simply continued to dig.
In late 2014 I had been working on OpenStack documentation for about a year. We were preparing the Kilo release, when the current project team lead (PTL) asked if I would be willing to put my name forward as a candidate for Liberty PTL. In early 2015, I was elected unopposed to lead the documentation team for the Liberty release, and all of a sudden I realised: I had no idea how to run a community group.
At this point, I had managed docs teams of various sizes, across many timezones, for five years. I had a business management degree and an MBA to my name, had run my own business, seen a tech startup fail and a new corporate docs team flourish. I felt as though I understood what being a manager was all about. And I guess I did. But I didn’t know what being a PTL was all about. All of a sudden, I had a team where I couldn’t name each individual, couldn’t rely on any one person to come to work on any given day, couldn’t delegate tasks with any authority and couldn’t compensate team members for good work. The only tool I had in my arsenal to get work done was my own ability to convince people that they should.
If you’ve spent time as a manager in a corporate environment, you’ll be used to keeping secrets, actively managing your employees’ careers, and pretending you know the answers to things (especially if you don’t). This is entirely the wrong way to go about managing a community, and if your team decides you’re treating them like that, they will probably only give you a couple of chances before they eat you alive1. If you get it right (even if it’s on the second go-round), the opportunities for growth and satisfaction are unbeatable. Not to mention the sense of achievement!
My first release as a PTL was basically me stumbling around in the dark and poking at the things I encountered. I relied heavily on the expertise of the existing members of the group to work out what needed to be done, and I gradually started to learn that the key to getting things done was not just to talk and delegate, but to listen and collaborate. I had to not only tell people what to do, but also convince them that it was a good idea, help them to see it through, and pick up the pieces if they didn’t. You will end up stumbling around in front of your team a lot in open source. Here’s how to make it work for you:
Rewarding the good, punishing the bad
The phrase ‘carrots and sticks’ is often used to describe the process of rewarding good behaviour (carrots)2 while punishing bad behavior (sticks)3. Rewards are everywhere in today’s corporations. From monetary incentives (bonuses, share schemes, gift cards and shopping vouchers), to various team activities (lunches, dinners, paintball, barista courses, and all manner of competitive activities), these awards are designed to make all your colleagues envy and despise you. Not to mention all those little branded tchotchkes (a stress ball in every imaginable shape!) we all seem to accumulate. There are so many carrots given out, that not getting any can often be a form of stick.
Of course, this is the first and most obvious thing you will notice missing when you start managing a community rather than a team in an organisation. You don’t get to pay them. You don’t get to give bonuses. And the tchotchkes are harder to find and more jealously guarded.
The first thing you have to do is work out what you have got. Got access to stickers, t-shirts, or other branded merchandise? Give them out! What about privileges (and no, giving someone more responsibility is not a privilege, so don’t count things like granting core access)? Things like discounted tickets or travel to conferences, access to company-sponsored events like code sprints or meetups, or things like the ability to vote on leadership positions can all be considered perks of being part of a community.
There are also other, less obvious, things that you can do to motivate people: always be willing to call out great work (or even mediocre work, especially if it came from someone surprising) in a public way, but keep any criticism private. Thank people, a lot, for everything. Make sure when people email you asking questions you add other people into the conversation, with a note like “this person is an expert on this topic, and I’d love to hear their opinion”. Flattery and thankfulness are some of the best tools you have to motivate people on your team, and they’re entirely free. Just try and keep your ego in check and let other people take credit wherever possible.
Performance measurement as a behaviour management tool
One of the more popular performance measurement methods is referred to as a nine box, or a talent matrix4. The idea of ranking employees can be quite distasteful, so it’s important to remember that it’s not about ranking staff against each other, but against themselves and their own past performance. You should be able to see each employee move from the lower left to the top right of the matrix as they improve in their role. Once they hit the top right box, you must be ready to promote them, at which point they drop to the centre of the matrix, and start the journey up and to the right again. Of course, the opposite is also true: if an employee starts to track down and to the left, you need to be having some serious discussions about the role that the person is in, whether or not they’re having personal issues, or whether they’re the right fit for your team, or your company. The point is, there’s something of a science to this when you’re in a corporate environment.
That science becomes much more of a dark art when you’re leading a community. For starters, though, you need to remember that it’s not really your responsibility. Most of the people in the your community already have a job, and a career path, and a manager who (hopefully) cares about those things. And that person isn’t you. Also, those things are (and should be) fairly opaque to you, it’s really none of your business. But that doesn’t mean that you shouldn’t care about your team’s performance within the constraints of your group. Most communities have levels of responsibility within them. From leading sub-teams, to being involved in testing, sitting on advisory boards, or becoming core contributors with greater levels of trust and expectation, right up to leading the group itself, you need to be aware of the aspirations of your community members, and ensure you’re letting people know the options available to them should they wish to progress. An extra added complication is where these two things intersect. You never know if a team member is getting pressure from their corporate manager to achieve a certain role within your community, or what value (if any) companies might place on metrics, roles, or positions of trust within your community. You can’t always rely on team members to tell you what they’re trying to achieve, either, sometimes they make you guess.
The best way to ensure you’re helping individuals succeed in their performance goals is to make sure you understand what those goals are. This isn’t always easy and you can’t necessarily assume that all team members want to progress, either. This is even more true in communities than in companies, since a promotion often means more responsibility without any increase in benefits (you’re not paying them, after all). The best way to do this is to ask people, and the best way to get a good answer is to do in private. Don’t be afraid, as a community leader, to reach out to people directly, saying something along the lines of ‘hey, I noticed you’re doing great work, and wanted to have a chat to you about the kinds of things you’re interested in working on, and how I can help you achieve your goals within our community.’ You won’t always get all the answers you might want, in the detail you might need to really help them, but at least you’ll have a better idea than just assuming everyone wants to become a team leader some day.
The performance art of trust
Perhaps more important than rewarding staff, or accurately recording their performance improvements, is proving that you trust them. A little trust goes a long way and can positively impact loyalty, morale and retention. As a manager, there are many occasions where you are privy to information you can’t share with staff: financial or company performance information, restructures, or even layoffs. The thing is, your team members are probably pretty smart and they probably know that this is a thing. You need to reassure them that as soon as you can tell them, you will. But there’s more to it than that; there’s something I like to call the performance art of trust, which is more about telling them when you don’t know something than when you do. If someone asks you a question, and you don’t know the answer, don’t make things up! Just come right out and say it: “I don’t know.” You might find it helpful to practice, because it’s not easy to do when you’re trying to be all manager-y and stuff. In fact, most of your training to become a manager has probably been about pretending you know the answers when you don’t, which is exactly the wrong way to go about it.
Of course, as a community leader, you almost never have access to information before anyone else, so you may be wondering why this is relevant. It’s because the principles of honesty and trust are just as important, if not more so, in community situations than they are in a workplace. Community members will work with you if they want to work with you, and they won’t work with you if you’re a twit. The best way to look like you’re someone worth working with is if you appear open, honest, communicative, trustworthy, and reasonable.
One of the hallmarks of many open-source communities is the somewhat impassioned email communications5 that occur. Flamewars on mailing lists are a feature6 of open source communities and they happen out in public. Treat them as performance art, where your audience is focused on one thing: is this person someone I trust to lead this group?
It’s easy to come out of a flamewar looking like a buffoon, so here’s a couple of tips:
- Always read the email you’re replying to thoroughly, several times, and try to understand the sender’s point of view. Work out what the question is (if there isn’t a question, then don’t send a reply).
- Start your reply by thanking the sender: for bringing up a point you hadn’t considered, for asking questions, or even just for taking the time to put their thoughts into words. This forces you to assume good intent.
- Answer the question, AND ONLY THE QUESTION. Give reasons for your answer, using dot points if necessary, but don’t bring other issues into it, and certainly don’t launch into personal attacks. Be prepared to question your own beliefs about things (you don’t have to change your mind, but you need to be open to other perspectives).
- Ask a question of your own: Do they think this is reasonable? Can they think of something you might have missed? Do they have further comments?
- Don’t hit send yet. Leave it as long as possible; at least a couple of hours, preferably overnight. This not only gives you time to calm down a little, but it also slows down the exchange on the mailing list, which will hopefully remove some heat.
- Before you hit send, proofread, and take out all the emotional language. Work out if you can consolidate some points, reorganise the content to be clearer, or take out irrelevant information. Be as concise and to-the-point as possible.
- If the thread has been dragging on and there’s no progress, take it offline. Admit that perhaps you don’t fully understand their viewpoint and offer a video or phone call, even if it’s an early morning or late night for you. Be the bigger person, take the hit. People are always much nicer on the phone, and if nothing else, it stops the flamewar.
To conclude, communities are definitely more forgiving than corporations, so you’ll probably get away with stumbling around a little bit before you find your feet. However, they’re also run almost entirely on trust and goodwill and you can erode that really quickly and sometimes without noticing. Be honest when you don’t know something, own up to your mistakes, never shift blame (even if you really didn’t do it), and always lift your team members up. If you can nail those things, then you’ll find a way through, and I’m willing to bet that you’ll become a better manager in the process as well.
1. OK, maybe not actually eat you, but they won’t like you for it. Not even a little bit.↩
2. Why anyone would continue a good behavior for a carrot reward, unless they were a bunny, is beyond me (I prefer chocolate biscuits, personally), but it’s as good a shorthand as any to describe this process.↩
3. Please don’t actually beat anyone with a stick. It’s poor form.↩
4. The nine box performance matrix is usually attributed to McKinsey, who invented it in the 1970s for GE. If you’ve done any classes at business school, you’ve probably done a course on it. For the purposes of this article, however, it is simply a method of plotting team members on a graph from lowest performing in the lower left, to highest performing in the upper right. Most nine box models plot performance on the x-axis, and behaviour on the y-axis, but there are many variations.↩
5. Some would call them ‘flamewars’.↩
6. Some would call them a ‘bug’.↩
