![]() It was the right decision for the team, but it looked unimpressive in a promo packet. 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. My other work didn’t look so good on paper either. I drastically reduced the time developers spent repairing those failures, but there were no metrics that tracked developer time. The pipeline’s failures increased because I made it fail fast on anomalies instead of silently passing along bad data. My bug discoveries caused the overall bug count to increase. The ones it did have made it look like things had gotten worse. I couldn’t prove that anything I did had a positive impact on Google. The problem, as I discovered at promotion time, was that none of this was quantifiable. I documented the pipeline as I learned it so that the institutional knowledge was available to my teammates instead of siloed in my head. ![]() I deleted thousands of lines of code that were either dead or could be replaced by modern libraries. I fixed dozens of bugs and wrote automated tests to make sure they wouldn’t reappear. I proudly and lovingly nursed the pipeline back to health. Its failures took days to diagnose because nobody had written documentation for it since its original design spec. It frequently died silently or produced incorrect output. It had been in maintenance mode for years, but load had increased, and the pipeline was buckling under the pressure. My main responsibility until that point was a legacy data pipeline. Unsurprisingly, it doesn’t work like that. 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. In my head, the promotion committee was this omniscient and fair entity. That’s not really how it works □︎īefore I put together my first promo packet, I never thought about the logistics of how it all worked. They’d see past all that and recognize me for my high-quality code and shrewd engineering decisions. They wouldn’t be tainted by any sort of favoritism or politics. Of course my fate should be in the hands of a mysterious committee who’s never met me. 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.Ī promotion committee then reviews your packet with a handful of others, and they spend the day deciding who gets promoted and who doesn’t.ĭuring my two-year honeymoon phase, this system sounded great to me. 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. No, managers at Google can’t promote their direct reports. I just needed the right project to prove it to the promotion committee. ![]() He felt that I was already capable of senior-level work. My manager assured me that my promotion was close. At Google.” People would be so impressed. What a great title! Forever after in my career, I’d be able to say, “Yes, I was a Senior Software Engineer. 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.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |