What is worse than a meeting where everyone sleeps while the meeting-man talks?
A meeting where everyone has a different opinion, everyone talks and everyone is busy being nice to one another.
If that picture from Don't Make Me Think by Steve Krug looked familiar when you glanced through it, and it felt like deja-vu; it is probably because that is exactly how a lot of critical user interface, software development and sometime even organizational decisions are taken in a lot of places.
During a recent conversation with an individual, while talking about his company, he ended up describing the whole idea; co-incidentally; but much more articulately than I might have explained it myself. I might not be remember the discussion to the minute detail of every thing that was said to be able to quote it word for word, but here is how it pretty much went:
| Individual: You know, in general I have nothing against my company; we are all amazing individuals working really hard and doing all we can do to get the right thing done or the right decisions taken; but every time it looks like something is going to work out really well, we work hard; collectively; as a group, to screw things up real bad. Me: Interesting. Am I allowed to use that sentence on my blog? Individual: Sure. Why? Me: It's an interesting sentence. You might read this sentence again on my blog; sometime soon. Seriously. Individual: Sure. Go ahead. Use it. |
The whole a-group-of-really-nice-people sitting in meeting rooms and screwing things up seems to be a recurring theme that happens to manifest itself again and again, so many times that you start to question, if there is something fundamentally wrong in the idea of getting things done by perfect consensus.
Turns out, that there are times in software development when 'Committee Driven Development' as we shall call it, starting today, is down right in-effective. Scott Berkun in his presentation on how progress happens describes how democracy is bad in software development:
| Committees by definition prevent change. The whole idea is to try and get consensus and consensus will always lead towards mediocrity because you are averaging out decision making. So one of the most interesting stories to me about Rome; this is a picture of the emperor Constantine. [picture of Constantine on a projector] He was a later emperor and one of his claims to fame... if you remember the early history of the Christians in Rome; they didn't like the Christians so much; like the whole 'throw them in the lines thing'… that is not a story; that was true. There are catalogs of all the things they would do with Christians and Jews and slaves and other things. There were hundreds of years of horrible treatment for Christians; and then one day Constantine decided - 'You know what? We should be nice to Christians'. Boom! Edict of Milan, believe it was called. Edict of Milan. And now, next day, everyone's nice to Christians. Boom! Like that. That could never ever, ever, ever happen in a democracy; ever. It's designed to prevent that from happening. But if you're talking about change and I'm not really trying to get into a debate about political structures and tyranny and what not but if you are talking about change; autocracy and solidified centralized power is actually a much more effective way to make immediate change happen. |
This opinion from Scott might be subject to a lot of criticism, by people who are firm believers of democracy, but anyone who has been in a meeting where a bunch of people, having equal or similar power, just cannot get to agree on anything, knows exactly what Scott is talking about.
'Power' by it's very nature is something that sounds like a thing the micro-managers crave and the ones who are into the modern-management, shun; but power itself, is neither good nor bad. In the ideal world power is supposed to be just a quality which enables you to get things done. That's what we mean when we say - you're-being-empowered-to-do-this - It is invariably handing power in the hands of people who crave for it the most, that results in disastrous situations.
Where most organizations tend to miss out on, is finding the right Constantines who are capable and will indulge in using this power to bring about meaningful change. Quite a few organizations often fail at trusting these Constantines after they have been found, simply because they lack trust. Trust, is indeed, a difficult thing to give to your employees after all.
People in favor of democratized software development often tend to cite open source projects as an example of development by mutual agreement and consensus; but anyone who has been associated with open source for more than a day knows how the function of a gate-keeper and how important it is to the success of any open source project.
Recent discussions around GNOME user interface that a small team changed, without the community consensus, and then presented these changes back to the community, forms an interesting read. The explain their stand while presenting the final changed to the community:
| Although the changes aren't nearly as radical as the original mockups, they are a big change from the current GNOME panel menu. If we had proposed the changes on the mailing lists, it would have started a huge discussion about what people hated about the design ("you can't make the panel menu depend on beagle!!!") and how it should be different. And then we could have either (a) completely ignored everyone and done it ourselves anyway, or (b) had a long conversation about the merits of the design and then not actually finished the code in time for NLD10. So we did it ourselves, and now either GNOME will like what we did, in which case, yay, free code for GNOME, or GNOME won't like what we did, in which case, no harm no foul for GNOME, and yay, brand differentiation for Novell. (And anyone who yells "fork" deserves to get one stuck in them.) An equivalent answer to the question is "because you can't do design by committee". Everything good in GNOME is good because one person or a small number of people working closely together made it good. Much of what is bad in GNOME is bad because lots of people have contributed without having a single vision of what the end result is supposed to be. This is just another aspect of the UI "simplicity" thing. We like UIs that try to do the right thing (metacity, epiphany/Firefox, evince) rather than UIs that try to make every possible user happy (enlightenment, mozilla, gpdf/acroread). If you try to design something by committee, you either have to end up with the latter sort of messy does-everything UI, or you ignore and hence piss off a large chunk of the committee. |
In the same discussion, the developers submitting their changes, thrash the whole design-by-committee approach rather ruthlessly and end up with a conclusion the individual I quoted at the start of this post had landed up with. The developers who made changes to the Gnome user interface without community consensus explain:
| But some people will still say "But couldn't you have discussed it with the community before doing it?" No, we couldn't. If we had, it would either not have happened, or it would have sucked. It's inevitable. It's not a problem with he GNOME community, it's a problem with communities in general. The wisdom of crowds [4] only works in situations where there are clear right and wrong answers. If you try to apply it to a design problem, where there are many entirely different right answers, then you end up with a wrong answer. Always [5]. So to sum up: design by committee is bad, endless debates that result in code not actually being written are bad, design by very small teams is good, software with a unified vision is good, trying out cool new UI ideas is good, free code at least doesn't suck, and of course, for Novell, not shipping NLD10 is bad. I don't think there's anything we could have done to get more of the good without also getting more of the bad. |
From what you've read so far, it might sound that committees in general just prevent change from happening and slow down things.
Committee Driven Development is definitely the sure-shot path to avoiding change. It prevents both you and your organization from doing anything remarkable; but it doesn't stop there.
I am here, dear reader, to tell you, that blown out of proportions, high volumes of overlapping responsibilities and having too many committees in place, is single handedly capable of destroying your next project or even your entire organizations faster than most programmers and organizations think. Committee Driven Development is not just lame; it's dangerous.
The next time, when you're thinking about your company, and feel that you're all amazing people, doing the right things individually, but tend to screw things up when you get in meeting rooms and talk for long hours, maybe it's because your organization has failed at picking the right Constantine's and giving them enough power and trust to get things done.
Your job, in some of these situations, is to see if you can become that Constantine.
Don't know how? Go read the James Shore's Change-Diary or see Scott's video on how to make change happen and prevent committee driven development.
I wish you good luck.
Comments are closed.