Summary
Why does a company full of smart people make stupid decisions? How do we keep it from happening?

The natural tendency may be just to make decisions that are acceptable and least-common-denominator; decisions that no one disagrees with -- because it's easier and less contentious. But this doesn't seem to be the path to success.

Microsoft is an easy target right now, but it's because they're such a puzzle. Filled with really smart people, effectively infinite financial resources. And buffaloing themselves right over a cliff. I finally figured out that the reason Bill Gates used to loudly proclaim that innovation is what Microsoft is all about is not because he actually believed it, but because he wanted it to be that way. He saw that the only way the company could survive is if they actually became innovative. And he got out because he eventually understood there was no way to turn the ship away from the iceberg.

The company that avoids collective stupidity is a statistical anomaly. Something about the way we do and think about decisions -- something so fundamental that we do it below the threshold of consciousness -- builds in this inevitable tendency towards the non-innovative, non-creative, non-fun organization.

I think one issue is desperate hiring practices which come from forced growth. You "must" grow, so much so that you start saying "we need a body to fill this position," and so the "people are our most important asset" maxim goes quickly into the trash. You start hiring people that don't have the company vision, that don't fit into the team, but they have "qualifications" and they are available and you've got this project that needs to be staffed up right now because there's a contract and money, etc., etc..

And those people eventually start disagreeing with decisions that would once have been clearly seen to be in the company interest, and to placate them those decisions are dumbed down and pretty soon you've got collective stupidity.

Another aspect of this is the size of the group. One of Hewlett-Packard's fundamental tenets was the idea that no unit of the company should be larger than a small town, so you could know everybody. If a unit got too big, they split it to keep things small. It worked pretty well. It just seems like when a group gets large enough, you have the mediocritization effect kicking in even if everybody in general seems to be pulling in the same direction.

So perhaps the answer is to keep things small; keep the units of your business broken up into teams where everyone gets along and moves forward together, and evaluate the health of the business based on the health of those individual teams. Maybe we are hard-wired to be unable to operate optimally at anything larger than tribe level. Eric Raymond once told me he was going to write about what he considered the future of the software business, which would be independent teams that come together to work on a particular project, and when the project is over go back to being individual teams again, joining up with different teams for the next project.

These are just my thoughts on the problem. What do you think causes collective stupidity, and how can we design an organizational structure to prevent it?

Talk Back!

Have an opinion? Readers have already posted 16 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Bruce Eckel adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Bruce Eckel (www.BruceEckel.com) provides development assistance in Python with user interfaces in Flex. He is the author of Thinking in Java (Prentice-Hall, 1998, 2nd Edition, 2000, 3rd Edition, 2003, 4th Edition, 2005), the Hands-On Java Seminar CD ROM (available on the Web site), Thinking in C++ (PH 1995; 2nd edition 2000, Volume 2 with Chuck Allison, 2003), C++ Inside & Out (Osborne/McGraw-Hill 1993), among others. He's given hundreds of presentations throughout the world, published over 150 articles in numerous magazines, was a founding member of the ANSI/ISO C++ committee and speaks regularly at conferences.