Agreed... it's supposedly one of the few remaining companies that actually respect engineers, but this post pretty much comes out and says otherwise in bold, flashing letters.
"(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.
Haha, yeah, where I work whenever there is a crisis, the "Tiger Team" swings into action.
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.
Given Google's attitude towards perpetual betas, I'm curious if their "war rooms" are more to solve immediate problems (show-stopping bugs, security issues, etc) rather than attempts to "fix" late projects.
Google's attitude toward perpetual betas extends to perpetual war rooms. Almost every feature that you'd recognize from the last three years was developed in a war room. The visual redesign was a war room (well, war cubicle). Real-time search was a war room. The search options panel was a war room. SearchWiki was a war room. The bar across the top was a war room. Pac Man wasn't a war room, but almost all the folks involved were in war rooms and avoiding the war at the time.
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 have a... well, some random dolt with a VP or director or some similarly overinflated title, but no meaningful role who explained that you should use "agile" method when:
1) You don't have time for planning
2) You don't have time for design
3) You don't have time for documentation
4) Requirements are changing
Which to me meant, "You use Agile(tm) methods when your project has already failed."
That's usually what "war rooms" are for, in my experience. Something goes wrong, and to provide the illusion that everyone's on top of things, some managers set up a "war room" where they can "triage" problems and come up with an emergency solution.
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.
It doesn't seem that the post paints Google as being disrespectful to engineers. If it is unfriendly to engineers, then it is unfriendly to everyone.
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.
Good points. I don't think interiews ever became hazing rituals. What happened instead was that a lot of folks got burned out on interviewing, and because interviewing was never taken seriously as a priority, interview training was outsourced to an outsider. That led to a number of travesties.
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.
> one of the few remaining companies that actually respect engineers
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.
"(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.