Working at Google
Michael Lynch (via Stephanie Hurlburt, Hacker News):
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 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.
See also: The Econ 101 Management Method, Sins of Commissions.
