|
|
|
|
|
by fuck_google
4906 days ago
|
|
It could be argued that the "hire the best people and give them the tools and information to do their jobs" strategy hasn't worked out that well for product management at Google. Google Docs and App Engine are two prime examples of dysfunctional product management that seems to value the opinions of "the best people" (supposedly Google employees) more than those of the customers. Malcolm Gladwell's article "The Talent Myth" seems fitting:
http://www.gladwell.com/2002/2002_07_22_a_talent.htm |
|
I don't think the article supports your argument. You can't argue against "talent" -- talented people are tautologically more capable than untalented people. If you don't want smart people making decisions, who do you want making them? Stupid people? Some unspecified different group of smart people under unspecified different conditions?
The article makes the strong point that certain reward systems are harmful. If you give anyone who shows strong short-term results a huge bonus and a promotion and anyone who doesn't a pink slip, you create an overwhelming incentive for people to fudge the numbers and take bad risks in order to stay on the A list. But that's not the same thing as hiring the best and brightest and then (perhaps after some probationary period) giving them the equivalent of tenure and autonomy as long as they don't start any major fires.
If the article can be summed up in a single paragraph, it's this:
"Groups don't write great novels, and a committee didn't come up with the theory of relativity. But companies work by different rules. They don't just create; they execute and compete and coordinate the efforts of many different people, and the organizations that are most successful at that task are the ones where the system is the star."
Which is bullocks, because it's overly broad. "Companies" are not a uniform thing. If you're General Electric or NASA and you make jet engines and nuclear reactors and spacecraft, you need to run everything by the lawyers and the actuaries because if you make a mistake then literally planes fall out of the sky.
But you don't design web apps the same way as you design medical devices. The risk profiles are totally, comprehensively different. If a pacemaker fails, someone dies. If Google Maps is not available on your device, you just use Mapquest. Or a paper map. Or ask someone for directions. If some engineer collects wifi data that they probably ought not to have, again no one dies, and the ultimate outcomes in the case of "collected and then deleted before being used" vs. "prevented by bureaucratic process from being collected" are, as far as I am aware, completely identical for all parties other than from a public relations perspective.
When the cost of a mistake is low, it makes good sense to take more risks. If the damage that someone can do is smaller, you don't need to put so much effort into preventing it. Which is good -- it's efficient -- because having to check and double check is slow and expensive.
There are legitimately cases where it costs more to prevent a mistake than to clean it up. In those cases it is completely rational to allow mistakes to happen. Science needs negative results. Sometimes we need to be allowed to make mistakes in order to learn from them. And companies in such industries can do far worse than to act as a risk pooling apparatus for a loosely federated collection of small teams of individual inventors.
This is probably not a strategy that works well if you're making war machines or dangerous chemicals or massive scale financial transactions. But it seems to be a strategy that works well for making web apps.
I mean, they are making billions of dollars. Enron didn't make billions of dollars. Enron lost billions of dollars and then lied about it. That's a pretty big difference.