Skip to main content

Being Googley

I've been at Google for almost a year now and have been thinking back on what my expectations of the job would be like compared to what it has turned out to be. This got me thinking about corporate culture in general and how important it is for fostering innovation and being successful.

Google is well known for having a creative work environment with tons of perks -- free food, yoga classes, massage, on-site doctor. Here in Seattle, we can borrow kayaks to take out onto the shipping canal next to the building. (I am fond of telling people this but know full well that I am unlikely to ever take advantage of it.) On the surface these things might seem frivolous, but I think they go a long way towards creating an environment where people are passionate about what they do. The term we use is "being Googley," meaning, doing whatever it is that Google people do: thinking big, focusing on the user, not being evil, etc. On a more day-to-day basis, being Googley means turning out the lights when you leave a conference room, being friendly and helpful to new engineers, being a good citizen.

Google is by no means the only company like this: Yahoo, Facebook, and Amazon are great examples, and many other Internet-era startups follow a similar model. But this is miles away from what I thought corporate life would be like before I joined Google. To be sure, most of my prior exposure to corporate life (that is, before doing my PhD and becoming a professor) was through internships I did at a couple of older technology companies. I spent time writing code at a company that built semiconductor testers, as well as a large electronics company in Japan. I had also visited several large industrial research labs in the US, places that in some cases have been around for more than 50 years. I had a very hard time imagining myself taking a job at any of these companies: the sea of cubicles, drab beige walls, terrible cafeteria food, very few people under 40. Like Dilbert in real life. I wonder how those companies continue to attract top talent when there are places that are so much more appealing to work.

The Google culture is not just about lava lamps in the conference rooms though. The thing that surprised me the most is that there is very little hierarchy in the company: every engineer has the opportunity to create and lead new projects. It's not uncommon for something cool to start up with a few engineers working in their "20% time" -- GMail being one famous example. It is rare for a technical edict to be handed down from on high: projects are usually bottom up and are driven by what the engineers want to accomplish. To be sure, there are projects that could benefit from more adult supervision: things can go off the rails when you don't have enough management. But it's amazing what a merry band of hackers can put together without a lot of imposed structure or artificial constraints from the Pointy Haired Boss. I think the result is that engineers feel a lot of ownership for what they create, rather than feeling like they are just building something to make management happy.

When I was in the Google office in Cambridge, I worked on the team that builds Google's content delivery network -- a huge system that carries a significant chunk of the Internet's traffic (mostly YouTube). Almost everyone on the team was a good 10 years younger than I am (and way smarter, too). There was very little oversight and everyone kind of pitched in to keep the thing running, without anyone having to be told explicitly what to do. I was amazed that you could run such a large, complex project like this, but it seems to work. It's a hacker culture at a large scale. Companies like Facebook and Amazon are run pretty much the same way. All of this seems to turn the conventional wisdom about what it takes to run a successful company upside down. This won't be a surprise to anyone who spent time at startups in the last 10 years, but I'm new to this stuff and surprised that it even works.


  1. Well said. If you hire great people and have the right culture (and you make sure you hire people who will "get" the culture), all else will follow. If you don't, then no amount of management (or even financial incentives) can save you.

  2. That's great we still have Google, Facebook, Amazon and innovative start up companies to hire best of Compute Scientists and give these great perks, I wanted to comment on your previous blog regarding CSE education (from student and then working in old technology company perspective) as enrollment and opportunity/job-prospects are co-related.

  3. Matt, I'm at one of those companies with drab walls and a sea of cubicles. Turns out that 50 years ago, that was an innovative way to run a company (HP) --small groups, open door policy, etc. Nonetheless, in case you're wondering what keeps people working here ... it's the people around them (even the ones above 40) that make them better. I'm sure that's true at Google, as you allude to. But, it's also true in the drab places. What matters is the opportunity in front of you, the people around you, and the facilities to make that happen. You get that at Google and other places in high tech, but even if you can't find a job at Google, all is not lost, even at the drab places.

  4. Hi Mehul... You'll notice I said nothing about the quality of the people or work done at such companies... I have many friends and colleagues at those places of course! It is still striking to me that there seems to be such a cultural gap though.

  5. Interesting article........what I can make out is that Google is a rocking place for the young grads. But may not be so for doctorates or senior pros. They would be better off somewhere else where they'll be engaged more in a leadership kind of stuff rather than still be a s/w engg. and lose sleep over the million lines of code.

    Just a personal opinion....Nothing against Matt!

  6. Edugeek - what you're saying makes no sense. Who do you think has the leadership positions at Google?

  7. @Matt: What I want to say is that I feel doctorates should do more of research rather than be a pure s/w engg. They should be involved in higher level research, publish and provide directions to the junior staff rather than themselves be a part of this implementation. I know there are many will who will disapprove. But I feel there should be some separation between doctorates and the grads....

  8. Contrary to popular belief, even within Google, Gmail was actually _not_ a 20% project; Paul Buchheit (the creator of Gmail) tells the real story starting on page 161 of "Founders at Work" -- he was asked to work on an email project, and it was mostly his full-time job. Search Google Books with the query 'founders at work buchheit gmail 20 percent' to access the full text. Steven Levy also reports on the true origin of Gmail around page 169 of "In the Plex", although the full text doesn't seem to be as available.

    Perhaps you could update your post to highlight Google News or some other true 20%-time project instead of Gmail? Thanks for the post; your reflections on your experiences at Google are fascinating.

  9. For T. Record - Thanks - I will check those references out. Google's own official press release for GMail from 2004 says that "The idea that there could be a better way to handle email caught the attention of a Google engineer who thought it might be a good "20 percent time" project." See:
    I wonder why there is this discrepancy?

  10. Edugeek - You seem to be conflating research and leadership. These do not always go hand in hand; I know many "researchers" at various companies, including Google, who are not leading teams. I respectfully disagree that a pure research job is the only viable career path for someone with a PhD, but see my previous other blog posts on that very topic :-)

  11. @Edugeek: The line between engineering and research, like everything else in life, is not clear cut. There are many good engineering work that count as research, and have gotten into top conferences like OSDI. On the other hand, good systems research typically require good implementation, i.e. engineering.

    There seems to be this prevalent misconception that having a PhD means you belong to an elite class. A PhD is just a piece of paper, what matters at the end of the day is that you can build a better system, which must entail good design, implementation, analysis, measurement etc. It is something that someone with or without a PhD can do, believe it or not. And what matters is that the system is better. Not because a committee says so, but because the many millions of everyday users say so.

    There are many PhDs who do not deserve one. There are many engineers who do. Research papers should be the by-product of good work, not the main objective. Research should be conducted on the way to doing useful work, not to be done for the sake of 'doing research just because I have a PhD' itself.

  12. Anon - It's also a fact of life that having a PhD does give you opportunities that folks without PhDs often do not have. At least in terms of getting a "research" position at most companies, or a faculty job, having a PhD is pretty much mandatory (though not always). The way I view it, having a PhD trains you to approach problems scientifically and think deeply about them at a certain level of abstraction. This is not to say that people without PhDs can't do this (or even that everyone with a PhD can). It's training, nothing more, and by no means does having a PhD entitle you to anything.


Post a Comment

Popular posts from this blog

Why I'm leaving Harvard

The word is out that I have decided to resign my tenured faculty job at Harvard to remain at Google. Obviously this will be a big change in my career, and one that I have spent a tremendous amount of time mulling over the last few months.

Rather than let rumors spread about the reasons for my move, I think I should be pretty direct in explaining my thinking here.

I should say first of all that I'm not leaving because of any problems with Harvard. On the contrary, I love Harvard, and will miss it a lot. The computer science faculty are absolutely top-notch, and the students are the best a professor could ever hope to work with. It is a fantastic environment, very supportive, and full of great people. They were crazy enough to give me tenure, and I feel no small pang of guilt for leaving now. I joined Harvard because it offered the opportunity to make a big impact on a great department at an important school, and I have no regrets about my decision to go there eight years ago. But m…

Rewriting a large production system in Go

My team at Google is wrapping up an effort to rewrite a large production system (almost) entirely in Go. I say "almost" because one component of the system -- a library for transcoding between image formats -- works perfectly well in C++, so we decided to leave it as-is. But the rest of the system is 100% Go, not just wrappers to existing modules in C++ or another language. It's been a fun experience and I thought I'd share some lessons learned.

Why rewrite?

The first question we must answer is why we considered a rewrite in the first place. When we started this project, we adopted an existing C++ based system, which had been developed over the course of a couple of years by two of our sister teams at Google. It's a good system and does its job remarkably well. However, it has been used in several different projects with vastly different goals, leading to a nontrivial accretion of cruft. Over time, it became apparent that for us to continue to innovate rapidly wo…

Running a software team at Google

I'm often asked what my job is like at Google since I left academia. I guess going from tenured professor to software engineer sounds like a big step down. Job titles aside, I'm much happier and more productive in my new role than I was in the 8 years at Harvard, though there are actually a lot of similarities between being a professor and running a software team.

I lead a team at Google's Seattle office which is responsible for a range of projects in the mobile web performance area (for more background on my team's work see my earlier blog post on the topic). One of our projects is the recently-announced data compression proxy support in Chrome Mobile. We also work on the PageSpeed suite of technologies, specifically focusing on mobile web optimization, as well as a bunch of other cool stuff that I can't talk about just yet.

My official job title is just "software engineer," which is the most common (and coveted) role at Google. (I say "coveted&quo…