Previous entries: Part I and Part II. I will continue to bold statements which come from that specific work experience.
MTV
It’s testament to Google’s technical DNA and stellar reputation that the company remains a very desirable work destination for a lot of current and to-be software engineers. It has taken some lumps in recent years, but its engineering still features systems at massive scale, abundant technical challenges, all wrapped in a comfy work environment. And even though much of the hiring process is well-documented and public at this point, my first post on this blog—on how to get past the phone screen—still gets the most traffic on most days 7 years later.
MTV is the internal code for Google’s Mountain View headquarters, and when I chose to work out of Google HQ, I was given a choice of 3 teams and ultimately landed1 on a little-known team on ads called GRM: Google Relationship Manager. Ads in 2010 was already mature as a product and revenue stream, and GRM was a tiny corner within that organization still, so I was able to absorb most of what Google had to offer without a ton of pressure to deliver.
Big tech companies are great for learning best practices. Most people, when they cite the reason why they join a giant tech company, cite the sheer scale of the biggest tech companies’ systems. Under-appreciated, however, is the opportunity to learn how great software is written—an aspect of software development that’s in some cases more applicable in future roles. Internally, Google has great tools, comprehensive tutorials on everything an engineer would need to learn, and generally good development practices. When other companies clamor for Googlers, not only are they leveraging the company’s famous interview filter; they expect to absorb some of its battle-tested best practices2.
Navigating a Corporation
It’s obvious, but worth stating, that companies value specific roles over others and you will be generally happier working for one that values your role. Google is an engineering-centric company; Apple elevates its designers; Microsoft promotes engineers into product management. Being near or at the top of the role hierarchy defaults to more influence and autonomy, and at Google that engineering-centrism played out exactly as you’d expect: engineers had a wide berth and allowance on what they got to work on, in some cases overriding the wishes of their managers and product counterparts. Sadly, I also see traces of this attitude in some of the startups I’ve interviewed at, presumably staffed with ex-Googlers or attempting to emulate that culture.
Like most corporate environments, projects deemed high priority by the executive team get this outsized halo effect. During my stint from 2010 to 2011, Google’s top priority was Emerald Sea, the internal build of what eventually became Google+. As you’d imagine, important projects were highly competitive and attracted those who were willing to sacrifice their livelihoods to accelerate their careers and paychecks; that said, most didn’t even bother trying3. This dynamic made me appreciate that the vast majority of a big company’s employee base is working on mundane tasks and are perfectly content with that arrangement. This informed my eventual observation that hiring only “A” players is not only prohibitively costly, but it actually makes it more difficult to get all the business-critical work—particularly the less interesting stuff—done.
Out of necessity, big companies end up standardizing many of their processes. Again, many of these have become second-hand public knowledge, but I saw how interview got structured, promotions were set up and granted, lateral transfers approved, and learned about some of the nuances of the infamous 20% time before it got killed. In the intervening years, I’ve reflected on the “why” behind each of those processes, and have tried to disclose those rationales to startups that have sought to emulate the “Google way”. Most of the time, just following the mechanics of a best practice end up producing underwhelming results; it’s better to evolve a process to fit the culture and people.
Part IV
The engineering-centrism eventually got to me; I lasted for a little over a year before looking for something where I felt like I could collaborate with PMs and designers as peers. I likely overcorrected in that regard by joining Square—a very design-focused startup—in 2011, to be detailed in the next post.
If I remember correctly, my other choices at the time were the Image Search group and Search Experiments.↩
Sometimes, though, there is an anti-pattern with Googlers where they’ve only worked with Google’s proprietary systems and have a rough time navigating more commercial/open source alternatives.↩
For instance, I heard that during that time, the Android team only entertained lateral engineering transfers above a certain level.↩
