What Larry Page really needs to do to return Google to its startup roots

When you get to the point where the arguments against something don't make sense outside the context of the internal path you've chosen, you have to ask if maybe you've crossed into an area where you're very much in danger of group think.

I respect what they have been able to achieve, and I certainly respect the vision of data center sized computers. I also experienced first hand the kinds of weird rationalization that accompanies trying to mentally (or culturally) accommodate an externally forced invariant for which the original principles have ceased to be relevant.

The 'Google Scale' problem is one such invariant.

For a large part of its existence there was never enough infrastructure to support things, and if you looked at Google's financial disclosures they were spending a billion dollars a quarter on new infrastructure. An x86 class server costs about $5k, do the math.

When the Great Recession hit that expansion stopped but what was interesting was this: When Google had been growing, an App that was popular would develop a material footprint in the infrastructure, that imprint would cause additional pain if it wasn't designed to fit in with everything else. However, just buy growing so much infrastructure, Google had reached a point where some apps would never have a material impact on the total resources consumed, the infrastructure was just that big.

But the rules didn't change, you had to design to run on what constituted 'Google Scale' as defined in the present not by what it meant when that requirement was put in place.

So the difficulty of implementing the requirement scaled with the size of the infrastructure, but the kinds of products that were being conceived and deployed would never need that level of scale. Stalemate, and what was worse there wasn't anywhere inside the company to even have the conversation about whether or not the requirement still made sense. And that was the root of a lot of problems and a lot of people have reflected that up the chain.

When I was there this blog posting might have been a long missive to the internal list for miscellaneous discussions, it would no doubt become a centi-thread (over a 100 responses) and detecting any change that it produced would be difficult at best (and positive change would never be credited to the person who pointed it out, only the people who changed would get any credit). And it's not that it wouldn't cause change, the social network inside worked through these issues with a plodding but deliberate slowness and sometimes those internal groups within groups might reach out to the original instigator, but more often not. But what the change wouldn't feel like is "startup-y."

I suggested to Alan Eustace once that Google I/O was a really cool way of getting people on board with various API changes and understanding the direction folks were taking, how come we didn't have an internal version?

Lots of potential, lots of challenges. Fortunately lots of folks dedicated to working through the challenges to make things better and its always great to have Larry pounding his fist on the table to add some urgency to an already frenetic environment. Sometimes the table pounding though just made the organization look like one of those table top football games where the vibrating games board caused the game pieces to move, somewhat randomly, around the board :-)

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.

It is so much easier at Google to design something for scalability (which Google is mostly about) than at other companies, mostly thanks to the policies and infrastructures you criticized.

It is easy to just criticize without considering the implications of alternative policies.

For example, re: Switch to team-based distributed source control I've worked at a pretty large software company that does this. The problem is lots of teams are working on similar things and results in duplicated effort.

As someone who worked in the SRE and datacenter/cluster management teams during the same period you were there (2005-2010), I can confidently say that I agree with almost everything you’ve mentioned. If you think engineers on small projects have a hard time dealing with acquiring and managing cluster resources, try being on the team that has to resolve all of those requests. Because many of Google’s core infrastructure pieces are so inflexible and frankly not designed to be used as they are, they end up dying a death of a thousand cuts. Systemic design flaws lead to telling most teams “no” when they asked for even 5 machines worth of resources.

At the end of the day, Google has maybe 5 products that generate 99% of the revenue and operate at huge scale. Should they devote most of their attention and money to these products? Absolutely. Should they do this at the expense of all the small projects? Not if Larry wants the company to act like a startup.

Ultimately the limiting factor to Google’s agility will be its technology infrastructure, not its engineers.

Yishan Wong (previously FaceBook's Director of Engineering )'s suggestions there are interesting

e.g

" 1. Fire a broad swath of people in the executive and management staff

I've talked to quite a few extremely talented and didn't-leave-because-they-were-incompetent Xooglers over the past year at Sunfire (and via other avenues), many of them key early employees. A recurring refrain that I hear is that Google has been taken over by overly-political managers who have laid waste to a formerly meritocratic organization where good ideas get turned into good products, and this has been deadly in two ways: (1) truly good talented people who keep their heads down and get things done are motivated to the leave the company and (2) the organization that remains becomes, by necessity, one that revolves around this internal politicking rather than productive endeavor and shipping products.

Identifying these people from above will be hard, because part of being politically skilled includes looking good to the people above you (and the more politically skilled they are, the better they look), so Larry should directly contact a thousand of the best ex-Googlers and ask them to anonymously name 5 people who are still at Google who should be fired, and using a histogram of the results, fire the top 100 names without letting those people "explain" their way out of it. Steve Jobs did something like this when he returned to Apple (except he just walked the halls firing anyone he thought sucked), and this is the data-driven equivalent: a thousand ex-Googlers is enough to even out any personal grudges, and the aggregate information is likely to be highly reliable about who has been climbing without regard for those below them or the good of the organization. "

Isn't that the point? They are there to maintain a larger point of view from individual developers. Giving every person with their own agenda launch authority is disastrous (in a large organization): Of course my project is important. My project doesn't need review, I wrote it.

> Make it very clear that good, small ideas matter.

This is a problem everywhere big, and I agree one million percent.

Rather than reducing the load Google needs to better connect the work of doing good recruiting to to individual/team success. The total disconnect between who does the interviewing and what team a hire ends up working on is the big problem, not the total amount of time/effort being devoted to recruiting.

-harryh, googler from 2004-2009

However, the key is to understand that these are simply superficial manifestations of a bigger issue: as the company grows in size, communication requirements grow exponentially, and even a slight mismatch in the talents of people will lead to serious issues. I don't think any of the recommendations will work at the scale of 20,000 engineers that Google has.

Take open source software for instance. For a 10 person start up, it works beautifully. Now try convincing 10 other startups to adopt exactly the same set of software, and you'll have a never ending religious war on hand. But you cannot also let everyone to pick their own solution, for then the 10 different groups cannot integrate with each other.

Far too many people keep complaining (I complain where I work for as well :), but the solution is not easy. By far the best approach is for people to realize that there is a need for a company to grow so much, and not anymore. However, human nature will not permit that.

The root of all evil. At Google. That's ironic.

Another great quote: "Amazon EC2 is a better ecosystem for fast iteration and innovation than Google’s internal borg system."

I'm not saying you're wrong, just pointing out the flip-side.

Maybe Google should have a separate network with separate virtualized machines and no "Google stuff" for new medium-sized projects. Test whether they get traction there and then port them into "the Google-way" later.

Or maybe "the Google-way" just needs to be fixed up to make it easier. For example you could use AppEngine.

Also, "behaviors that lead to success" are not necessarily the same as "behaviors of the successful". Lots of folks have effectively won the lottery.

It sounds like what they SHOULD do is streamline and document the system for their engineers better. There should be an internal project started to make their developers HAPPIER and more productive. For example, you have an idea for a new project? Here's the actionable checklist. Need to launch? Please make sure all of these are checked, then you can launch. Treat your developers like you treat your users.

As for capturing people into an incubator before they leave the company? I like that idea. Except of course, one has to wonder how much this will incentivize people to quit google, just to get more autonomy and a better deal :P Not to mention, that once acquired by google, the startups' technologies are just rewritten to live in the Google ecosystem, so this seems like a waste of money... except for possibly the IP licensing costs.

What about ~2 months per year? Like a mini-sabbatical.

http://webcache.googleusercontent.com/search?q=cache:t0H7qG2...

BTW, can someone explain the first point, "Compiling & fixing other people’s code" ? The "world" here refers to other teams inside Google or external libraries?