I've been credited with coining the term "do-ocracy." When I've had the opportunity to lead an open source project, I've preferred to "run" it as a do-ocracy, which in essence means I might give my opinion, but you're free to ignore it. In other words, actual developers should be empowered to make all the low-level decisions themselves.
When you think about it, the hacker group Anonymous is probably one of the world's most do-ocratic organizations. Regardless of where you stand on Anonymous' tactics, politics, or whatever, I think the group has something to teach developers and development organizations.
As leader of an open source project, I can revoke committer access for anyone who misbehaves, but membership in Anonymous is a free-for-all. Sure, doing something in Anonymous' name that even a minority of "members" dislike would probably be a tactical mistake, but Anonymous has no trademark protection under the law; the organization simply has an overall vision and flavor. Its members carry out acts based on that mission. And it has enjoyed a great deal of success -- in part due to the lack of central control.
Compare this to the level of control in many corporate development organizations. Some of that control is necessary, but often it's taken to gratuitous lengths. If you hire great developers, set general goals for the various parts of the project, and collect metrics, you probably don't need to exercise a lot of control to meet your requirements.
Is it possible to apply do-ocracy outside of open source and hacktivism? Not to the same degree Anonymous does, but in moderate amounts, it could improve the overall quality of our software and our jobs.
Vision and culture rule Anonymous members pick targets and carry out actions based on the general vision and culture of the group. Whether in a do-ocracy or not, vision goes a long way.
Some years back I worked for a network equipment company. It was probably one of the worst jobs I've ever had, complete with rows of beige cubicles highlighted with sickly green trim. Not only was I told to write my Java classes mostly in caps, with few files and minimal whitespace, but each day we had hours of conference calls with a team in New Jersey. Our computers were vintage and our shell connection was slow. The "vision" was to try and catch up with whatever Cisco was doing.
Internally, the project was considered a success, but to me it was clearly a failure. I'd be shocked if the company kept a single customer from leaving, and I'm virtually positive it didn't land new ones. The website was horribly confusing and unattractive. It was intended to be a B2B site. The dilapidated culture of the company and its hollow objective coupled with a bizarre need for control yielded predictable outcomes.
Sign up for CIO Asia eNewsletters.