Background: I worked on a 3 month-2 year project loosely affiliated with the Rationalist community and/or the EA community. The project may have been a 'satellite' project (e.g. it was not as core to the community as LesserWrong). I'd like to share insights without sharing my identity, so the project in question will remain anonymous.

In this post, I aim to draw attention to how internal politics plays a role in organizing projects, in a way that I personally did not anticipate.

The short version: In this particular project, political troubles and fighting turned out to be 50% of the work I faced and 90% of the burn. This was about 5 times more than I expected, and this was in a project that involved 3-10 people.

Longer version: The project I was part of required early volunteers who were committed to spending time on seeing the project through. (Why didn't we hire people for pay? No great reason). This had the following effects:

(A) We naturally attracted people who aimed to expand their glory in the rationalist community.

(B) Said people, in my observation, do not like taking no for an answer. This leads to power conflict, fights, etc. etc. etc.

(C) I personally find it very hard to say "no", and am anecdotally high on agreeability. When other people push hard for "yes" on their own ideas, this leads to a strong feeling of being squeezed against a wall.

(D) It is difficult to fire excited volunteers, for a variety of reasons. The one or two times we did so, it led to them feeling salty at me and the organization -- a feeling that I believe persists to this day.

This, to put it mildly, led to a huge organizational imbroglio.

Our project actually worked out very well in the end. However, in an ideal world we could have avoided this internal imbroglio on the way there. Note that (B) is a personal assessment, and not the self-reported internal experience of the project's volunteers.

Actionables I would take in the future:

-- Hire people with money, even outside people. I later did this, and it worked out much better for me than the infighting that stymied the volunteer group. Hiring establishes a known expectation between the contracted employee and the employer.

-- Volunteers with considerable working experience may be more valuable for team cohesion than volunteers without working experience. This is hard for me to elaborate on, so we can treat it as an untested hypothesis.

Anonymity may ruin any conclusions I presented from being generalized, so I apologize in advance about that :). The one second summary of this post would be : in one particular project affiliated with some members of the rationalist community, political considerations dominated the internal calculations.

This should not be taken as a general systemic feature of rationalist projects, in which I have low experience. I do believe it is a systemic feature of longer-term projects of any form, in the world at large. Therefore, I would speculate it applies to many internal rationalist projects. I am happy to be presented with negative evidence.

Note: For my own sake, please try to refrain from guessing at what the project in question is. This would help me produce more content in the future. I only speak for my awesome self. I do not speak for any other human, organization, or collective of individuals. :)

New Comment
9 comments, sorted by Click to highlight new comments since:

The way to reduce conflicts is to have a clear method of decision making that everybody respects. In formal employment it's usually accepted that a both can simply order his employees to do things but the same isn't true for volunteer run organisations.

Often time that means it make sense to vote on decisions to make them accepted by everybody.

Do you have experience being one of the leads in an organization where this worked? Just curious. (If you have, I have some questions to ask about pitfalls you ran into and how you avoided certain failure modes that I encountered.)

I spent time in a bunch of different organizations that worked more or less well. I spent 4 years at the board of a toastmasters club. Another 4 years as part of the moderator of a personal development internet forum. I started the Berlin Quantified Self Meetup and at the moment I'm involved in Wikidata as an administrator.

On the other hand, I don't see myself as an expert at leadership either.

Wow, that sounds great. Can I poke you for a few questions on how those organizations ran? I think that experience is invaluable.

In particular, I'd like to know how wikidata's community reaches a consensus, when I imagine many different players would like many different things for the future of the community.

There are cases where Wikidata has ways to find consensus because it has actual policies and there are cases where it doesn't.

The creation of new properties is for example a process that's well-defined. At some time a policy was written that a property proposal has to be open for at least 7 days to be created and has to have a majority of support for being created. The person who makes the actual creation decision also has to be either an admin or have the special right of property creator so that not every user can simply go ahead and get a new property created.

On the other hand, there's a case like interwiki links. Wikidata has different items for the tomato fruit and the tomato plant. A lot of Wikipedias however have only either an article for the tomato fruit or the tomato plant and one Wikipedia article can only be linked to one Wikidata item. All Wikipedia articles have interwiki links to all Wikipedia article in other languages that link to the same.

Various Wikipedia users in small languages care very much about their very short articles having interwiki links to the other Wikipedias. When some Wikipedia articles are linked to the tomato fruit and others to the tomato plant a lot of them won't have interlinks and as result those users want all articles interlinked to the same article. On the other hand, two taxonomists on Wikidata care very much about linking certain articles to the fruit or the plant and there's conflict.

Unfortunately, we don't have a good policy to resolve that conflict and as a result new conflicts about this topic pop up regularly. A way to reduce this problem would be to write an actual policy for how the conflict should be handeled.

When it comes to writing new policy, the idea is to have an Request for Comment (RfC) that declares the new policy and people being able to vote SUPPORT or OPPOSE and when a proposal gets high support an admin can mark it as being accepted after some time has passed. At the moment, the policy about how an RfC gets accepted is more implicit and it would likely be good to have a more formal policy there as well.


A quote comes to mind from ze frank - snerdcore comedy

"Dance like an idiot and don't sell anything."

Translated here to mean: "stop caring what people think and stop trying to push for status.". If only it were that easy to tell people in the project to do that.

I think telling this to volunteers runs into natural difficulties: in the volunteer setup, people naturally expect to be compensated with something (whether that's money, status, college-app material, or the feeling of being part of something larger than themselves). Otherwise why would they put the reliable dedication time in?

This was something I'll be thinking on more next time I organize something. I'm curious if you have any suggestions or thoughts.


The work should be it's own reward. If you need external incentives do you really want to be doing it? A lot of my writing was so rewarding because I wanted to get it out of my head onto paper. Without external reward. (caveat of course people sometimes work for money, etc. But that's not what volunteers do it for)

This was very mildly interesting but not I think suitable for the front page. Also, if you continue to post about this stuff you're going to de-anonymize yourself (to anyone that cares anyways).