What Larry Page really needs to do to return Google to its startup roots
I worked at Google from 2005-2010, and saw the company go through many changes, and a huge increase in staff. Most importantly, I saw the company go from a place where engineers were seen as violent disruptors and innovators, to a place where doing things “The Google Way” was king, and where thinking outside the box was discouraged and even chastised. So, here’s a quick list of things I think Larry could do to bring the startup feel back to Google:
Let engineers do what they do best, and forget the rest.
This is probably the most important single point. Engineers at Google spend way too much time fussing about with everything other than engineering and product design. Focusing on shipping great, innovative products needs to be put before all else. Here’s a quick rundown of engineering frustrations at Google when I left:
- Compiling & fixing other people’s code. This is a huge problem for the C++ developers at Google. They spend massive amounts of time compiling (and bug fixing) “the world” to make their project work. This needs to end. Put an end to source-code distributions for cross-team dependencies. Make teams (bigtable, GFS, Stubby, Chubby, etc.) deliver binaries & headers in some reasonable format.
- Machine Resource Requests for products in the “less than a petabyte” class. Just hand out the resources pro-bono, track usage, and if they exceed some very high limit, then start charging. Why is this a struggle?
- LCE & SRE “blockers”. Having support for Launch Coordination & Site Reliability is great, but when these people say “you can’t launch unless…” then you know they’re being a hindrance, and not a help.
- Meetings. Seriously, people are drenched in “status update” and “team” meetings. If your company has to have “No meetings Thursday” then you’re doing it wrong. How about “No meetings except for Thursday”. That would make for a productive engineering team, not the other way around.
- Weekly Snippets, perf, etc. I was continually amazed by the amount of “extra cruft work” that goes on. I know it sounds important, but engineers should be coding & designing.
- Perf, Interviews & lengthly interview feedback. The old fashioned model of getting together in a room to discuss a candidate is way more efficient. Make sure that every single engineer in the building is participating in the interview process to spread the load more evenly. Don’t let the internal recruiters pick engineers for interviews, as they have favoritism and are improperly motivated. Limit to 1 interview per week, maximum. Make a simple system for “I can’t make this interview” and “I think this resume looks shitty and don’t want to talk to this candidate.”
- Discourage of open source software. There is so much innovation going on in the open source world: Hadoop, MongoDB, Redis, Cassandra, memcached, Ruby on Rails, Django, Tornado (web framework), and many, many other products put Google infrastructure to shame when it comes to ease-of-use and product focus. Engineers are discouraged from using these systems, to the point where they’re chastised for even thinking of using anything other than Bigtable/Spanner and GFS/Colossus for their products.
Get rid of the proprietary cluster management system.
Yes, seriously. What they have is a glorified batch-scheduling system that makes modern datacenters feel like antiquated mainframes. Dedicated machines and resources are what startups have, so give them to your best engineers, and they’ll do great things. You should have learned this from the teragoogle team. Start building a better, Virtual Machine based system where engineers can own & manage machine images themselves, all the way down to the operating system, dependencies, etc. If more structure is needed, use existing open source packages or develop new systems in house, and open source those. Build new “non-standard” data centers that don’t use the old system, and that every engineer can use.
The cluster management system’s fatal flaw is that it requires too large of an ecosystem, and pidgeon-holes running jobs into a far too restrictive container. It doesn’t allow persistent local disk storage, since jobs can be terminated and relocated at any time. Services running there are then cajoled into using Bigtable and/or Colossus for their persistent storage, which rules out virtually all other external database systems (MySQL, etc.). This is an antiquated and overly constrained model for job allocation.
Switch to team-based distributed source control.
Teams or large related teams should manage their own source code. Provide git-based hosting, and nothing else. Cross-team deliverables should be done at the binary release level, not at the source code level. Hard Makefile-type dependencies between teams need to be abolished.
Be the Bazaar, not the Cathedral.
Rethink the “lots of redundant, unreliable hardware” mantra.
Having to launch a simple service in multiple datacenters around the world, and having to deal with near-weekly datacenter maintenance shutdowns is unacceptable for an agile startup. Startups need to focus on product, not process and infrastructure. One persistent Amazon EC2 instance is much more valuable than a 100 batch scheduled jobs in a cluster that goes down for maintenance every week. Stop doing that.
Eliminate NIH-syndrome
Google has a very, very strong NIH (Not Invented Here) syndrome. Alternate solutions (Hadoop, MongoDB, Redis, Cassandra, MySQL, RabbitMQ, etc.) are all seen as technically inferior and poorly engineered systems. Google needs to get off it’s high horse, and look at what’s happening outside of it’s organization. Hugely scalable services like Twitter are built on almost entirely open source stack, and they’re doing it really efficiently. Open source solutions have a product-focus that’s missing from much of Google’s infrastructure for infrastructure’s sake engineering endeavors. Focusing on the product first, and using any available solution is the agile way to experiment in new spaces.
Additionally, by eliminating the NIH syndrome, Google needs to allow these open systems into it’s production environment. Amazon and RackSpace have nailed this with reliable, virtual hosting solutions, and this is allowing services built on those platforms to be portable, efficient, and agile.
Remember that small, special-purpose is more agile than big, general-purpose.
Google is famously good at building huge pieces of infrastructure that solve big, important problems. GFS & Colossus for file storage, Bigtable, Blobstore and Spanner for structured data storage, Caffeine for document storage and indexing.
But, when faced with a new problem or new requirements, projects are expected to pidgeon-hole their needs into one of these systems, or be chastised for “doing it wrong”. Additionally, when your application needs inevitably don’t fit or grow out of existing infrastructure capabilities, requests for improvement or enhancement are lost in the noise. This means small teams are crippled by the lack of agility of these monstrous systems.
Google’s engineers need to think & act like startup founders. Only develop what’s absolutely necessary to get your job done. Simplicity counts. Complex systems are hard to learn, debug, and maintain. Keep it small and focused.
Implement an in-house incubator.
Do this right now. When a current employee comes to you and submits their resignation letter, and says they’re joining a startup, you should immediately respond with “Oh! Well, let me tell you about our in-house startup incubator…”
Put smart people together in a room, let them think freely about products and infrastructure, and good things will come of it. In fact, I might argue that every Staff level engineer or higher should “go on sabbatical” to the in-house incubator for a period of a minimum of 6 months. Rotate people in & out, and let them bring their incubator learnings back on to the main campus. Have one incubator per geography, at a minimum, possibly more. Let people choose their best freinds/coworkers, and go off and do something great for 6 months. No managers, no meetings, no supervision.
Make it very clear that good, small ideas matter.
This is so important. One of the things I heard over and over was “If your product isn’t a billion-dollar idea, then it’s not worth Google’s time.” This message sucks. What you’re saying is “your great idea that might make millions per year is less important than a small tweak to ads or search”. Even if it’s true, you need to foster innovation of much lesser initial impact.
Google acquisitions of companies in the $5-50mm range means that at some level, small businesses are valued. Make this very clear. It sucks to have someone say “your $5mm idea isn’t big enough” on the one hand, and then watch Google buy up companies for $5mm each. This is bad precedent.
Eliminate internal language and framework cronyism.
By this, I mean: “Stop forcing people to do things The Google Way”. There were several times where I had seen “unGoogly” system desgins get shot down because they didn’t use Bigtable, GFS, Colossus, Spanner, MegaStore, BlobStore, or any of the other internal systems.
For example, languages like Python are shunned upon because they’re “too slow for web frontends”. Let teams use whatever tools and languages they want, and are most efficient in. Don’t pass judgement on infrastructure, pass judgement on Products. If someone launches a great system based on Oracle and a bunch of Perl CGI scripts running on Sun Sparc 5′s, then you should praise them. If they’re crushed under load, then praise them even more for their success.
Engineers at Google spend huge amounts of their time being forced to prematurely optimize their backend and frontend infrastructure. Most of the time, this benefits no one, as small products never get big enough to need such heavyweight systems, and are bogged down with the cost of multiple redundancy, and by using poorly behaved internal APIs that don’t meet direct product needs.
Make a general purpose cloud for internal use.
Amazon EC2 is a better ecosystem for fast iteration and innovation than Google’s internal cluster management system. EC2 gives me reliability, and an easy way to start and stop entire services, not just individual jobs. Long-running processes and open source code are embraced by EC2, running a replicated sharded MongoDB instance on EC2 is almost a breeze. Google should focus on making a system that works within the entire Open Source ecosystem.
Acknowledge that 20% time is a lie.
Virtually no one I knew in my entire career there had an effective use of 20% time. There are stories about how some products are launched exclusively via 20% time, and I’ve seen people use their 20% time to effectively search for a new internal position, but for the vast majority of engineers, 20% time is a myth.
I think it’s a great idea, and it needs to be made effective. 1 day per week isn’t reasonable (you can’t get enough done in just one day and it’s hard to carry momentum). 1 week per month would be great, but doesn’t do justice to your “main” project. Something needs to budge here, and engineers need to be encouraged to take large amounts of time exploring new ideas and new directions. Really fostering internal tools and collaboration might be the right answer. I’m not sure, maybe they should just give up on it and give everyone a 20% raise. Oh wait, they did that already.
Repeat your mistakes.
Engineers learn by doing, and learn by making mistakes. Having rules about system design puts unnecessary constraints on thinking and products. Having internal lore around things like “Google will never let another thing like Orkut ever happen again” is blatantly wrong. Orkut was (and still is) a huge success, period. None of the infrastructure stuff matters. Even recent mistakes (Wave, etc.) should be praised and engineers should be encouraged to repeat those mistakes.
“Google Scale” is a myth.
Yes, I said it.
Google Search (the product) requires vast resources. Almost nothing else does, and yet is constrained and forced to run “at Google scale” when it’s completely unnecessary.
Giving engineers the freedom to think & design out of the box with respect to infrastructure and systems means you’ll be more efficient in the long run. Providing reliable platforms and data centers means you’ll have less redundancy, and be more efficient.
Given that a single machine can easily have 64GB of RAM, 10TB of disk, and 8 CPUs, it’s amazing that any product launch needs more than just a couple of that class of machine. Let engineers push the boundaries, make mistakes, and run on the edge.
A small system that falls down under load is a huge success
A large system that’s wasting resources and has only a few users is a huge failure.
Hi Slacy,
Great post – I’d love to talk to you about reposting on Business Insider. Please shoot me an email if you’re interested. contributors@businessinsider.com.
Julie
This is not a surprise. The problem is once you grow to become a large public company, risk taking and startup mentality is discouraged. If for no other reason than people who have nothing to do with the internet are investing their money in your company. And they expect that investment to be protected. Right there and then, you are ‘agilely screwed’. Because mistakes affect stock prices. But mistakes are how you explore and learn.
Google is simply too big. Like Microsoft. Like Oracle. Like yes, Facebook. Too big to manage, means more managers. And that means more meetings, emails, procedures, etc… All just overhead.
Oddly enough, almost a carbon copy of memos that floated around within Microsoft in 2000. Reading this was like a flashback!
Really enjoyed this as I have spent a lot of time thinking about Google in the past. In your opinion, is the reason the switch was made back to Larry is that he has realized that Google is headed down the wrong path and wants to return it to its roots; and, if so, do you think that can be done? I am curious if you feel people internally are excited about the switch to Larry and generally if you can run a massive company of Google’s scale with the same energy and spirit as a start-up. Any other thoughts you could add would be more than helpful. Thanks, Adrian Meli
Thank you! It expresses very clearly a bunch of frustrations I experienced during my 3.5 years at Google. Good school, bad atmosphere.
I don’t believe it is curable though. The atmosphere, once established, will prevail forever.
It all starts with respecting other people’s opinions and valuing truth above petty interests.
There are lots of talented people there at Google, but mediocricy rules now. There’s no way you can beat mediocricy, they are a majority.
Fabulous article, and thanks for your refreshing honesty. IMHO, Google needs to get back to their core business model of focusing on search, indexing, and advertising through the capture of consumer eyeballs versus goofing around with GAPE and trying to compete with collaboration platforms like Office and Skype. They appear to want to be everything to everyone, and this fragmentation is killing their ability to focus and act quickly to market changes. Why not focus more on new advertising markets that leverage the vast consumer intelligence machine that they must have over there versus trying to make computerized 3D Scales of the human body???
You had me until you called twitter scalable.
I worked there from 2006-2010 (came in with the Writely purchase). This is absolutely spot on – I’ve documented and/or complained about many of these when I was there.
I hear good things these days, I think Larry has an open mind about changing the culture. Let’s hope he gets a chance to read this and make some changes.
Google isn’t a startup so I don’t see why it would want to act like one. If you wanted to work in a company that acts like a start up why don’t you leave google and go work for a start up?
They don’t need products to be pushed out as quick as possible like a startup does so while it might take longer to make sure things scale and use languages that take longer to develop in, it saves having to rewrite the product down the line when performance becomes an issue.
The vision I get from your idea is a company with hundreds or thousands of independent teams all using different languages and technologies pumping out all sorts of products of highly variable quality. Even if it works at first it is going to end up a huge mess in a few years when people leave and there isn’t anyone to maintain the old code.
Your article seems insightful overall, but I think the aversion to re-inventing the wheel is dangerous too. If Google hadn’t been willing to re-invent the wheel more than a decade ago, we’d still be doing all our Web searches on Yahoo! or Altavista.
I wrote an extended reply here.
Big companies are funny… I really wonder why would anybody stay …
I often wonder how to foster innovation. There have been some interesting TED talks about what motivates people. I think the “internal startup incubator” is a great idea.
-Sam
http://www.awkwardengineer.com
Wow, it’s gotten even worse than when I was there.
I think it’s the hiring process that is broken and which has been broken for a long time, particularly in Mountain View. There was a feedback cycle in which engineers only hired people “like themselves only more so” who in turn hired even more extreme comp sci students who knew how to write ever more beautiful and brilliant algorithms.
But the kind of reflective person who has managed to build amazing systems in the past by thinking about problems harder and more laterally and not bothering to keep up-to-date with the latest developments O(log N) complexity sort — well, they’re only a second class engineer and not worth hiring. Even more so for the engineer who has straddled business management and development at the same time — they haven’t spent as much time coding lately, so we’ll bring them in at level 3 if at all. And if an extroverted person makes it through the hiring process and then actually uses the supplied lunch time to meet people from other teams — wow, are they ever weird.
Mix and repeat for a few years and you end up with a company that has a few awesome technology niches, painfully slow development cycles, inter-team communication problems and continual issues with poor management.
But the hiring process is the elephant in the room. It is compulsory to believe that it is perfect, or perfect minus a few tweaks, because it successfully filtered out the wannabees, hired lots of very smart people, and therefore can’t be wrong. People get very angry when the issues are pointed out — it belittles your self-esteem and the mental model of yourself to admit that what you got through is actually a very flawed system.
So the hiring won’t change in any hurry. Larry Page could fix everything in the list above and do everything on his to-do list too, but the problems will be like hydra — or worse, perhaps: fractals. There will always be one more problem to solve to get innovation flourishing again and to “get google back to its roots”.
Innovation happens when you don’t have money and you have to come up with a solution anyway with whatever other resources — brains, experience, contacts, whatever — are available to you.
The grass is always greener on the other side.
Hello Slacy,
I am in fascination reading your analysis and the comments. I work at Yahoo! (and originally came from Altavista, so I take personally what Jeremey has to say). At Yahoo! we have already gone through a similar ‘maturization’ process as a company, with source code compilation and deployment issues, etc.. Google has a couple of big wins, some smart leaders, and a PR message that makes sense, but at the core level of how do you structure teams to get cool stuff done.. it doesn’t scale/fails/etc. in the current company model, frustration emerges, etc. Get it.
At Yahoo! we relish the fact that we are somewhat underdogs now, as our Product executive says, the ‘house is on fire’. Many of your callouts and comments resonate with me and my team as things that we are actively addressing as we reshape Yahoo! to recover from its hangover of ‘undeserved success’ and position the company to compete at scale in the digital media space (which is an area where I think we can play to our strengths, help our partners, and build some really cool user experiences and technology).
In any event, I am trolling a bit. My email address is private (per my comment action on your blog), but I assume you have it. If you would like to talk to me about how you can take your thoughts and roll them out at scale in the context of a team/company that has retreated, recognized our sins, etc. and decided ‘how we will kick some ass, deliver some game changing user experiences, and make money in the process’, drop me a note. I run the engineering team that delivers Yahoo! frontpage, news, sports, finance, movies, shine, etc. I am intensely interested in probing your brain to understand what was F**ked up at google, and making sure we can use that in our rebirth here at Yahoo!. Drop me a line if you are interested. The world needs better alignment between what customers want, and what companies like Y!, Facebook, Microsft, and Google deliver, and I think you might be able to help Y! deliver what our users want.
Thanks, sorry for the blatent ‘come and talk to me’ message, but hey, this is capitalism at its best and if the big G! isn’t letting you realize your potential, lets have a chat.
John T
(email as part of this post, but not public)
Why should google’s destiny be different from sgi or sun? They all made their billions for a few years, then engineers get overrun by management.
For those who’ve been in software for any significant length of time, this is an old story. All companies have issues like these, or some other set. As anonymous said, the grass is always greener on the other side.. until you realize it’s not.
And that we’re talking about Google shouldn’t make this disenchanted employee’s perspective any more interesting. In fact, it should be assumed that they have problems like this. It’s just the way of things… Moving on…
Google is no longer a start-up. Along with the $586 share price (and the associated millions for Google engineers) comes the realization that you can’t run a successful public company with engineers who behave as “violent disruptors”. A level of consistency and predictability is demanded by the market.
If you like working in a start-up environment – join a start-up. By definition, you can’t stay a start-up forever. It’s unrealistic to expect a multi-billion $ publicly traded company to behave like one.
I worked there from 2005-2009 and couldn’t agree with you more…but I think you aren’t being critical enough. I worked with the PSTN team that powered GOOG411 and Google Voice. What a joke. Google Voice had/has huge potential, but like most everything at Google nowadays its potential is lost to way too many Engineers trying to prove how smart they are for performance review time. Very little innovation takes place inside Google anymore, and what little does is mired down by huge architectures. Only the projects that don’t have these contraints tend to grow, Android being one, but nowadays even Android is starting to get mired down. I used to work at Microsoft 1998-2005, saw the same thing happen, and I feel sorry for anyone working at these or similar companies. I have worked for a <50 person company with <10 engineers for the past 2 years, and I *love* the problems that they have!
Wow. I recently left Yahoo!; s/Google/Yahoo!/g along with corresponding internal home-grown tech name substitutions, and it still reads true.
Re the high-horse: what I kept hearing at Y! was “We’re special because we’re big, and no one else understands our scale, so we have to build it all ourselves.” And, as you observe, I pointed out many examples where Y! is no longer unique, and that others are in fact operating at comparable scales. But the belief in this is too entrenched, and no one wants to introduce new tech from outside because then we wouldn’t all be using the same one-size-fits-all solution, which would be a *terrible thing*. Oh well.
Thanks for writing this blog. All companies risk becoming too committed to the things that originally made them great. They can become stuck Defending and Extending their original success formula. You’ve pointed out several areas, from technology to hiring, where Google appears to be locking-in on what worked in the beginning — yet overcoming these lock-ins may be critical to future success. Competitors create change in the market, and it becomes critical that early leaders change to remain competitive. I was pleased to cite your blog in a recent Forbes article, re-iterating the risks at Google and reinforcing many of your points for Larry Page to take action (I especially like your incubator idea) if Google is to remain successful. Read the Forbes article here: http://bit.ly/gJyDZs
>>0x4a6f4672 says:
>>Your photo gallery gives a database error. And your blog is setup poorly (categories and archives missing, no about page, etc).
Steve write so good that you really shouldn’t care about the photo gallery with database error. This post is excellent.
A refreshing take on the internal growing pains of Google. I worked at Google from 2002 to 2009 as a Software Engineer. Although I was never able to articulate it as well as you have in this blog post, you have definitely touched on some key areas that resulted in me quitting. Thanks for the post.
Wait a moment, this is magnitudes better than what happened in Google China. Almost everything was broken there from the very beginning. Here’re a few things popped up in my head:
- With >200 engineers, it achieved *nothing* in 4+ years. Plus, there were no healthy work relationship established between Beijing engineering team and its headquarter counterpart, at least it was so in teams I ever worked for.
- Its HR seems to tend to hide a lot of information from new hires. It could give you an senior level offer, which you only found out later actually wasn’t. Or, it didn’t tell you internal transfer policy in HR orientation when on board.
- Really lousy performance management, especially regarding poor performer. One has to wonder why so many not-qualified-as-engineer guys can hang around like for ever. When confronted, managers used to say “well, Google is famous for not managing poor performers well”. They seem to take that for granted. Even, they are sort of proud of it, which I find really amusing.
- All those reflected to business outcome. Think about it, Google China had staff number about 1/8 to Baidu’s, and it didn’t have big data center to run in mainland China, but it was still not profitable (at least in year 2010 when I left). Why? One reasonable doubt could be it did a lot worse than search market share of China may have suggest.
So, ladies and gentlemen, I guess I just show you a new definition of AIG (arrogant, incompetent, and greedy). Damn, many engineers worked there were hired directly from universities. Working for Google is supposed to be a golden start for their careers. But it’s far from that; it is a blow.
I love Google and all their great products, but the bottom line is that they could be in a lot of trouble and it’s very easy to see why. People use Facebook now all the time. And then, when they need to search, they go to Google. However, there is no reason for this. It would be easy to implement a “search the Internet” feature on Facebook. Once that is done, nobody will need to go to Google. And, since 90% of their revenue still comes from search, they would be in a LOT of trouble.
Entrepreneurs come up with ideas, break down barriers and go to market fast with alot of ups and downs as they figure out their space. Once they have done this the management team comes in for more predictability and sustainaility. This is when culture becomes important as everything cascades off this.
In other words, history repeats?
Why do so many of your recommendations to Larry Page suggest the reality inside Google is a growing creeping organisational sclerosis? Slacy, your quite comprehensive list of problems and recommendations, many of which stem from the problems of success (i.e. scale issues, complicated interdependent products, a growing need for communication and understanding but size itself becomes the obstacle).
Are innovative organisations inherently self limiting? Is there a certain inevitability to Christensen’s idea of the innovator’s dilemma, that one organisation cannot be all things to all product or service innovation and delivery? Time to spawn independent subsidiaries maypaps?
Notes:
Christensen, C. M. (1997) The Innovator’s Dilemma: When New Technologies Cause Great Firms to Fail, Harvard Business School Press.
Interesting stuff, I think python maybe used now more than it was while you still worked at Google?
Just wanted to point out a typo:
‘“unGoogly” system desgins’ -> ‘“unGoogly” system designs’
Cheers!
Thanks for this interesting and comprehensive post. After working in a startup that did everything you asked for, I feel that the Google Way makes a lot of problems disappear that bogged us down. Especially scaling small MySQL installations, coping with stubborn engineers writing excuciatingly slow web frontends in Python etc.
I do not agree that only search needs a huge infrastructure. What about maps, video, mail, books? In fact, every important Google product benefits from its infrastructure and interoperability. Everything else should be done in startups.
Furthermore, I am thankful that Google does not run an incubator. Instead, they provide a huge service to the world by releasing trained engineers into the wild.
Richard,
Really? “It would be easy to implement a ‘search the Internet’ feature on Facebook“?
Google wasn’t exactly the first company to build a search engine. Why is it that the world’s using Google today and not one of the plethora of search engines that were around before Google? How did Google come out on top?
I can’t tell you what made up other people’s minds, but I can tell you what got me to switch: useful and relevant results. Web searching back in the day was a chore—you could either get a few results on a narrow range of topics from one site, or you could get a huge flood of mostly irrelevant and useless garbage from another. I’d sort of assumed things had to be this way, that search engines could index lots of pages or they could return quality results from a few pages.
Google broke that assumption. Suddenly, I could search a huge sample of the Web and do less digging to find what I wanted. They’ve gotten better at it since then, too.
If it were as easy as you seem to think it is to get this right, other search engines would’ve quickly countered Google’s moves early on and this newcomer would’ve never stood a chance.
That “search the Internet” feature, from what I can gather, is actually kinda hard to get right.
«Meetings. Seriously, people are drenched in “status update” and “team” meetings. If your company has to have “No meetings Thursday” then you’re doing it wrong. How about “No meetings except for Thursday”. That would make for a productive engineering team, not the other way around»
Seriously, you’re my hero.
Very true. If social tools to share status and ideas are there for us to use, why would you need to meet with people?
Ebbba ooof rreii oma lefta reef!
Hi,
Some of the things you said might be true, but in a very constrained environment. The way I see it is the people who make a choice to join a startup are really passionate about their work. They generally are partial entrepreneurs in themselves, who know how to utilize the freedom provided to them. All the things you said will be true if Google was a startup, because then it will have employees like that.
Now, most of the people join Google because its ‘Google’. It gives you a fat salary, it is a market leader and you get a lot other perks. These are good engineers, just that not all are passionate enough to do all the things you just said. Had Google been a startup today, it would take risks to let engineers go build a great product which is not reliable. But today, if Google launches something 10 million people jump in within a couple of weeks (Google+), you can’t afford to make mistakes at such a huge scale else it will affect the name Google is today.
Also each of you bullet points are change in policies which needs atleast 3-5 years of time to be implemented in a company of ‘Google’s scale’. And if it does not work out you don’t have a way to come back.
I feel the way Google work to day is it gives engineers enough freedom to come up with ideas and work freely on whatever projects they work on. And that is still appreciable, because not many companies do that. But, at the same time it keeps a control over employees so that if someone is making a wrong decision, it does not affect too much.
As far as running search on a couple of machines with huge resources is concerned, answer this – would you use Google search if it goes down just because a someone spilled coffee over a transformer placed in Mt. View?
I believe the biggest problem of Google is not the datacenters that look funny, from developer’s point of view, compared to, say, rackspace – but the googlers themselves. All this trouble with NIH, territorialism, SREs preventing a launch unless Larry or Marissa tells them to stop, all that greed and envy – they are just incurable. Just move on. No company was ever cured by nice people trying to do the right stuff.
There are things that may be true, but with an organisation with over 30k people worldwide there should be some constraint to allow it work properly.
Brainstorm is important, but exceed in time is counterproductive hence I agree materialise all the need in one go.
I do not agree with freedom in the wild. Giving people the chance of use what product suit them best is not the answer for making a better product. What if your code work and then need to be re-written in a different language to make it usable and deplorable in the company?
An what from a maintenance poit of view. The engineers that take care of the infrastructure need to be aware of so many situations that sooner this will go in the wild.
You can pretend some agility on your own like virtual machine, but not all the rest you said.
Certainly considering thir party products already on the market and making them better or simply using them, avoiding the NIH syndrome is somewhat they can think about but I’m not a googler so I can’t tell you more.
Well, great diatribe but it all pre-supposes two very important things, one that Google did anything earth-shattering and that the so-called innovations were really innovations and not just re-worked decades old ideas. Really, you think Google invented technology or something? Creating “big table” is not exactly earth-shattering, try maybe a inventing the wheel like Codd did. But nice self-aggrandized rant anyway.