In my last blog post, I talked about what it's like to get started at Google as a new engineer. In this post, I'll talk about how new projects get started.
Standard disclaimer applies: This is my personal blog and nothing I'm saying here is endorsed or approved by Google. This is only based on my personal experience. Take it with a grain of salt.
Google is well known as having a bottom-up engineering culture. That is, new projects typically arise because a group of engineers get together, decide a problem needs to be solved, devise a solution, and convince others to (a) join in the effort and (b) launch it. It is rare -- although not unheard of -- for a Google project to start with a high-level mandate from some executive. (I have heard that this is how Google+ got its start, but I wasn't there at the time, so I don't really know.) More typically, a grassroots effort emerges out of engineers trying to build something that they think is important and will change the world. Or at least scratch an itch.
How my project got its start
My team is responsible for a range of projects to optimize and streamline the mobile web. The main thing we are known for is the Chrome Mobile data compression proxy, which provides users of Chrome on Android and iOS a switch they can flip in the browser to compress web pages by 50%. I thought it might be instructive to talk about how this project came about.
When I started the team in 2011, I was given a very broad mandate: Go fix the mobile web. Initially, we spent a bunch of time just trying to understand the problem. At the time, there were no good tools for even measuring mobile web page performance. Now, we have things like Webpagetest for mobile, but at the time you couldn't get decent measurements without a lot of work. So, we built a testbed for collecting mobile web measurements and bought a bunch of phones and tablets and started collecting data. We spent a huge amount of time analyzing the data and playing around with various technologies, like PageSpeed, to see what kind of gains could be had.
At one point we realized that the only way to move the needle with mobile web performance was to build our own proxy service which could be integrated into a browser. Around the same time, the Chrome Mobile project was ramping up, and we realized that the technology we were building would be a great addition to Chrome when it became available for Android and iOS. So, we went to the Chrome team (which we were not yet a part of) and pitched the idea -- would it make sense to integrate this hypothetical proxy into the browser, provide a setting for users to enable it? At the time, we didn't even have the proxy yet -- just a slide deck and a crude, proof-of-concept demo. But we had a lot of ideas of what it could do and how it would work.
Fortunately, the Chrome team loved the idea and even offered to take our team on as part of the Chrome project. Of course, they hadn't agreed to launch anything yet -- that approval wouldn't come until many months later -- but we had their blessing to develop the idea further and get it to a state where it could be dogfooded within Google. So we built it. We got it to dogfood. We collected data from real users (well, Googlers anyway). The data looked good, so we got approval to launch it externally, first behind a flag, then in the Chrome beta channel, and finally launch it to everyone. Boom!
So the idea for the proxy service and the project as a whole came entirely from within our team. Nobody told us to do this. And it was our job to "sell" it internally, in terms of turning the idea into a fully-baked feature that could launch with Chrome. In a lot of ways, it's like being a startup company (although one that does not have to worry about funding and already has fancy cafeterias and a gym).
Does this generalize?
I can't say for certain that my experience is the standard way of getting new projects off the ground at Google, but it seems to be.
Projects often seem to get their start with one or two engineers who have an itch to scratch, and come up with something compelling that they want to build. They might start the project on their own, in their 20% time (on which see more below), or they might spawn an effort out of their existing work.
A typical example might be where an engineer realizes that a new system needs to be built to solve a problem that they keep running into all the time (measuring mobile web pages, say). So with the blessing of their manager (or not, in some cases), they carve out time to get that project off the ground. If it's successful, it might grow, and more engineers will start to get involved.
New projects often die, too. Sometimes a project will start out with a couple of people, they'll spend a quarter or two trying to get it off the ground, and the effort fizzles out for any number of reasons. One example is that it turns out to be much harder than expected. Another is that other priorities come up and they don't have the time to run as far with the idea as they had hoped. Another is that some other project comes along which is a broader, more general form of what they were trying to do, so they decide to join forces (or just shut down the original effort).
What about 20% time?
Much has been written about Google's "20% time", whereby engineers are allowed to work on projects unrelated to their main job. (You can't do just anything for 20% projects -- taking guitar lessons wouldn't be allowed, for example -- but the definition is pretty broad.) 20% projects are a great way to seed a new effort, since (a) you don't really need any formal approval to work on them, and (b) it gives engineers a chance to do things that they would not otherwise find the time to do.
Gmail famously started as a 20% project. (The original press release was ironically posted on April 1, 2004, but it was not actually an April Fools' joke!)
There have also been many unfounded rumors of 20% time's demise. From where I sit, 20% time is alive and well, and several engineers on my team have active 20% projects. For example, one of them contributes actively to our internal platform for employees making charitable contributions, called "G-Give". Another contributes to the smart contact lens project. My own (unofficial) 20% project is doing outreach activities to the Computer Science research community -- serving on program committees, reviewing research proposals, that kind of thing. (It actually takes a lot less than 20% of my time, but don't tell my boss that.)
That said, 20% time is not used uniformly across the company and some managers are probably allergic to it. I don't think all engineers should do 20% projects, since often people can have more impact if they spend 100% of their time on their "day job" -- the 20% would be a distraction and not necessarily help them get promoted.
But promotions are the subject of my next blog post, so I'll leave it at that.
Standard disclaimer applies: This is my personal blog and nothing I'm saying here is endorsed or approved by Google. This is only based on my personal experience. Take it with a grain of salt.
Google is well known as having a bottom-up engineering culture. That is, new projects typically arise because a group of engineers get together, decide a problem needs to be solved, devise a solution, and convince others to (a) join in the effort and (b) launch it. It is rare -- although not unheard of -- for a Google project to start with a high-level mandate from some executive. (I have heard that this is how Google+ got its start, but I wasn't there at the time, so I don't really know.) More typically, a grassroots effort emerges out of engineers trying to build something that they think is important and will change the world. Or at least scratch an itch.
How my project got its start
My team is responsible for a range of projects to optimize and streamline the mobile web. The main thing we are known for is the Chrome Mobile data compression proxy, which provides users of Chrome on Android and iOS a switch they can flip in the browser to compress web pages by 50%. I thought it might be instructive to talk about how this project came about.
When I started the team in 2011, I was given a very broad mandate: Go fix the mobile web. Initially, we spent a bunch of time just trying to understand the problem. At the time, there were no good tools for even measuring mobile web page performance. Now, we have things like Webpagetest for mobile, but at the time you couldn't get decent measurements without a lot of work. So, we built a testbed for collecting mobile web measurements and bought a bunch of phones and tablets and started collecting data. We spent a huge amount of time analyzing the data and playing around with various technologies, like PageSpeed, to see what kind of gains could be had.
At one point we realized that the only way to move the needle with mobile web performance was to build our own proxy service which could be integrated into a browser. Around the same time, the Chrome Mobile project was ramping up, and we realized that the technology we were building would be a great addition to Chrome when it became available for Android and iOS. So, we went to the Chrome team (which we were not yet a part of) and pitched the idea -- would it make sense to integrate this hypothetical proxy into the browser, provide a setting for users to enable it? At the time, we didn't even have the proxy yet -- just a slide deck and a crude, proof-of-concept demo. But we had a lot of ideas of what it could do and how it would work.
Fortunately, the Chrome team loved the idea and even offered to take our team on as part of the Chrome project. Of course, they hadn't agreed to launch anything yet -- that approval wouldn't come until many months later -- but we had their blessing to develop the idea further and get it to a state where it could be dogfooded within Google. So we built it. We got it to dogfood. We collected data from real users (well, Googlers anyway). The data looked good, so we got approval to launch it externally, first behind a flag, then in the Chrome beta channel, and finally launch it to everyone. Boom!
So the idea for the proxy service and the project as a whole came entirely from within our team. Nobody told us to do this. And it was our job to "sell" it internally, in terms of turning the idea into a fully-baked feature that could launch with Chrome. In a lot of ways, it's like being a startup company (although one that does not have to worry about funding and already has fancy cafeterias and a gym).
Does this generalize?
I can't say for certain that my experience is the standard way of getting new projects off the ground at Google, but it seems to be.
Projects often seem to get their start with one or two engineers who have an itch to scratch, and come up with something compelling that they want to build. They might start the project on their own, in their 20% time (on which see more below), or they might spawn an effort out of their existing work.
A typical example might be where an engineer realizes that a new system needs to be built to solve a problem that they keep running into all the time (measuring mobile web pages, say). So with the blessing of their manager (or not, in some cases), they carve out time to get that project off the ground. If it's successful, it might grow, and more engineers will start to get involved.
New projects often die, too. Sometimes a project will start out with a couple of people, they'll spend a quarter or two trying to get it off the ground, and the effort fizzles out for any number of reasons. One example is that it turns out to be much harder than expected. Another is that other priorities come up and they don't have the time to run as far with the idea as they had hoped. Another is that some other project comes along which is a broader, more general form of what they were trying to do, so they decide to join forces (or just shut down the original effort).
What about 20% time?
Much has been written about Google's "20% time", whereby engineers are allowed to work on projects unrelated to their main job. (You can't do just anything for 20% projects -- taking guitar lessons wouldn't be allowed, for example -- but the definition is pretty broad.) 20% projects are a great way to seed a new effort, since (a) you don't really need any formal approval to work on them, and (b) it gives engineers a chance to do things that they would not otherwise find the time to do.
Gmail famously started as a 20% project. (The original press release was ironically posted on April 1, 2004, but it was not actually an April Fools' joke!)
There have also been many unfounded rumors of 20% time's demise. From where I sit, 20% time is alive and well, and several engineers on my team have active 20% projects. For example, one of them contributes actively to our internal platform for employees making charitable contributions, called "G-Give". Another contributes to the smart contact lens project. My own (unofficial) 20% project is doing outreach activities to the Computer Science research community -- serving on program committees, reviewing research proposals, that kind of thing. (It actually takes a lot less than 20% of my time, but don't tell my boss that.)
That said, 20% time is not used uniformly across the company and some managers are probably allergic to it. I don't think all engineers should do 20% projects, since often people can have more impact if they spend 100% of their time on their "day job" -- the 20% would be a distraction and not necessarily help them get promoted.
But promotions are the subject of my next blog post, so I'll leave it at that.
You miss the one big difference from a startup company. Yes, you don't care about funding and you have a fancy cafeteria, but someone else (be it Larry, Sergey, Eric, or someone else at a higher level) is making millions of dollars over your work, and you get a slightly-better-than-industry-standard-of-cubicle-farms paycheck. Just because you work with other clever guys, and everything is shiny doesn't mean they are not ripping you off.
ReplyDeleteI'd trade job stability at Google over the uncertainty of a startup any day, but that's because I'm almost 40 years old and have a family to take care of. Also, you have no idea how much I make, but let's just say "slightly-better-than-industry-standard-of-cubicle-farms" somewhat misses the mark.
ReplyDeleteHi Matt, clearly Anonymous does not know how much money “star” engineers make. Knowing some salaries for junior Google engineers, and the ballpark for Harvard professors, I would guess it’s between “a lot” and “a lot more”.
ReplyDeleteHowever, Anonymous is right about Google (and other tech giants) ripping their employees off, at least in the past: http://www.lieffcabraser.com/Case-Center/Apple-Google-Silicon-Valley-No-Cold-Calling-Anti-Poaching-Lawsuit.shtml
Aren't you an at-will employee? Do you have a 6 months or longer notice period in your contract? Have you though about what would happen if Google loses a big chunk of Ad market and profits drop to one tenth of current value? (Actually even if that happens they would probably keep you, but a big layoff might happen for other employees.) Stability might be an illusion.
ReplyDeleteCouple of grad students in a garage is not the only way to form a startup. There are many people with money, business contacts, experience, etc. They always seek talented developers, and their only way to attract them is to give more money, more equity, and more initiative. Such small companies are usually stable too, cause they are lean and they don't have huge costs to operate.
For the other point, yes I don't know your exact salary and equity, but I might have a good idea or maybe an overestimate on it. Do you ponder how much "star engineers" would make if they work in a smaller company though? or do you know how much your manager is making? or a sales person? Are you %100 certain you are getting a portion of profits which corresponds to your contribution, or the money you are getting is good enough for you and that makes you believe that it is fair?
Now, Google indeed provides you with vast amount of resources and scale, and that has real value (unlike the fancy restaurants or toys), but please be careful when comparing it with other values.
At your age with your career and wisdom, these questions might be already answered and might not be that important. But for the younger developers who are reading these, I'm concerned that they will make a decision and will miss opportunities. So here is my advice to them:
Google is an awesome place for a new graduate to be in, but it is not the only place and definitely not the final destination, it might even be extinct 15 years later. So always look around, and never confuse your managers and colleagues with your family.
Sorry, I didn't mean to come across as bashing small startups.
DeleteI have no illusions of job security here -- everyone is at will, and Google probably won't be around forever. For now I'm happy ridin' this gravy train though!
I agree 100% that I could be making more money elsewhere, but making more money is not my immediate goal in life.
Personally, I've yet to find a small startup that really excites me -- although maybe one will come along one day and offer me a big opportunity to get in on the ground floor.
One thing I like about working for a big company, frankly, is that I have the freedom to work on "unsexy" things that don't necessarily feed into the bottom line. Google doesn't make any money directly on the things that I'm working on. My work is more about supporting the ecosystem of the mobile web as a whole, rather than tapping into a revenue stream. And one reason I've never been interested in starting my own company is that I really dislike having to worry about raising funding. (Eight years as an academic taught me that lesson very well, thank you.)
But I'd agree with your main point. Google is not for everyone, and it's not the be all end all. This post was intended to answer frequent questions I get about how projects work there.
I didn't mean to bash Google either. Looking forward to your further posts.
DeleteHi Matt, I found your post very eye-open and useful for people like me, who are going to work in Google or want to know more about the exciting careers there. I do not really understand why this post could possibly make some people uncomfortable. Nevertheless I am a fan of your blog now, and please keep posting!
ReplyDeleteDear Matt,
ReplyDeleteThank you for sharing your knowledge and experience. It has been really helpful for me.
I have two questions which are irrelevant to this post.
In one of your posts, “So, you want to go to grad school?”, in this comment:
http://matt-welsh.blogspot.com/2010/09/so-you-want-to-go-to-grad-school.html?showComment=1284843970471#c1439110369344324707
you mentioned that independent research in CS is possible. Now I have two main questions from you:
1) That comment was posted in 2010 and I think you were still in Harvard at that time. Do you think it is still possible (considering ever-increasing research in companies like Google and current state of Computer Science research)? If yes, what would your advice be to someone who wants to do research independently? What should he do exactly? (By research I mean “doing real and fundamental science” not trendy science. Something that certainly has impacts in the future.)
2) What areas of CS/CE you think is more suitable? (By asking that I mean, for example, in Machine Learning you need data and some academics go to Google because it has the data and maybe it’s difficult to being a ML researcher without any provided data.)
I would really appreciate if you could help me. Thank you so much again.
Best regards.
PS. I have a B.Sc. in Software Engineering.