Confession of an Engineering Manager on Promotions

I’ve often seen or heard that one of the key indicators of a good manager is the ability to promote someone. On the surface, it seems agreeable enough. After all, what does a manager do, if they cannot promote their people?

On a deeper level, I find the statement misleading.

I have heard of and have said it myself, regrettably, that as an engineering manager, going into a promotion calibration meeting is like going to an at-bat on behalf of a candidate, like a designated hitter in baseball. The candidate is a strike pitch, and the manager’s job as a DH is to hit the four-seam fastball out of the park.

The characterization is wrong.

Consider just two variables among others: bull market vs bear market, big company vs small company.

Market Condition

First, when times are good, companies are fueled by liquidity with low interest rates and managers have one mandate — grow at all costs. In that environment, an organization needs to expand horizontally as well as vertically, hence promoting folks quickly is both a function of necessity and a way of attracting new hires.

At a tougher time, however, promotions are often delayed or put under much more scrutiny. Big tech typically has at least a 15% replacement target, consisting of both firings (unregretted) and attritions (regretted). When the market is hot, voluntary attrition is usually at least 10%, so firing is kept low. Conversely, when the market is cold, attrition drops and companies are eager to increase firing and keep staff at levels longer.

Capital Expenditure

Second, smaller companies and companies with less capital to spend on talent, often resort to job title inflation or a faster promotion track. In my experience, I’ve seen companies promote based just on non-written impressions and a reversed stack ranking of who they fear to lose the most. It could be said that they “promote as a reward for performance”.

In contrast, bigger companies and especially Big Tech often do the opposite — they keep staff at their levels until they’ve proven to be at the next level across all areas. Looking at it cynically, that means unless someone is ready beyond any shadow of a doubt they are barred from a promotion. Also, the senior engineer position is typically a terminal level in those firms, so the escape velocity to go up to the next level thereon is much higher than elsewhere.

In the most egregious circumstances — a smaller company in a hot market, promotion is largely a function of how good a manager is at verbally promoting their staff. The aforementioned analogy of a Designated Hitter is uncanny. The outcome is often miscalibrated and unfair. Folks whose manager has a tongue of gold get promoted at the expense of others.

Promotion should be a standardized and transparent process of data comparison and with enough clarity, should be largely self-evident. A manager’s job should be to judiciously record and showcase the data, quantitively and qualitatively, and have a deep understanding of a staff’s contribution and impact. Below is a list of examples:

Samples of Quantitative Data

1. Coding: diff* count, average revisions per diff, code review count
2. Documentation: design doc (RFC**) count

*diff is a unit of code change merged into the main codebase, also known as merge request, etc.

**Request For Comment; a standardized document for designs and reviews

Samples of Qualitative Data

1. Coding: design patterns, code coverage
2. Design: robustness of design, responses to comments
3. Operations: incident management, on-call rotation

Below are three key recommendations for securing a promotion, barring the aforementioned abnormal situations:

1. Excel at the current level, then "punch up"
2. Collaborate with your future promo endorsers
3. Know thy competitors

Excel at the current level, then “punch up”

Some folks make the mistake of attempting the level+1 performance metrics before excelling those at the current level. For instance, the metric for intermediate-level staff is typically a high coding throughput (even higher than the senior staff). It would be a mistake to attempt to lead projects without ever exhibiting the ability to code well and fast. After all, with limited time it’s extremely hard to optimize both. Herein, the manager’s job is to allocate staff correctly to not stifle their promotion paths.

Collaborate with your future promo endorsers

Promos need endorsers outside of the immediate team, so the only way to reliably get an endorsement is to find opportunities in cross-functional projects whereby one could collaborate with level + 2/3/4 staff*. And the only way to get it is to do a superb job and be recognized as such. Suffice it to say, without collaborations with external senior staff on cross-functional projects it’s virtually impossible to get promoted.

The process is both push and pull: a manager needs to put “promo-ready” staff on visible projects and the staff needs to actively solicit for such projects too.

*if the current level is intermediate then L+2 would be staff engineeer, L+3 would be senior staff engineer, etc

Know thy competitors

Don’t believe anyone who tells you otherwise, at every promo cycle, there’s a budget for promotion and on the flip side for performance improvement plan (PIP). That means management stack ranks the staff and identifies the top and bottom performers. That’s typically the top 15% and bottom 15%.

The manager and the aspiring staff should do enough intelligence work in terms of who’s the top of the crop and periodically monitor their quantity and quality metrics. Pay attention to where the bar is and aim to be in the same league. If the manager has proactively identified them and the staff knows whether there’s a gap, there should be no surprises if a promo case doesn’t pan out.

Metrics are a proxy for performance and not in and of itself and hence could be gamed. As a manager, rather than sales pitching their staff and sabotaging the others, as often praised as a good manager’s quality, it is more fruitful to present comprehensive and truthful data while keeping the other managers honest:

Is a candidate’s coding throughput abnormally high? Are configuration changes counted toward it? Is a candidate listed as an author of a design doc but the actual input is lower than the other coauthors? Is management discerning the coding throughput in a platform team vs a product team? Is a candidate “punching up” without excelling at the current level?

My final confession: In Big Tech, with a few exceptions (e.g. Meta), getting promoted to a senior level is an arduous task, and often harder than, dare I say, getting a new job at level+1 outside of Big Tech. In my observation, even the most robust 5-hour interview loop has many blind spots one gets less scrutiny than in a typical promo calibration committee. The odds are in an aspiring candidate’s favor to just find a new job (with enough tries).