Problems With Promotion-Oriented Cultures
Zach Lloyd (via Hacker News):
If you’re an engineer at Google or Facebook, you’re likely focused on one career question: when am I going to make it to the next level?
Getting to the next level unlocks a lot – more money, more responsibility, more respect, a feeling of progress – and even if you care deeply about other things (your product, your users, etc), you can’t really avoid caring about promotion as well.
[…]
The main problem with promotion-oriented culture is that it’s very hard to align promotion-criteria with business objectives, and so engineers end up doing a lot of work that doesn’t necessarily most benefit the product, users, or business – or even potentially their own growth.
[…]
Our [Google Sheets] engineers cared about the product and wanted to polish it. But they also wanted to be promoted. And so we would deprioritize product polish for projects that looked better to a promotion committee.
But the root cause isn’t that people want to get promoted. It’s that Google promotes people for the wrong reasons. Put very simply, the problem is that Google promotes people for “solving hard problems” not for solving USEFUL problems.
Imagine if people did get promoted for fixing bugs instead of building a new product (to be abandoned)! Or if maintaining an existing system was somehow on par with building a new system (which is just a bigger more complicated version of something perfectly good). The googler would say “well those useful problems are too easy to merit a promotion.
Previously:
Update (2022-05-19): See also: Hacker News.
4 Comments RSS · Twitter
"But the root cause isn’t that people want to get promoted. It’s that Google promotes people for the wrong reasons"
That's kind of a difficult distinction to make, though. Small corporations work based on trust, and an inherent understanding of what everybody else is doing. Once corporations reach a certain scale, you no longer know everybody, so trust tends to be replaced by systems. As soon as you have any kind of system, people have the ability to abuse that system.
You can't have "the right system." No right system exists. Every system has rules people must follow to be successful, and these rules never fully align with the goals of the company, so there is always incentive to prioritize individual success over company success.
One thing at Google is that it is incredibly difficult to get people to help you out with a problem, even if it is obviously beneficial to the company to collaborate on that problem. "Helping somebody else get their shit done" is not a valuable promotion criteria, so people tend to avoid doing it. But let's say you make it valuable. Now you've incentivized people to deprioritize their own work, which is also not what you want.
All of these trust replacement systems are inherently dysfunctional.
It seems to me that this problem is caused by confusion over the objective of cultivating your employee pool. Is the objective to get engineering done, or to create team leaders? Those aren't quite the same thing.
I work for a European-owned company, where engineers can become very senior and well-paid without becoming team leaders. There's a separate track for people who want to become team leaders and managers, and you can move between them. This means that senior engineers can be managed by people of lower grade who are paid less than them, but nobody has a problem with that.
Yes, I think David Graeber had something to say about that, didn't he?
Technical promotions are not a matter of "solving hard problems" vs. "solving useful problems". It needs to be both. Fixing a lot of simple bugs is great for customers, but it doesn't demonstrate preparation to be a tech lead of a team. Likewise, building some technical marvel when there was an off-the-shelf solution that would have delivered the needed functionality at a fraction of the cost is even more of a counter-indicator for promotion.
Being able to deliver valuable, high quality, solutions under complex constraints is the key. To evaluate that though, you can't just look at the system delivered, you also have to take into account the constraints, the quality, and the value to customers.