Why I Quit Google to Work for Myself ·<br>mtlynch.ioFor the past four years, I’ve worked as a software developer at Google. On February 1st, I quit. It was because they refused to buy me a Christmas present.<br>Well, I guess it’s a little more complicated than that.<br>The first two years 🔗︎<br>Two years in, I loved Google.<br>When the annual employee survey asked me whether I expected to be at Google in five years, it was a no-brainer.<br>Of course I’d still be at Google in five years. I was surrounded by the best engineers in the world, using the most advanced development tools in the world, and eating the free-est food in the world.
My most recent performance rating was “Strongly Exceeds Expectations.” If I just kept going, I’d soon be promoted to the next level, Senior Software Engineer. What a great title! Forever after in my career, I’d be able to say, “Yes, I was a Senior Software Engineer. At Google.” People would be so impressed.<br>My manager assured me that my promotion was close. He felt that I was already capable of senior-level work. I just needed the right project to prove it to the promotion committee.<br>Your manager doesn’t promote you? 🔗︎<br>No, managers at Google can’t promote their direct reports. They don’t even get a vote.<br>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.<br>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.<br>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.<br>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.<br>That’s not really how it works 🔗︎<br>Before I put together my first promo packet, I never thought about the logistics of how it all worked.<br>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.<br>Unsurprisingly, it doesn’t work like that. It took me two years to figure that out.<br>Working naïvely 🔗︎<br>My main responsibility until that point was a legacy data pipeline. It had been in maintenance mode for years, but load had increased, and the pipeline was buckling under the pressure. It frequently died silently or produced incorrect output. Its failures took days to diagnose because nobody had written documentation for it since its original design spec.<br>I proudly and lovingly nursed the pipeline back to health. I fixed dozens of bugs and wrote automated tests to make sure they wouldn’t reappear. I deleted thousands of lines of code that were either dead or could be replaced by modern libraries. I documented the pipeline as I learned it so that the institutional knowledge was available to my teammates instead of siloed in my head.<br>The problem, as I discovered at promotion time, was that none of this was quantifiable. I couldn’t prove that anything I did had a positive impact on Google.<br>Metrics or it didn’t happen 🔗︎<br>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.<br>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.<br>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.
Learning from rejection 🔗︎<br>The...