4 ms·
This sounds way more like "how to make Google a developer wonderland" than "how to make Google more startup like". The author started at Google post-IPO. That
by wheels 16y ago
This sounds way more like "how to make Google a developer wonderland" than "how to make Google more startup like".
The author started at Google post-IPO. That's hardly "startup" time. In a startup it's not like resources are given out like candy and there's massive amounts of free-time for working on 20% projects.
It's true that there are less meetings at startups, but there are other things that typical hackers find unsavory: developers also have to do sales, sysadmin, customer support and generally be much more aware of where the money comes from.
The thing that makes a startup interesting is that the company is the project. Frequent meetings aren't as necessary because the goals are usually easy to understand and fairly one dimensional, e.g. "We have one product and we need to increase the number people using it."
The way you'd make a big company more startup like would be to make teams far more autonomous and drastically increase the risk / reward gradients. Your product ships 6 months late? Your entire team is fired. You open up and sustain a new revenue channel that's paying big dividends? Everybody gets a $2 million bonus. Team leader disagrees with his boss? He can chose to do it his way, knowing he's risking his team's livelihoods.
I don't know if anybody's really crazy enough to try it in a large company.
- deleted 16y ago[deleted]
- sirbyx 16y agoWhat you're describing sounds exactly like Amazon, except for the $2 million bonuses.
- orborde 16y agoI'll speculate that this is a problem with all large companies: the price of failure for the team involved is huge (unemployment?), but the benefit of success is small (continued employment and maybe a bonus). If the incentives are so structured, it's no surprise that you get risk-averse behavior.
- nostrademons 16y agoVery few teams actually get laid off just because the product fails. The only time it's happened in Google's history was Google Radio Automation, where they brought on a bunch of people with very specific domain knowledge of the radio industry and then had nowhere to put them when they decided they weren't going to get involved with radio after all. Most of the time (assuming they don't quit), the team just gets absorbed into other products. I assume things are similar in other large tech companies. I'll posit that the real problem with big companies is the opposite: the price of failure is mild (you get reassigned to another team and get to do more cool stuff) and the benefits of success are also mild (you might get a promotion and an iPad or something). When your actions have little effect on the outcome, your actions tend to regress to the mean. In a startup, where failure means you starve and success means you never have to work again, you have a much bigger incentive to go the extra distance.
- woan 16y agoFrom an innovation standpoint, it might be interesting to go with the model of high benefits of success, low cost of failure. That relative skew is what has arguably made the US the leader in this field in the macro. Startups given the market for engineers in particular actually only have a temporal starvation penalty. It's not like they can't get another job after they fail. Doing this in a large company might lead to even more innovative products because startups are so under-resourced and governed by promises to investors that they risk becoming myopic and less agile.
- danbmil99 16y agothe reward for successful skunkworks at a large co is typically promotion (serious promotion to very high-paying, visible roles). That can be very rewarding for certain personality types.
- blacksmythe 16y agoReward for who? The team lead? More than one person? (Serious question - what I have seen is that the team lead gets bumped up one notch and gets to try on a larger scale).
- alexkcd 16y agoSteve Jobs tried that a while back. Of course, Apple wasn't as large then as it is now.
- danbmil99 16y agoMicrosoft was using this model in the mid/late 90's. Teams like DirectX, Netshow (became Messenger) and Xbox were given wide latitude, and run more or less like startups, with appropriate rewards and consequences. Not sure to what extent this approach was company-wide, but maybe it should have been, because I think it worked pretty well for them at the time.
- n_are_q 16y agoEric Schmidt has mentioned several times that google is very fond (focused on he would say) of the "hockey stick" projects that are created by developers and not by the managers on up, and as users discover them, experience exponential growth due to the value they provide. I assume his strategy is to attempt to create an environment in which such projects can first be created, and then be successfully scaled to the masses if they prove popular. So the "use google infrastructure" mantra will be difficult to let go if you are in that mindset. They need to either remove at least a major part of the overhead and constraints of these highly scalable systems, or create a well planned and organized transition path from something with low deployment and development overhead to something "google scale". This could be at least at first a completely non-technical thing, such as requiring teams to at least have a plan of how they will migrate their redis, solr or whatever data stores to whatever google is using at scale. But reading this makes me cringe, that sounds like a very frustrating environment to work at and sounds very ungoogle-like to me. It appears their public image diverges much farther from reality than I would have thought.