Promotion-Driven Development

Silicon Valley Anti-patterns, Part 1

When it comes to anti-patterns that I commonly see across many Silicon Valley companies, nothing is as prevalent and as broken as Promotion-Driven Development: a style of programming in which software engineer ignores what is good for business in favor of what looks good on their next promotion packet.

I believe that Promotion-Driven Development is a lot more common that most will admit, because it is a natural side effect of a typical Silicon Valley engineering performance management culture.

Status Quo

Performance management in Silicon Valley is surprisingly similar across all the companies, big or small. There are levels. There are career matrices (a.k.a ladders, pathways, skill matrices, expectations, etc) that describe those levels. There are ratings against expectations in those matrices, some positive some negative. There are rituals: feedback, packets, calibrations, and appeals. There are committees that produce ratings against level and move people up level. There are algorithms that take all of the above and give raises.

Some details vary from company to company, but, ultimately, it is so standardized, that there is even a well known mapping of levels from one company to another that is widely accepted by all recruiters, hiring managers, and HR.

So what is wrong with it?

The good news is that not everything is! For example, the process works well for junior engineers: it gives a solid frameworks for growth for those who recently entered professional workforce. However, once an engineer eyes the promotion to a “super-senior” level (Staff, Principle, L6+, etc.) this process not only falls apart, but also actively hurts both engineers and the company they work for.

So, in no particular order …

Incentives are not aligned

Leveling up is the primary way how software engineer can grow their compensation: sometimes total compensation grows exponentially with each new level, while at best you can expect logarithmic growth if you stay in your level. So it is reasonable to assume that every engineer will eventually put their earnest effort to get promoted. This means that an engineer will gravitate towards the project that check the boxes on career matrix, whether those projects are good for company or not.

And here is the rub: what is good for promotion is very often not aligned with what is good for a company. In practice, this leads to over-engineering, re-building from scratch rather than iterating, building in-house rather than buying from third party, and over-staffing rather than running lean.

Strong performance != professional growth

The sad truth is that there is not always room for professional growth in a company, especially at senior levels. Every company will benefit if junior engineers will become slightly less junior over time. However, not every company benefits when their senior engineers become super-senior: there are only so many “large scale initiatives that span across business units” that a company needs. Yet, someone always need to fix routine bugs and build routine features. And doing so is not good enough to meet expectation of Staff engineer, let alone justify being promoted into one.

In the ideal world, good performance and professional growth would come hand in hand. But in the real world, they do not. I often see engineers, who do what is right for the company, that do not get rewarded. While others, who chose to ignore company needs in favor of their own career growth, tend to get the undue rewards and recognition (often in a form of promotion).

Happy times asset, sad times liability

Career matrices are usually created in happy times. The company is growing, old products get scale, new products get launched, and we need to make our team better and bigger to support that growth. In those times professional growth is always a good thing: there is never enough senior engineers to build everything we need, and we constantly hire more and more junior folks to backfill all the promotions and keep well balanced teams. In those times we build the processes that will “serve” us in the future.

But good times inevitably end: growth slows down, hiring is followed by layoffs, products get cancelled, Wall Street expectations change, and so on. Yet career matrices stay, and they continue rewarding happy time behavior. “Leading a team introducing large scale architectural change” may have been very valuable in happy times, when we were growing and old architecture was barely holding up. But now, when we are focusing on optimizing for profitability, a series of small tweaks and performance optimizations may be what company needs instead.

If company gets back on growth track shortly, the damage inflicted by a happy time career matrix will quickly be mitigated. But what if sad times last a little longer, like a year or two?

One way street

Once promoted, hardly anyone ever gets demoted or fired. Even if it happens, it usually takes years: the reputation that led to a promotion protects an engineer long after that promotion is in the books. This already creates a bad dynamics, where it is so much harder to get promoted to a level than to stay at that level. But that is not the end of it …

Often the criteria for promotion is “sustained performance at next level”. While it sounds reasonable at first, one can quickly see that it is not entirely fair due to information asymmetry. For example, it may be harder to learn about impactful problems to solve without already reaching a certain organizational level: levels and titles open doors (e.g. access to executive, being invited in design reviews, face time with business leaders, etc). So, as a results it is again, so much harder to get promoted to a level than to stay at that level.

Promotion becomes sort of hazing. In the worst organizations, engineers look at it as short term sacrifice: one has to suffer for a limited time in order to get a raise and rest and vest for years to come. Way too often, promotions are one hit wonders: engineers who manage to pull off one impactful thing for a company, and never ever do anything of that magnitude again.

Short tenure

Once promoted, the software engineer will eventually quit. And judging by the average tenure of software engineer in Silicon Valley company it will happen soon. I would guess that even at senior levels, it is not likely to be longer than 2 years after last promotion.

But that over-engineered piece of software, that looked oh-so-good on staff level promotion packet a year ago, stays. And it still needs to be iterated upon. And that is when we suddenly find out, that it needs 3–4 engineers to maintain, that the “creative solution” that was praised in promo committee looks remarkably like duct tape, that we have no one that is familiar with the “pioneered new technologies”, and that “excellent documentation” actually made sense only to its author.

We start getting this gut feeling that maybe that promotion was not deserved after all, but not much can be done now. So we hire another senior engineer, who makes a case to rewrite it from scratch: an easy case given all of the above. They earn another promotion, quit a year later, and take the vicious cycle to the next iteration.

How can we make it better?

The good news is that we do not need to destroy the existing process and rebuild it from scratch, that would be the exact kind of over-engineering that I advocate against. We need to do a series of small tweaks, that will have a great impact.

So, without further ado, here are some ideas …

Decouple compensation and promotions

… and, at the same time, couple compensation with doing what is right for the company. Doing what is right, even when that is below the level skillset, should never be bad for you. This will help in two ways: it will remove monetary incentive to solve hard problems that need no solving, and will add monetary incentive to solve easy problems with huge impact.

One step towards it is to bring back bonuses — real, sizable bonuses that are tied to to performance. Doing the right thing for a company, should lead to a very positive performance rating, and should in turn lead to a compensation (for this review period only, not indefinitely) that may be a lot higher than compensation of the next career level. This performance based bonus should become a real alternative to constant promo rush. I am certain that in company that works this way, we would have a lot fewer promotion nominations, and a lot more value built every day.

Of course, bonuses alone won’t solve the coupling completely. We need to try out other ways, and figure out what works.

Be honest about professional growth

Telling your super-star that they have reached ceiling in your company or department is hard, but I would argue it is necessary. Being honest that there are no growth opportunities, at least today, will help aligning those incentives. That employee will have a choice: either wait for the right opportunity while doing what is right for the company, or move on to a different department or company and free up space for someone who will. And if we have decoupled compensation and promotions as suggested above, learning that there is no growth opportunities right now may not be that bad of a news: it may be a clarity that employee needs to make the right choices day to day.

I would also consider letting someone, who grew too much on the job, go from the team. Of course, it should be done respectfully, with proper support needed to land the next job in a place that can provide the growth they seek. And goes without saying that ideally, if possible, we would find another team in same company that needs someone that senior, before pushing the engineer outside. Helping someone realize that their next career growth needs to happen elsewhere, and helping them find this opportunity, may be more beneficial for the company than trying to keep them by inventing work that does not need to be done.

After all, it is common to not hire someone because they are overqualified for the role. So why is it less common to let go someone who became overqualified in their current role?

Decouple performance and promotions

We need to make it culturally okay for senior levels to not grow in levels. Typical company makes promotions visible and celebrated, but keeps performance ratings private. As a result, people with super-senior levels get more respect from the peers. Instead we need to change cultural perception of super-senior levels: it is a different job type that one may or may not chose to do. At the same time, we should find a way to celebrate people doing amazing things quarter after quarter at their level. It should become a norm that senior engineers exceed expectations year after year, and never go for a promotion. Those are the most valuable people in the company, and should be respected as such.

Make super-senior promotions a two way street

Perhaps it is time to rethink a super-senior level promotions at all. Often, managers talk about staff+ engineer level as a different role: you often spend less time coding, and more aligning the teams, evangelizing the tech, building tech community, or coaching on a specific technology you are an expert in. Should we make it possible to shift into and out of that role easier, rather than consider that one-way door?

Just like one can become a manager and come back to individual contributor, one should be able to become staff engineer leading large initiative and come back to senior engineer coding for a different project when company needs or personal goals change.

Career matrix is not a dogma

Finally, I would argue that we should give managers or directors some amount of discretion on how to apply the career matrix in their org. We hold managers accountable for delivery of their teams, and we should give them some latitude to shape the team as they need. Of course, there is a possibility of bias here, that one needs to carefuly watch for.

Where do we go from here?

Change is hard. It means going against conventional wisdom of top Silicon Valley companies. It means that your levels won’t easily match industry levels. It means your company will have to educate candidates about how compensation stacks up against competition. It means you may loose some good people while you flush the new process out. It means you can fail at the end.

But I strongly believe that all of that is better than long term cultural, technical, and financial damage that Promotion-Driven Development inflicts on your company. We can build leaner and higher performing teams, and we can significantly reduce technical and organization complexities, if we find an effective way to squash the Promotion-Driven Development anti-pattern.

Do you have other ways to fight Promotion-Driven Development? Did you company successfully avoided Promotion-Driven culture? If so, I would love to hear from you!