The Problem With Promotion-Obsessed Cultures

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.‍ This post talks a bit about the (well-known) issues with this type of culture, and suggests some alternatives for startups not looking to replicate it.

‍The problems with promo-culture

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. ‍ For instance, when I was leading Google Sheets, we had a lot of small bugs and usability issues, often in areas where we weren’t at parity with Excel. Users wanted us to implement disjoint selections, fix our charting UI, add the ability to insert and delete ranges of cells – pretty standard spreadsheet fare, and very reasonable requests. ‍ However it was a constant struggle to prioritize these types of issues vs. “bigger impact” projects. Our 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.

‍In addition to it being hard to prioritize polish, promo-cultures tend to create other inefficiencies:

• A surplus of “leads” on a project (being a “lead” allows engineers to check the leadership box for getting to the next level)
• Post-hoc design documents written specifically to explain work to a promo-committee after the feature has been built
• Promo-time “tech-talks” and brown-bags of dubious value from engineers trying to demonstrate community contributions ‍

Finally, there is the dreaded “perf-season” where engineers and managers waste a tremendous amount of time prepping promo-packets to make their cases for moving up the ladder.

To sum up the problems…

• From a business perspective, promotion-driven cultures decrease productivity and increase cost per engineer.
• From a product perspective, managers create new, confusing, internally competing products while existing products languish or are sunset, because one of the best ways to get promoted is to launch something new.
• From a cultural perspective, for engineers who really care about the products they are building, promo-culture creates a demoralizing situation, sometimes forcing engineers to choose between doing what’s best for users or what’s best for their career.

Alternatives to promo-cultures

‍In theory startups should be the foil to promotion driven cultures – most startup employees understand that getting promoted is a second-order concern relative to the risks of the startup not succeeding.

Conversely, folks understand that if they are early at a successful startup, they will be successful too – they will all do really well from a comp perspective, have seniority by default as the company grows, and get to take pride in building something from nothing. Incentives are naturally aligned.

However, anyone who has spent their careers in startups knows that this isn't always true, and that startups that are successful tend to drift towards a promo-culture. As startups grow, early-stage risks and benefits decline, and so incentives become less aligned.

Some things I've been thinking about that might help avoid promotion culture:

• For as long as possible, make the success of the company the primary motivator, rather than promo
• Try to hire engineers who are fatigued by the promo process at bigger companies and don’t want to replicate it
• For any formal promo process, put real limits on the amount of time that goes into it while keeping it fair
• Build into core values wanting to create a culture where the end-user is the priority, not individual advancement up the ladder
• Make the ladder heavily focused on user-impact as the main criteria for advancement
• Be constantly on the lookout for promo red-flags like post-hoc design docs, internally competing projects, and “promo-seasons” ‍

If you have other ideas on how to avoid the slip into promo-culture, I’d love to hear your thoughts.

Also Published