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.”

Link

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.

Link

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.

12 comments

  1. Penelope Haccius

    Excellent article! What a relief to have some perspective, in a world of daily hype and hoopla about “openness”, as though it’s the new Holy Grail. My experience – although on a far smaller scale than yours – has been the same.

    This:

    is the crux of the matter, and many people underestimate the trickiness of managing smartly, while overestimating their own understanding of the situation.

  2. Jeffrey

    I think openness can be scaled, but the openness/approach you use when initially creating something may not operate at the same scale as the effort evolves in future iterations as you aptly note. The issue is given the openness we want to maintain and the number of people interest in engaging, how can this be managed so that it doesn’t overwhelm the system? I’d rather continue to strive for maximum openness than to assume at the onset that we’ll have to tighten the leash fairly quickly.

  3. Pieter Colpaert

    As an OKFN member I am somehow biased, but nevertheless, here’s my opinion:

    Blaming a bad organisation on “because it was an open organisation” is like a programmer that blames his programming language for the bugs in his software, or a soccer player blaming the ball for a near miss. It’s true that you cannot manage a team of 5 people in the same way (closed or open) than managing a team of 100 people. That’s normal, they need different approaches. Saying that “open” doesn’t scale is quite far-fetched though.

  4. Warren Smith

    Hi Laurent,

    Interesting article. What you’re describing seems to me very close to what has been analysed previously in firms using the competing values framework. Companies move from being a very unstructured, open unit (adhocracy), then resemble a tight knit family, until growth sets in, requiring a more formal structure.

    The important question (IMHO) is should growth always be our objective? What if firms, associations and social units all remained relatively small? Clearly, for firms, you could argue you wouldn’t benefit of economies of scale & scope, however, you wouldn’t either have to bear the negative impacts of growth (bureaucracy, loss of democratic control, loss of original vision). Certainly an interesting topic to debate…

    • Laurent

      Agreed, growth doesn’t have to be an objective. But there are two drivers that make openness complicated: growth and success. And success can happen to a small structure. Think of TED for example. They are still a 50 persons organization, but their reach has been multiplied by a million. They must be getting a number of external inputs totally unmanageable by an organization their size. So in a way, without growing nor making any change internally, they are becoming less open by the force of things.

  5. Rodolphe

    Interesting. I believe your experience explains why institutions emerge(d) at some point, as an artefact by which individuals agree to sacrifice some part of their power for the sake of collective manageability.
    And therefore the question: could institutions emerge in todays’ crowd-everything era? Can they resist?

    • Laurent

      I’m sure there are ways to still capitalize on the wisdom of the crowds, I just think than in practice the process is less open than in theory. In practice all inputs are not good, all inputs are not useful. You have to design a system open enough that you get new and unexpected ideas from the outside, but closed enough that internal resources aren’t flooded and contributors don’t feel frustrated. It’s really a balance act, different for each situation.

  6. Raphaël Briner

    I think some companies will have the same issues within their internal social networks ala yammer. The difference is that they might force processes and regulations too heavily at the beginning, trying to reduce their fear, when they should fear their own bureaucratic attitude towards openess. This comparison is valid with your next article “more projecting, less sharing”.

  7. Pingback: Wikipedia: from 51000 active editors in 2007 to 31000 in 2013 | Accelerating reinventions
  8. Pingback: FractalCult.net

Post a comment

You may use the following HTML:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>