That must be the most depressing thing I read in quite a while.
"(Exception: War-room firefighting. Google loves those, and loves heroic performances from people in war-rooms)"
The whole "war room" concept in IT has always bothered me -- it's what managers do when they have a crisis that they don't know how to deal with. It's usually a crisis that they could have avoided if they'd actually done their own job in the first place. War rooms are also invariably where the worst of the developers end up -- at Disney the war room period was one of our most product weeks as a result. Of course, the folks who got rewarded were the ones in the war room, even though their primary contribution was to strut around in front of a bunch of executives while the rest of the team got project work done and the operations team had already figured out what went wrong.
Basically, it's just putting all the developers involved on a project in a room together and giving them a clear goal (launching). Other firms might call this "Agile" or even just "development". Heck, still others would call this a "startup".
"We've always been at war with Eurasia..."
http://www.google.com/search?q=war+room+software+development
From the Joel-on-Software thread:
It raises the question: if this works, why not do it all the time?
Which to me meant, "You use Agile(tm) methods when your project has already failed."
The problem is that they usually use the same approach without the phrase "war room" to create the original product, which lead to the problem they're now trying to solve in the first place.
No you're not tigers. You're a bunch of middle-aged middle-managers in a medium sized IT organization. No-one thinks you look like a helicopter pilot with your stupid Bluetooth headset. Grow the fuck up!
And said crisis is something that was probably caused by their poor decision making in the first place. Umm hello McFly, cutting 50% of the features to save 5% of the budget is not a bargain...
Keep in mind that management wants things that are good for Google. You care about what's good for you
This isn't true either. A manager wants what's good for his or her career 10x more than an engineer does. As I have said before, the only people who become managers are those who want to, which implies they want it more than doing engineering. If they convince you it's "for the good of the company" well that's just a tactic to get you to put their interest ahead of your own.
Not that companies don't need management. But don't get starry-eyed about it.
Some points here:
The key point that starts off #1 is more or less a side effect of any company where you hire folks who have a need for stability in their life. The unpredictability that he refers to is little different than how startups need to pivot. The only difference is that at a big company, it's management's job to hide that from the masses, and there's a limit to how well that can be handled.
Now as startup folks, you may find this abhorrent, or as big-company peons, you may still find this abhorrent, but all the organizations I've seen, from 200-man high school volunteer clubs all the way up to multi-billion dollar corporations, all of them have to deal with this. It's just that a tiny startup where people feel like they're on the same boat and have the emotional fortitude to handle it, then it may be better to be direct and honest.
The no-interviews bit is mildly troubling, but every engineer who's thought about company culture has probably come to this question eventually: if it's not to one's own benefit to interview engineers, then doesn't it seem likely that interviews would devolve into intellectual hazing sessions?
Points #3 and #4 are typical at any company larger than about one or two hundred. My hypothesis is that once you have more than 3 layers of management, the folks at the top who've been there and know what they're doing can't help your direct manager when he needs it. And again, as I see it, this is little different from how startup folks have to go through the process of finding the right company, the right founding team, and so on. People want to go to a big company and think that it will suddenly all be magical but of course there is no shortcut for the biggest challenges in life.
Like the one I had for my Google phone interview earlier this year... when he asked me to code up a simple sorting implementation (an array with an empty slot, and you can't use extra memory) the FIRST thing I described was a swap method that took the two indexes to swap, as well as the index for the blank. (I also at that point mentioned saving the location of the index in order to avoid having to scan for it for every swap). Two minutes later when I said we would simply swap two items, he asked me how, and I ended up describing the swap function AGAIN. And he also didn't understand the part about remembering the location of the blank, he brought it up in the performance analysis -- even though I'd mentioned saving it in a class variable already, I had to explain it yet again.
I didn't get a call back and I didn't expect one, but I was sorely disappointed with the quality of the interviewer, so I can't say that not getting a call back was much of a disappointment after that.
I'd look at it more as a cyclical thing than as a "dying breed". Google itself, after all, is barely more than 10 years old... New ones will come and go.
Every company will have its flaws. Google has over 20000 staff now so there's always going to be some politicking required if you want to get ahead. It's still probably a lot better than other companies that size.