| I'll play devils advocate because it's more fun but this: > 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 understand why the author might think this is better, but all software have bugs and a lot of data is tainted by those bugs. Was fixing the pipeline an actual priority? Was it critical? If so, how were the downstream internal customers dealing with the new exceptions? Why were they not raising a ruckus about it? Why was the author allowed to move on to a different project if there were so many bugs in that pipeline deserving of a promotion? I have met more people in life that made a big deal out of ultimately unimportant details than the opposite. Internal pipelines usually have a lower bar and the downstream consumer may not even care about 75% of features that are just there and unused. Being a senior engineering is also knowing when to leave good enough alone. > 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. Is that conclusion really wrong? It's a bit uncharitable for sure but that is indeed what happened not just how it appeared to have happened. If your project was such a low priority that dropping it for several months does not flash a red light in someone's dashboard, then I am sorry but that does not seem promotion worthy. The little comic also has good examples that things that imo are not "senior" work. Writing E2E tests for a product that is already shipped is worthwhile, but unless it's something very special it's not complex enough, does not require enough design to be considered "senior work". Again I don't know the guy, maybe he did get an unfair read on his body of work, but reading the entire blog I mostly get the vibes of "I worked 2 years at Google and then wanted to be a senior so I rushed my promo packet without a cornerstone project" and the committee refusing that is just the system working as intended. |
I largely agree with you.
I didn't mean to argue that the work I was doing for the first two years merited a promotion.
My point was more that I felt frustrated that I was doing what my manager and team asked of me, told consistently that I did the work well, and then later found out that it was all worthless for career advancement.
I think there are competing interests at a large organization that make this difficult. On the one hand, you have grungy work that needs to get done but only requires the skill of a junior developer (e.g., fixing bugs, writing tests). On the other hand, everyone at Google wants to advance their career by doing senior or above work, so how do you incentivize anyone to do the grungy work if it essentially means a career pause? I don't know how to solve that problem at scale.
I didn't and still don't harbor resentment toward Google or my managers for how promotions worked. I think it's difficult to align incentives for an organization with 100k people, and they chose a reasonable strategy. But I felt like the things I was good at didn't align well with career advancement at Google, so that was why I left.