How many Microsofties does it take to implement the Off menu?

Sparked by a post Joel recently made, Moishe Lettvin (a former Microsoftie now Googler) gives us a little insight into Windows development. From the post:
So that nets us a conservative estimate of 24 people involved in this feature. Also each team of 8 was separated by 6 layers of management from the leads, so let's add them in too, giving us 24 + (6 * 3) + 1 (the shared manager) 43 total people with a voice in this feature. Twenty-four of them were connected sorta closely to the code, and of those twenty four there were exactly zero with final say in how the feature worked. Somewhere in those other 17 was somebody who did have final say but who that was I have no idea since when I left the team — after a year — there was still no decision about exactly how this feature would work.
By the way “feature” is much too strong a word; a better description would be “menu”. Really. By the time I left the team the total code that I'd written for this “feature” was a couple hundred lines, tops.
But here's how the design process worked: approximately every 4 weeks, at our weekly meeting, our PM would say, “the shell team disagrees with how this looks/feels/works” and/or “the kernel team has decided to include/not include some functionality which lets us/prevents us from doing this particular thing”. And then in our weekly meeting we'd spent approximately 90 minutes discussing how our feature — er, menu — should look based on this “new” information. Then at our next weekly meeting we'd spend another 90 minutes arguing about the design, then at the next weekly meeting we'd do the same, and at the next weekly meeting we'd agree on something… just in time to get some other missing piece of information from the shell or kernel team, and start the whole process again.
What feature is he talking about you ask? It's the shutdown menu. The post in its entirety gives you a good idea of how thing work, but Joel sums it up nicely:
Every piece of evidence I've heard from developers inside Microsoft supports my theory that the company has become completely tangled up in bureaucracy, layers of management, meetings ad infinitum, and overstaffing. The only way Microsoft has managed to hire so many people has been by lowering their hiring standards significantly. In the early nineties Microsoft looked at IBM, especially the bloated OS/2 team, as a case study of what not to do; somehow in the fifteen year period from 1991 – 2006 they became the bloated monster that takes five years to ship an incoherent upgrade to their flagship product.
So why am I posting this? What does it have to do with Linux, or Open Source? 'Those Who Forget History Are Doomed to Repeat It'. Microsoft seems to have forgotten very quickly, and they are paying the price now. Let's learn from the mistakes of others and not repeat those mistakes. As Open Source projects get bigger and bigger, the chance for bureaucracy and layers of management become greater and greater. Luckily Open Source typically has a way of routing around issues like this, but as the likes or Oracle and Microsoft enter our world, it's important this case study isn't one we forget.
–jeremy
Microsoft, MSFT, Windows, Linux, Open Source