The Google Caste System
managedcode writes "Google doesn't like to do things traditionally. Right from their IPO, when they dumped Goldman Sachs for secretly trying to deal with their big investor, Kleiner Perkins. Business Week covers the Google Caste System, 'in which business types are second-class citizens to Google's valued code jockeys [..] They deem the corporate development team as underpowered in the company, with engineers and product managers tending to carry more clout than salesmen and dealmakers.' At last a company is shouting at the top of it's voice, engineers make the world."
I hadn't heard that Goldy refused to play by the rules from the Google founders. The rules were typical Google: no backroom deals that favor big institutional investors over smaller investors.
But Goldy wanted to get some easy money, they got caught and shut out of the deal. That makes my night. If you've dealt with bankers (esp. "New York" bankers), you'll know why.
Here's a nice article on this.
Perhaps this also explains the "Google will fail" articles that appeared before the IPO; the powers-that-be were peeved that Google did the IPO their way, and wanted it to fail.
http://www.thebricktestament.com/the_law/when_to_
I think this is the right way to describe it: the engineering/product management group provides lots of options. Management allocates people/machines/resources to the various options. But nothing happens without that initial impetus from engineering.
:-)
Case in point: I asked Eric Schmidt about a potential project based on some comments he made at an all-hands meeting. He point-blank told me, "Don't ask me about getting that going, find some coworkers and make it happen. I'm the wrong person to ask."
Projects don't come from the top. It is entirely bottoms-up. And the nice thing is that top-to-bottom agrees this is the best model.
Damn, I love working there
If you've never heard the phrase "software engineer", you've just admitted that you've no industrial experience.
As a software engineer in safety-related software for the last 10 years (first job was power station controls, current job is car engine controllers), I can assure you that we are *very* serious about responsibility for mistakes. You screw up, people die. As a result, only about 10% of our time is spent actually coding; around 30% of the rest is spent on requirements capture and design; and the other 60% is spent testing the living shit out of it until we're sure what we're putting out is safe.
On projects that don't have safety implications, there isn't anything like as much testing. But this is an engineering judgement based on the impact of bugs on the customer - if your car radio bugs out for example, it's annoying but it doesn't kill you. Same in any other engineering discipline - you don't think that the mechanical engineers who design plastic toys use the same level of testing that engine designers would, do you?
Grab.