Keepers of secrets - FOSDEM 09 #
The closing keynote was given by Leslie Hawthorn whom I had the pleasure of meeting last year during Berlin
Buzzwords. In her talk she shared insights into a topic commonly encountered in open source leadership that is way less
often talked about than should be the case: Being in the role of a community leader people will talk to you about all
sorts of confidential information and ask you to not share that information with other no matter how beneficial that
might be for both parties.
Essentially if you’ve never been a community leader – it is much less about technical
skills and way more about strategy, marketing, development events and unpaid therapy really.
Leslie first
introduced the types of secrets:
- There are lots of one-on-one communications. There are several
small group conversations. After all this is what makes humans human. However no matter how much a community trusts the
people meeting in small groups, ultimately someone will feel betrayed, someone will suspect evil things being drafted
in those discussions – even though the conversation really may just involve the quality of the beer they had
yesterday.
- Being social entities we ultimately need input from our peers. This may mean that we require input on
things we perfectly well know that we are not supposed to discuss these topics with anyone.
- There are secrets
that are only secrets when told to the wrong person. There is information that is shared publicly – as in “on a website
that requires no authentication whatsoever” - but that due to the nature of how information is discovered by certain
people will never make it to the right person anyway.
- Some things are innociuous.
- Some things are
blindingly apparent, but aren’t told anyway.
All of this becomes all the more interesting once you become a community leader. Your ultimate goal is to foster empathy and inclusion. You have to understand not only what you communicate, but also how to say certain things.
One example: Assume there is a contributor in a critical code path that is having a hard time privately and appears less and less often online. He told you the reason why, but asked you to not talk about it for whatever reason. On the other hand the community – being uninformed as they are – is loosing trust in the community member, blaming him for stopping progress. How should you react? Well, the three solution paths are extremely obvious but that doesn’t make them any easier:
- Encourage
disclosure.
- Ask for permission to disclose parts yourself.
- Encourage the community to talk to the
individual directly.
The worst you can do is to ignore the issue. Still that is what many people do, simply because it is the most comfortable solution. Go out of your comfort zone – your goal should be to make your project thrive.
What about that one person that just doesn’t get they are hurting the project. The good-hearted person whose actions slow down the project? People on your project will get cranky, waste cycles on herding volunteer work if you avoid dealing with this person. There is no manual on dealing with frustrations and feelings in open source projects - though Poisonous people is a great intro to the topic by Brian Fitspatrick and Ben Collins-Sussman, so is their book on “Team Geek” published at O’Reilly:
Though these issues are messy and make you feel uncomfortable – do deal with them as quickly as you can, otherwise they will kill your project. Either correct the educational issues of the person in question, suggest other ways to be effective and ultimately be willing to kindly but sincerely ask the person to move on.
We have negotiations each day – most of them we do not notice as they happen in the comfort zone of “I like the person and our interests are very well aligned.” The more uncomfortable ones that we actually remember are the ones involving either constellations where we do not like the people involved but are well aligned, where we like the people involved but aren’t well aligned or in the extreme case neither like the people involved nor are we well aligned. Especially in the uncomfortable situations it makes sense to remember that negotiations really come in up to six stages:
- Being willing to openly ask for what you
need
- Asking for what you need.
- Finding common ground and reaching agreement
- If impossible, finding
the best alternative for boot
- If still impossible, agreeing to not having reached
agreement.
Value honesty above all, but really do not be a tactless jerk. Diplomacy in order to reach your goals is ok: Ultimately you have to decide whether you want to be right or whether you want to win.
To summarise make sure you care about your project – the people in it will need most love when you have most reason to hate them.
One final recommendation after a question for leader burnout from the audience: Noticing burn out is as easy as observing that each morning you wake up with that “oh no, I don’t want to do this, I want to walk away” kind of feeling wrt. to stuff that formerly used to be a lot of fun to do. First counter measure: RUN AWAY! Take vacation, turn of your electronics, hug a tree – get away from what is turning you down. After returning make sure you involve your peers in your work. If you cannot get on with your former pet project, find a successor. Nothing will kill your project faster than a burnt out leader dragging the project down. The reason for your burn out really can be as simple as having seen the same negative things over and over again so you do not want to deal with them yet again and having seen the same positive things over and over again so they do no longer give you any reward for your work. It may just be time to move on and do something else.