Openness does not scale
When I founded Lift back in 2005, it was nothing more than an abstract idea, an event that *might* happen. There was no value in being associated with it, other than true passion to contribute to the original vision.
Because I had no event organization experience, I made the conference preparation process completely open. On the event’s blog I would ask questions like “how long should the breaks be” or “who would you like to invite to speak?”
It was co-creation, crowdsourcing, radical openness; call it what you like. It worked wonders, helped create a unique event while involving the nascent community, and giving its members a sense of ownership and identity. The best possible scenario.
Then the event got noticed, and things changed. Lift became something, it had an aura, people wanted to be associated with it. From a few suggestions a month, I started to receive 10-15 emails a day, people proposing to “build synergies”, speak at the event, telling me that the format should change to this or that.
That is when I learned openness and success are not compatible. Openness does not scale, no matter how hard you try.
From a strength, being exposed to external inputs became a weakness. Some synergies were taking focus away from the core goals. I was receiving as many speakers suggestions a week as I had speakers slots for a year. People I had to turn down felt rejected. Format suggestions were often contradictory, and going into a direction was making one person happy, two others unhappy.
This is a well known problem. Let’s look at the Pirate party: as Ben Mason writes in Guernica: “a couple of radical principles is fine for a fringe group”, less “once [you] start winning seats”.
Pirate policies cannot be imposed from above, they must be determined by consensus of members; so if the base has not come to an agreement on an issue, the leaders have no opinion. The party convention in December [2012] was supposed to solve this by setting policy, but it failed embarrassingly: since each of the two thousand members who came had equal right to speak, long lines formed behind the microphone and they got through only half of the weekend’s agenda. So to many questions the answer remained: “We have no policy on that.”
What worked for a few hundred pirates doesn’t work when the party grows and starts to have success.
Same for Wikipedia: the organization that represents openness in everybody’s mind is now a mature project, and the movement towards more structure is very apparent. It started in 2005, when users were first forced to register. Restrictions and rules have grown ever since. So much that they have now started to impact the number of contributors, which went from 50’000 in 2006 to 35’000 today. From a recent report by A. Halfaker, R. Geiger, J. Morgan and J. Riedl:
[...] several changes the Wikipedia community made to manage quality and consistency in the face of a massive growth in participation have ironically crippled the very growth they were designed to manage. Specifically, the restrictiveness of the encyclopedia’s primary quality control mechanism and the algorithmic tools used to reject contributions are implicated as key causes of decreased newcomer retention.
From my experience it seems all open organizations follow the same path:
- At the beginning, a small, consistent and aligned community of people start a project in a fully transparent and open way
- The project grows, others are joining. Participants’ objectives start to differ more, the alignment level goes down
- Processes and hierarchies are put in place to formalize things that were previously happening informally
- As problems continue to grow, openness is scaled back and more restrictions are put in place
- Early adopters leave out of frustration, referring to the old days as much better
- A certain level of maturity is reached, made of a mix of open and formal processes
Openness/crowdsourcing/co-creation has been praised as the solution to almost everything. It makes products better by involving final users into the design process. It makes launches less risky as problems have been anticipated. But it is a process that needs to be managed smartly. The key: balance between openness and control.
Ron Lambert, ‘Object for Perpetual Openness’ 2007
From my years of experience, here are a few advices:
- Set the right expectations from the start. You know you will have to add restrictions down the road, so make it clear as early as possible. This way when new rules are installed, frustration will be less important. Don’t let contributors feel that their feedback results in actions from you 100% of the time, even if it can be true in the early days of a project.
- Be transparent about the difficulties. Once in the post conference survey we asked “would you like shorter or longer breaks?”. The result: 50% shorter, 50% longer. Make the call, and explain why you could not use feedback in that particular case.
- Learn to gracefully say no. Consensus is harder to find as a community grows, saying no is a normal and healthy thing. But find a way to not turn your fans against you in the process. This is a really hard thing, but people can understand that all their inputs can not be taken into account if you explain respectfully and carefully.
- Openness only works with the right people, so think about the incentives you are using to grow your community. It is the same problem with Facebook pages: if you recruit new fans via give-aways, you will not have the same quality of people than if you had been patient, only popping up on the radar of those genuinely interested in what you do.
- You do not have to choose between two extremes (open vs closed), but to position yourself on that axis in the best possible way, knowing than moving in one direction or the other is always possible. Balance is the key.
