I've written a few articles on how to be do something badly (or how not to do things), as I think they're a great way of adding a little humour to the process of presenting something. Some examples include:
The last, in particular, was very popular and ended up causing so much furore on a mailing list that the mailing list had to be deleted. Not my fault, arguably (I wasn't the one who posted it to the list), but some measure of fame (infamy?) anyway. I considered writing this article in a similar vein but decided that although humour can work as a great mechanism to get engaged, it can sometimes confuse the message or muddy the waters of what I'm trying to say. I don't want that; this is too important.
I'm writing this in the midst of a continuing storm around Richard Stallman's reappointment to the Free Software Foundation (FSF) board. We're also only a couple of years on from Linus Torvalds deciding to make some changes to his leadership style and apologising for his past behaviour. Beyond noting those events, I'm not going to relate them to any specific points in this article, though I will note that they have informed parts of it.
The first thing I should say about these tips is that they're not specific to open source but are maybe particularly important to it. Open source, though much more "professional" than it used to be with more people paid to work on it, is still about voluntary involvement. If people don't like how a project is being run, they can leave or fork it, or the organisation for which they work may decide to withdraw funding (and/or its employees' time). This is different from most other modes of engagement in projects. Many open source projects also require maintenance—and lots of it: you don't just finish it and then hand it over. For it to continue to grow, or even to continue to be safe and relevant to use, it needs to keep running, preferably with a core group of long-term contributors and maintainers. This isn't unique to open source, but it is key to the model.
What all of this means is that for an open source project to thrive in the long term, it needs a community. The broader open source world (community in the larger sense) is moving to models of engagement and representation that more closely model broader society, acknowledging the importance of women; neurodiverse members; older, younger, and disabled people; and other under-represented groups (in particular, some ethnic groups). It has become clear to most, I believe, that individual projects need to embrace this shift if they are to thrive. What, then, does it mean to be a leader in this environment?
1. Empathise
The world is not all about you. The project (however much it's "your baby") isn't all about you. If you want your project to succeed, you need other people, and if you want them to contribute (and continue to contribute) to your project, you need to think about why they might want to do so and what actions might cause them to stop. When you do something, say something, or write something, think not just about how you feel about it but about how other people may feel about it.
This is hard. Putting yourself in other people's shoes can be really, really difficult. More so when you don't have much in common with them or you feel that your differences (ethnicity, gender, political outlook, sexuality, nationality, etc.) define your relationship more than your commonalities. Remember, however, that you do share something, in fact, the most important thing in this context: a desire to work on this project. Ask others for their viewpoints on tricky problems—no, strike that—just ask others for their viewpoints, as often as possible, particularly when you assume there's no need to do so.
If you can see things at least slightly from other people's point of view, you can empathise with them, and even the attempt to do so shows that you're making an effort. That helps other people make an effort to empathise, too, and you're already partway to meeting in the middle.
2. Apologise
You will get things wrong. Others will get things wrong. Apologise. Even if you're not quite sure what you've done wrong. Even if you think you're in the right. If you've hurt someone, whether you meant to or not, apologise.
This can be even harder than empathising, because once two (or more) parties have entrenched themselves in positions on a particular topic, if they're upset or angry, then their impulse to empathise will be significantly reduced. If you can empathise, it will become easier to apologise because you will see others' points of view. But even if you can't see their point of view, at least realise that they have another point of view, even if you don't agree with it or don't think it's rational. Apologising for upsetting someone is only a start, but it's an important one.
3. Don't rely on technical brilliance and vision
You may be the acknowledged expert in the field. You may have written the core of the project. It may be that no one will ever understand what you have done, and its brilliance, quite like you. Your vision may be a guiding star, bringing onlookers from near and far to gaze on your project.
Tough.
That's not enough. People may come to your project to bask in the glory of your technical brilliance or wrap themselves in the vision you have outlined. Some may even stay. But if you can't empathise, if you can't apologise when you upset them, those people will represent only a fraction of the possible community that you could have. The people who stay may be brilliant and visionary, too, but your project is the weaker for not encouraging (not to mention for possibly actually discouraging) broader, more inclusive involvement of those who are not like you, in that they don't value brilliance and genius sufficiently to overlook the deficits in your leadership. It's not just that you won't get people who aren't like you; you will even lose people who are like you but are unwilling to accept a leadership style that excludes and alienates.
Conclusion
It's important, I think, to note that the two first points require active work. Fostering a friendly environment, encouraging involvement, removing barriers: these are all important. They're also (at least in theory) fairly simple and don't require hard choices and emotional investment. Arguably, the third point also requires work, in that, for many, there is an assumption that if a project is technically exciting enough (and, by extension, so is its leadership), then that's enough. Casting away this fallacy can be difficult to do.
Also, I'm aware that there's something of an irony that I, a white, fairly neurotypical, educated, middle-aged, Anglo adult male in a long-term heterosexual relationship, is writing about this because many—too many!—of the leaders in this space (as with many other spaces) are very much like me in many of their attributes. And I need to do a better job of following my own advice. But I can try to model it, and I can shout about how important it is, and I can be an ally to those who want to change and those worst affected when that change does not come. I cannot pretend that inertia—a lack of change and resistance to it—affects me as much as it does others due to my position of privilege within society (and the communities about which I've been writing). Still, I can (and must) stand up when I can.
There are also times to be quiet and leave space for other voices (even though even the ability to grant that space is another example of privilege). If you know of other voices I should be listening to, please share them in the comments. If I get enough feedback to do so, I'll write an article about those voices for my blog.
In the meantime, one final piece of advice for leaders: be kind.
This article was originally published on Alice, Eve, and Bob and is reprinted with the author's permission.
Comments are closed.