Six Things I Wish Someone Told Me About Getting a Promotion

[aum]

I was just newly promoted to Software Engineer II / Mid-Level Engineer at my company. This is a huge deal for me because I planned my whole life around the notion that internal promotions are impossible. I thought that the only way to get a promotion was to get a new title along with a new job.

 

Now that I know it's possible to get a promotion internally, here are some things I wish I knew when I was new to all of this. Last year, I wrote about 20 things I was working on getting from junior to mid. This is going to be an updated version of that with the wisdom of hindsight.

 

I'm going to skip some of the more obvious advice. You know how to get a promotion. Figure out what the company values, act on it, and demonstrate the impact of your actions to your manager.

 

In practice, it's a little more complicated than that.

 

1. You will never get a promotion or raise if there's no formal performance review process and career ladder.

 

If you're working at a company without formal, regular performance reviews, you are basically walking blind. You have no idea when other people's performance is being evaluated or awarded. The person next to you might have gotten 3 raises while you've been at the same salary since you started. Even if you are an intrepid type that will walk into your manager's office and ask for a raise, they may inadvertently put you through many more hoops than your peers.

 

As you would expect, this probably hurts folks from minoritized backgrounds more than their peers. We're less likely to be clued into this sort of secret knowledge, and people's personal biases come out a lot more when there is no transparent process in place.

 

In case you're like me and have never worked at a company with a performance review process before, here's generally how my company does it:

 

At the end of each year, we have to fill out a self-evaluation and give our peers feedback. This is all taken into account by our direct managers, who then write their own review and advocate for us. In these types of companies, it reflects well for managers to have engineers they manage level up. So, it's definitely in their interest to help you get to that next level as well.

 

After the managers submit a recommendation for a specific raise or promotion, it goes to their manager... their manager... their manager, all the way up to our CTO. (Mileage may vary here depending on the size of an org.) If a raise or promotion is approved, then it heads over to finance to budget it correctly, and then it comes back to us around 3 months after the process officially started.

 

We have a meeting with our manager that's similar to a 1-on-1 where we go over our performance for the year, goals for next year, and what actually changed in the compensation or title.

 

At my company, I generally expect to get a bonus, stock refresh, and a small raise (slightly above inflation/cost-of-living) every year. Again, your mileage may vary.

 

A manager also has a chance to submit someone for a promotion during the summer since a year is a long time. You'd have to plan this out with your manager in advance. Anything outside of summer and winter season is really rare and only a result of suddenly changed circumstances. No backdoor deals here.

 

If you want advice on a formal process like this, Gergely Orosz wrote a great post about how to write a self-evaluation recently -- from the perspective of an Engineering Manager at Uber.

 

2. You have to be performing at the next level for several months.

I've felt like a mid-level engineer for a long time. If I had to pinpoint exactly when, it was probably July 2020. It's February 2021 now.

 

Part of this is the delay from how long our performance review process is, but even then, that started in late November 2020. That's still 5 months where I felt like I was already a mid-level.

 

I think we tend to have this idea that, "If I'm doing well, I'll get promoted." I'm growing, I'm performing well, there's been no major issues with my performance, so clearly I can operate at the next level -- so give it to me!

 

The key word there is can. It doesn't really matter what you can do. All that matters is what you've done.

Generally, you'll be performing at the next level for a few months. Sometimes, this can be a year-long wait (especially if you're trying to get to a higher, more competitive level than mid).

 

There's a lot of potential for bias here. I've had (cis, white, male) friends tell me that they were basically promoted on potential and didn't have to actively go out of their way for several months to prove their performance. It'd be nice if that happened to the rest of us, but don't bet on it.

 

3. You can't skip two steps ahead into whatever skills you wish you could learn.

I've been trying to get to mid-level since the second I joined my company in September 2019. I was desperately trying to figure out any way to level up my skills. I read a bunch of books, I asked everyone I knew for advice, I overcommitted to so many things.

 

I had this idea that mid-level engineers knew system design and mastered 30 design patterns and made big architectural decisions. Now that I am a mid level... I'm actually not that different than I used to be. I still don't know how to design systems, I'm just a bit better at talking about it.

 

Technical skills aren't the only thing between you and the next level. In fact, they're probably not the main blocker between you and the next level.

 

Focus on a holistic approach to getting to the next level instead of the terrible lists of "things you need to know to be a senior developer" people write as if every company is the same. Your manager values certain things. If they don't tell you what that is, pound down every door in the company to find out. I recommend talking to other managers or folks who were recently promoted if your manager isn't helpful here.

 

For me, the difference between junior and mid was not reading Domain-Driven Design. It was becoming more comfortable talking to people & actively going out of my way to unblock the rest of the team. That's not really the sort of thing they teach you in books. It's just the kind of problem that shows up again and again, enough that you start to notice and act on it.

 

4. Embrace just-in-time learning.

This is a bit of a continuation of the last point. If you're not supposed to just read the lists of random recommended books, what should you do? You should spot patterns of things you don't know and work on them.

 

When I started at my company, I made this internal personal wiki for myself that had everything that I couldn't hold in my head. OKRs, business flows, technical gotchas. My seniors magically seemed able to recall all this stuff at will, and I was just treading water.

 

This was really good for me because it showed what I didn't know very clearly. Sometimes, that was stuff I could work on myself -- Node callbacks, react-redux, complex Cypress tests. But often, these were internal questions I had to ask -- how do I debug our GraphQL flow? How do we make good test plans? What's our A/B test process?

 

Personally, I really like work-life balance. I'm willing to spend a bit of time on the side reading programming books (Gergely Orosz recommends 2 books per year, I'm aiming for 3), but I'm not willing to sit down and learn Prolog just because it could, maybe, possibly help me learn code patterns.

 

Until I see a clear need to learn Prolog, I'm not going to do it.

 

5. Right place, right time makes a big difference.

There's so much that goes into who gets a promotion and when. For example, the layout of your team matters -- if there's multiple people vying for a senior position and you're the least experienced of the pack, you probably wont get it. But, this isn't a slight on you. If you looked outside of your company for the same position, no one would doubt that you are a qualified senior candidate.

 

For me personally, a bunch of doors opened up because of the changes the pandemic brought. The biggest change for me was that my team had a major re-org. Two teams combined into one to work on a bunch of brand new projects -- projects I happened to have a lot of familiarity with. Seemingly overnight, I went from being the least experienced member on the team to explaining how fundamental parts of our system to people who'd never worked in it before.

 

This quickly established me as a credible expert on the team and allowed me to demonstrate that I was performing above my level.

 

Fundamentally, all this comes down to is that so much of this is luck. If your luck is bad this round, you either need to wait for next time or look externally.

 

6. VISIBILITY.

If you can only remember one point on this list, let it be this one. This is the one that I really didn't understand until recently (specifically by reading Will Larson's StaffEng posts, even though I have no desire to be a staff engineer anytime soon).

 

The best way to be promoted is to have everyone at the company know and value your work so much that it's actually embarrassing that you're not at the next level yet.

 

Patrick McKenzie popularized the concept of working in a cost center vs. a profit center. I think the easiest way to be more visible is to work in a profit center.

 

You don't have to introduce yourself to every executive in the company, but being on a very visible team helps. Do the business folks know your team makes money? Does the VP of Eng know that your team builds some of the most useful products at your company? If your team is very visible and you're working on very visible products, all you have to do is demonstrate how you contributed to those projects in your self-review.

 

You know those emails that are sent out to either the whole company or your whole department about product launches and who was involved? If you can get your name included in one of those emails, you're suddenly very visible. Some exec who read that will come across your performance review, read your name, and realize -- Oh yeah, I remember that name! I received an email where huge kudos was given to this person.

 

Optimize for visibility. It is the most important marker for success.

...

That's it. There's loads of advice on this out there, so I tried to focus on the points that I don't see parroted around. If you think I missed anything or just want to tell me this helped you, leave a comment. If you have something more personal/private, you can still always email me.

 

Source