And yet in one short article the OP perfectly summed up who google sucks at making long term software that continues to work.
People often say that google rewards for new projects and ideas vs maintaining the old, I didn’t really understand what that meant until he explained it here. Doing good work is meaningless, the only that matters is what some faceless committee thinks.
What’s odd is that the committee doesn’t look at code quality, maintainability or longevity. They don’t care about documentation at all apparently because it’s not a quantifiable metric. And yet if you asked any engineer they would all say they’d rather work with documented code vs undocumented. It would ave them time and allow them to fix things faster.
The fact that google is trying to turn everyone into a quantified machine is making the whole org very sick.
The committees were changed a few years ago to no longer be "faceless" for most engineers. Now committees are made up of managers who work fairly near you in the org chart.
I work in an org that is explicitly tasked with a huge amount of maintenance and refactoring work. Our promo rates have historically been higher than other orgs. There is a very widespread belief that things like code quality don't matter at all for promos but it doesn't bear out in the numbers.
Does Google follow the practice of setting annual goals? At IBM where I worked for many years, we had to create something called a PBC (Personal Business Commitment). The idea was that you would be judged on how well you did with respect to those stated goals.
They do set annual goals starting at the team level and then moving up. But, as far as I have seen at the line manager and middle manager level, people are not judged directly on their progress on these goals. At higher levels this probably changes, but I don't really have a good sense of how directors and vps are evaluated.
There is indeed bias, but working at a company with a similar committee process, the committee process does indeed introduce its own series of biases and failure modes.
For example, depending on how the committee is chosen and the size of the company, you might still be known to the committee.
Popularity therefore still matters a great deal.
This isalso why my work inbox is chock full of weekly, biweekly, and monthly updates to products and features that are completely irrelevant to me, my team, or even my domain.
Complexity is hard to measure and somewhat subjective, but might be an important metric for promotion.
With potentially less specific domain knowledge available to the committee, something that seems easy might be extremely complex or vice versa.
Maybe you make something so easy and configuration driven engineers can delegate to non-engineers.
Now your job looks easy, but it took months of research to come up with a schema that can encode global tax rules (made up example) and only a few weeks to move hardcoded logic to the configuration and a couple days to build a UI on top.
Now engineers never touch tax rules ever again and deliver actual value in other domains. Your team remains small, possibly even shrinking as a result of your work.
But the Nth rewrite of $INTERNAL_LOGGING_FRAMEWORK has all kinds of sexy QPS, memory consumption, process time, etc. metrics to sell.
Right or wrong, I can say from experience the rewrite tends to get the promotion unless the tax guy writes a really compelling story in just the right way.
Humans are humans, be they managers or committee members.
People often say that google rewards for new projects and ideas vs maintaining the old, I didn’t really understand what that meant until he explained it here. Doing good work is meaningless, the only that matters is what some faceless committee thinks.
What’s odd is that the committee doesn’t look at code quality, maintainability or longevity. They don’t care about documentation at all apparently because it’s not a quantifiable metric. And yet if you asked any engineer they would all say they’d rather work with documented code vs undocumented. It would ave them time and allow them to fix things faster.
The fact that google is trying to turn everyone into a quantified machine is making the whole org very sick.