Let me try and give a little background here. The Wikimedia Foundation is the non-profit organisation that stands behind the Wikimedia projects, among which the well known online encyclopedia, Wikipedia. The Foundation is now around 3 years old, and has been striving at least for the past year, in light of the growing fame of the projects, to structure itself into a working organisation. Although I started as a Wikipedia editor, my interests have long shifted to the organisation itself and to helping Wikimedia take the necessary steps to become a strong and organised structure, in other words, the indispensable spine of the Wikimedia projects.

In the past few months, the Wikimedia Foundation has attempted to set up committees. The goal of those committees, as I undertood it, was to allow delegation from the Board of Trustees on some of the matters that get either forgotten or overlooked because the Board can't cope any more, with all there is to do. Yeah, well, I suppose you don't run an organisation the size of AOL with just two and a half people hired, and a board of Trustees where pretty much every member has a job on the side, which is what we're doing right now. But that's beside my point. When the idea of committees came up, voices in the community started to advocate the fact that:

  1. committees should be open and transparent
  2. anyone interested in a committee should be able to join and help, if people are bad, you throw them out

I won't linger on 1), because the definition of open and transparent varies with the people, the mood and the level of trust you put in anyone, anyway.

I would like to focus on 2), which, I believe has two aspects.

A) Anyone interested in a committe should be able to join and help

Basically, as I understand that, we can end up with committees totalling as many as 1000 people (of course, I am exaggerating), and you'd have to make sure that 999 of them pretty much agree to be able to throw someone out of the committee. Well, there is one thing that some people seem not to have understood, is that an organisation is not a wiki. I don't know how to put it more plainly.

In a wiki (the Wikimedia way), you have time to wait for people to give their opinion, rework an article, find a consensus. It can take two hours, it can take two years, it doesn't matter (well, in principle, it does not, in practice it may, but that is for another debate). In an organisation, you need to be able to make decision quickly. Because BigSponsorNumberOne will not be waiting for you to reach a consensus with 1000 people. They'll turn to someone else.

So losing time trying to reach a consensus, losing time trying to accommodate 1000 people, is (read my lips) not efficient. And guess what? The hosting company that hosts our servers? Well, they send a bill at the end of each month. And if there's no money to pay the bill at the end of the month, because the LetsGetBigBucks committee has spent hours and weeks trying to get anything done, or, even better, trying to find a consensus about who should be in and who should not, you lose efficiency. And you lose the big bucks, or the trial, or whatever it is that is happening in the real world and needs a decision right then and there, not a discussion. That is one of the reasons why I am against huge committees. And those who believe that I am just trying to keep the power in the hands of a chosen few, please read on.

B)The tendancy I seem to observe while looking at the committees forming, is the following:

People are trying to set up their committees making sure that they can cover every single possible case that is presented to them. So the LetsGetBigBucks committee is going to try and add every single person they know of that has ever had anything to do with money. Or sponsors. Or advertisement. They end up with a committee of 15 people, who all know a bit, and who all want to throw their bit in. I believe that is the wrong approach to committees. Let me try to give an example to make that as clear as possible.

Case study

Let's say CommunityMember comes to LetsGetBigBucks committee with a CoolProject. In that project, there's a LetsGetBigBuck part (partnership with a big sponsor), but there's also a budget part, which actually enters the area of competence of the SpendTheDoughButKeepTheCake committee, a LetsTellTheWorld part, which falls under the competence of the WeGotToGetTheWordOut committee, and a ScrewsAndNails part, which falls under the competence of the HandyWorkers committee.

Well, the LetsGetBickBuck committee cannot, by itself, answer all those parts. And it shouldn't. The LetsGetBigBucks committee should be made of say 5-7 people, who are conscious of their strengths, and their weaknesses. They know they can evaluate the LetGetBigBucks part of the CoolProject, they know what to ask of CommunityMember so that they have enough elements to ask the other committees to evaluate their part, one after the other. And they're smart enough so that these parts are analysed in the right order, ie. there's no point in letting the WeGotToGetTheWordOut committee lose time on assessing the project on their side if LetsGetBigBucks or HandyWorkers committees have deemed the project not in line with our goals, or technically unfeasable.

In the same line of thought, the LetsGetBigBucks committee can decide to only ask the HandyWorkers for the feasibility, since the CoolProject is actually so cool that they're going to make it happen, regardless of what the SpendTheDoughButKeepTheCake committee may think at first (typically: "we don't have the dough, we don't do it").

What I am trying to say here, is that having one member of the WeGotToGetTheWordOut committee on the LetsGetBigBucks committee might sound like a good idea at first, but in the end, it dissolves every single committee's power to focus on their skills (ie. the StuffTheyDoWell). Having a member of the HandyWorkers committee on the SpendTheDoughButKeepTheCake committee might help in chosing the best software for writing invoices, but it makes the HandyWorkers person lose time, because they have to liaise with their committee, or give an explanation of what is happening where and how, and rather than letting the SpendTheDoughButKeepTheCake committee write up their specifications, they're going to tell them No, that is impossible. Or no, that doesn't work and stall them in their precise assessment of what they need.

Let's go back to our CoolProject then. What is the good chain of events?

CommunityMember comes with CoolProject to LetsGetBigBucks committee. They read the stuff, find it to be in line with the goals of the organisation and the idea should bring in some BigSponsor, on the paper it looks doable (ie. it doesn't ask to plant a wiki on the moon), but they don't really know, because none of them is able to exactly assess the technicality of the project. So they make a summary of their assesment (ie. good for goals, should be easy to bring in BigSponsor), and send the project to HandyWorkers committee, who is to review the feasibility. Let's be very clear here. The HandyWorkers committee should not, ever, under any circumstances, reassess whether the project is in line with the goals, or if BigSponsor will be interested. That is not their task, that is not where their skills lie. They might have individual opinions, but if they want to express them, they go out for a drink (even if virtual) and talk them out with other people involved, informally, whatever. Their assesment is on the technical feasibility. That's it.

They give their assesment back to LetsGetBickBucks committee which makes an executive summary and says "let's go further", or "let's stop here". Assuming they want to go further, the LetsGetbickBucks committee tasks the other committees that might be involved with providing their assessment and their task list. So all committees put together a project. That's the key word. And once you have a project, you can start putting together a Project team. The Project team can comprise of as many people with as many needed skills as the CoolProject calls for (and that is where TheCommunity comes into play, you're sure to find people With The Right Skills to do the stuff. And if you don't, there is a world outside of TheCommunity), because guess what, nobody knows everything, but everybody knows something. And there are professionals out there.

What happened here, is that, instead of having argued for ever with 1000 people about whether or not the CoolProject was actually cool (due to technical issues, or communications issues, or financial issues, or weather issues) and in the end have the CommunityMember go elsewhere to present his CoolProject, you have a clear process, with timelines and decisions, made by people who are deemed to have the skills to make them and have been given the authority to do so. The more "complete" a committee, in my opinion, the less efficient. And here I mean complete in the sense that you'd want to bring in someone from another committee to act as "advisor" or "counsel" from the beginning. I am not saying that everyone should have the same profile when entering a committee.

Conclusion

Keep the committees separate. Learn to know your strengths, your skills, and your weaknesses. Don't try to make every committee a super-duper committee that will be able to answer all questions in every situation. Don't challenge what other committees have decided on grounds that "you know better". You might, but you have not been empowered to make that decision or that assessment. Others have, probably on the same grounds you have been empowered to make other decisions. "Learn to delegate". "Learn to trust". "Trust yourselves". "Learn to keep away from what is none of your business, you cannot be everywhere".