Why I Quit Google to Work for Myself

No, managers at Google can’t promote their direct reports. They don’t even get a vote.

Instead, promotion decisions come from small committees of upper-level software engineers and managers who have never heard of you until the day they decide on your promotion. You apply for promotion by assembling a “promo packet”: a collection of written recommendations from your teammates, design documents you’ve created, and mini-essays you write to explain why your work merits a promotion.

A promotion committee then reviews your packet with a handful of others, and they spend the day deciding who gets promoted and who doesn’t.

During my two-year honeymoon phase, this system sounded great to me. Of course my fate should be in the hands of a mysterious committee who’s never met me. They wouldn’t be tainted by any sort of favoritism or politics. They’d see past all that and recognize me for my high-quality code and shrewd engineering decisions.

promotion是一个稀缺资源，大公司里面就是僧多粥少的局面。即使每个人都做出“自己认为”很多的贡献，但是依然需要放在一个大池子里面进行评估，需要和其他人去竞争。

Before I put together my first promo packet, I never thought about the logistics of how it all worked.

In my head, the promotion committee was this omniscient and fair entity. If I spent each day choosing the right problems to solve, making the codebase better, and helping my team execute efficiently, the promotion committee would magically know this and reward me for it.

Unsurprisingly, it doesn’t work like that. It took me two years to figure that out.

The pipeline didn’t record many metrics. The ones it did have made it look like things had gotten worse. My bug discoveries caused the overall bug count to increase. The pipeline’s failures increased because I made it fail fast on anomalies instead of silently passing along bad data. I drastically reduced the time developers spent repairing those failures, but there were no metrics that tracked developer time.

My other work didn’t look so good on paper either. On several occasions, I put my projects on hold for weeks or even months at a time to help a teammate whose launch was at risk. It was the right decision for the team, but it looked unimpressive in a promo packet. To the promotion committee, my teammate’s project was the big, important work that demanded coordination from multiple developers. If they hornswoggled me into helping them, it’s evidence of their strong leadership qualities. I was just the mindless peon whose work was so irrelevant that it could be pre-empted at a moment’s notice.

I submitted my first promo packet, and the results were what I feared: the promotion committee said that I hadn’t proven I could handle technical complexity, and they couldn’t see the impact I had on Google.

The rejection was a difficult blow, but I wasn’t discouraged. I felt I was performing above my level, but the promotion committee couldn’t see it. That was solvable.

I decided that I had been too naïve in my first couple years. I didn’t do enough planning up front to make sure the work I was doing left a paper trail. Now that I understood how the process worked, I could keep doing the same good work, just with better record-keeping.

For example, my team was receiving tons of distracting email alerts due to false alarms. Old me would have just fixed these alerts. But now I knew that for this work to appear in my promo packet, I should first set up metrics so that we’d have historical records of alert frequency. At promotion time, I’d have an impressive-looking graph of the alerts trending downward.

Shortly after, I was assigned a project that seemed destined for promotion. It depended heavily on machine-learning, which was and still is the hot thing at Google. It would automate a task that hundreds of human operators were doing manually, so it had a clear, objective impact on Google. It also required me to lead a junior developer throughout the project, which generally won points with promotion committees.

My first denied promotion taught me the wrong lesson. I thought I could keep doing the same work but package it to look good for the promotion committee. I should have done the opposite: figure out what the promotion committee wants, and do that work exclusively.

I adopted a new strategy. Before starting any task, I asked myself whether it would help my case for promotion. If the answer was no, I didn’t do it.

My quality bar for code dropped from, “Will we be able to maintain this for the next 5 years?” to, “Can this last until I’m promoted?” I didn’t file or fix any bugs unless they risked my project’s launch. I wriggled out of all responsibilities for maintenance work. I stopped volunteering for campus recruiting events. I went from conducting one or two interviews per week to zero.

Priorities shifted. Management traded my project away to our sister team in India. In exchange, that team gave us one of their projects. It was an undocumented system, built on deprecated infrastructure, but it was nevertheless a critical component in production. I was assigned to untangle it from our sister team’s code and migrate it to a new framework, all while keeping it running in production and hitting its performance metrics.

As far as my promotion was concerned, this was a setback of several months. Because I hadn’t released anything for my canceled project, the two months I spent on it were worthless. It would take me weeks just to get up to speed on the system I was inheriting, and I was liable to lose several more in the gruntwork of keeping it operational.