DEV Community 👩‍💻👨‍💻

DEV Community 👩‍💻👨‍💻 is a community of 964,423 amazing developers

We're a place where coders share, stay up-to-date and grow their careers.

Create account Log in
Cover image for On Promotions
Brandon Weaver
Brandon Weaver

Posted on

On Promotions

On Promotions

Ah yes, that time of year has come again, and with it come some of the most difficult discussions in your job role like "will I get promoted?"

No resource, article, or course is going to guarantee you a promotion and if they do they're selling you something. No no, you cannot guarantee one, but you can certainly improve your odds and set the stage in such a way that it tells your story effectively.

That's what this article intends to do, and to that note it will be a particularly long one as there's a lot of ground to cover on the subject. It will by no means be comprehensive, but it will give you a good foundation by which to start.

With that said, shall we get started?

Crucial Conversations

All promotions start with one fundamental thing: your manager.

They are your representative to promotion panels, committees, or whatever incarnation exists at your job. They tell your story, distill your work, and make a case for whether or not you should be considered for promotion.

Even before that moment though there are a lot of conversations to be had, and we miss so many of them in favor of assuming it's all work done for us.

Explicitly Start the Conversation

You would be surprised how many managers I talk to that say they're not considering someone for promotion. Not because they don't have the skills, no, but because they have not expressed a desire to be promoted.

Good managers will nudge this, yes, but it is always wise to have direct and explicit conversations with them about your career growth and what you can do to improve. That means explicitly and clearly saying you want to pursue promotion and the growth that entails.

The higher level you are the earlier you need to mention this. If you tell your manager a week before promotions are due that you want a Senior or above promotion, or even a mid-level, chances are real low that they respond positively.

Surprise Surprise

One of the key rules when dealing with leadership is this: Do not surprise them.

Be clear, explicit, and to the point. With promotions this means your desires should be clear, and your growth towards those desires should be recorded clearly as well.

The more you surprise your manager relative to the difficulty of a promotion the less likely they are to work with you on that.

Meeting Expectation

You can both start an explicit conversation and not surprise your lead, which are a solid start, but you also need to make sure that these conversations continue and that their outcomes are recorded.

Being calibrated with your manager on expectations, whether or not you're meeting them, and what you can do to improve are crucial conversations to have to drive you towards a level of execution where that promotion is doable.

This can take months to years depending on how high of a level you're aiming for. Tracking growth, expectations that you met, how you course-corrected, and whether or not your manager agrees you're on the right track are critically important to building a mutual understanding of where you're at.

Now not every manager is straightforward, so I very much like to have this in explicit writing for each session to make sure we don't backtrack, because it turns out as an IC I don't particularly like being surprised either.

Held Accountable

One of my largest frustrations with managers in the past has been a lack of critical feedback. Everyone has somewhere where they can grow, and managers should be actively watching for these areas in their teams. If not, you definitely need to prompt it and get them thinking in that direction.

No feedback is not good feedback, it means you have no chances to grow and learn from potential mistakes you cannot see. It also becomes much harder to trust your manager if all they tend to say to you are ambiguous niceties that don't really reflect your work.

Having those hard conversations earlier rather than later will save you a lot of unexpected thrashing in review rankings where you thought your manager was 100% ok with your work only to find out they were harboring more than a few annoyances they never owned up to.

Mentorship

Outside of managers you should also consider finding someone willing to mentor you that's in a position you'd like to be in one day. For me that might be a Head of Engineering / VP / Distinguished Engineer that's done some of what I've done, or is in a role I want to hit in the future.

It helps to have someone outside of your manager to help facilitate growth and have a more unbiased look at what you're doing.

These don't have to be coworkers either. Two of my mentors are at completely different companies, and they're folks I've built relationships with over years of conversations. On that note, it's also probably not effective to surprise someone with asking them to mentor you.

We can look more into this later, but see if your company has a mentor program. Many do.

Remember?

We must also acknowledge that leaders are human. That means they can forget, misremember, or otherwise not have a full grasp of what it is you're working on.

Quickly, tell me what you did precisely three months ago, down to the first Monday of the week. Now do that for five months ago, one year ago, last week. Hard, isn't it?

Now do that for five engineers on your team, and you can begin to see where this may become difficult for a manager, and lessen the likelihood that they can clearly bring together a case in your favor for promotions.

What do you do then?

Written Record

Unless you keep a clear record of what you've worked on it's hard to recall all that information, yet we expect our managers to have a photographic recollection of our work with which to present us in the best possible light.

By keeping a written record, even high-level and topical in nature, we can immediately recall the highlights from the assessment period and put together a compelling case far quicker than if you had to hunt this all down from scratch.

Chances are you'll probably forget a few projects too while you're at it.

For me that includes PRs, design documents, high level themes and targets, communications cross-linking, and a spider's web of information I can draw immediate insight from. Unsurprisingly this is also very helpful in your day-to-day work as chances are you won't remember it all then either.

Targets, Delivered

The higher level of a promotion you're after the more your work is on the delta of multiple months to potentially years. You can be very busy certainly, but unless you're delivering projects at that scope (which we will get into later) you're going to miss.

Keeping a high-level list of targets and how you're achieving them, especially in the context of your engineering levels, is crucial in framing conversations around your growth and assembling a story that speaks to those leveling criteria.

While engineering levels are not checklists, strictly speaking, enough managers and people on panels are going to view it as such that you need to treat that as table stakes for getting into the conversation. We can philosophize all we want on that point, but the fact of the matter is at several companies I've seen that exact same thing play out, and all it can take are a few folks doing that to sink a promotion.

Make sure you have a solid case for each level criteria, and keep building that case as you approach your promotion attempt.

For me I spent a full year before attempting a Staff level promotion gathering evidence and reinforcing my points. That brings us to another important section.

Engineering Levels

Many companies have them, and many still will insist that they're not explicitly checklists as much as guidelines. Be wary of this, as it's one thing to have a philosophical opinion on something and quite another to see how it plays out in actual promotion panels.

By the Books

Strictly speaking one of the clearest things you can do for levels is to hit all the marks on the engineering levels for your target level, and make a clear case as to why you meet all of those criteria.

One could fairly argue this defeats the purpose, certainly, but if promo panelists are reviewing 10+ packets chances are they're going to fall back hard on those explicit levels and nuance will not be as high of a consideration.

Do I agree with that? No. Is that the way things have played in my experience? Absolutely. Focus on solving for what reality is today, not for what we would like it to be tomorrow. We should certainly seek to change and improve, but while the criteria still favors an old way make sure you have those conditions met, and clearly so.

Over-Level Contributions

Speaking of philosophy I believe deeply that communication skills are critical to any engineer, and that glue work is an incredibly valuable skill to have. I also believe, perhaps contradictorily, that you should actively avoid getting to entangled in either until higher levels.

Many newer engineers working on promotions at or below senior levels can get caught in a trap of heavy community and extra-curricular involvement that detracts from their actual role. While these are certainly noble pursuits and have value you should make sure that it does not compromise your actual role.

This work is rarely recognized and rewarded until levels of Staff or above, and in a lot of cases can be framed as being "non-technical" and not pushing enough code. Again, I disagree with this, but many leveling systems are wired this way and we play to the game as it is written, not as we would like it to be.

Especially for levels of senior or below I would actively encourage heavier code contributions to make an abundantly clear case for technical merit.

I can certainly write more later on changing engineering levels and the process around that, but even then if you did change them it would take until the next promo cycle to really come into effect.

The Staff Curse

On that technical point, promotions aren't the only thing happening, reviews are too. That means even if you're on for promotion you'll likely still get a judgement at your level.

Many Staff+ roles heavily involve networking, communications, politics, and general socio-political skills. Those same skills would be seen as not pushing enough code in senior or below levels, which might land you in hot water.

Back to the point of not surprising managers you're going to want to be exceptionally clear in getting written expectations and feedback when going for these levels as the assessment criteria is dramatically different than the ones before it.

I have observed engineers trying for a Staff level getting put on a PIP (performance improvement plan) for "not doing their jobs" and pushing enough code, and so much of it was related to not setting clear expectations and progressions with their managers first.

The Staff Expectation

Conversely if you're clear on pursuing a Staff role and you try and solo everything and pursue those levels from a perspective of Senior, but more technical, you're going to have a very steep uphill climb in many companies.

Staff engineers are expected to abandon the notion of IC (individual contributor) in favor of OC (organizational contributor) or CC (company contributor) as they grow to Principal. This means that they're no longer one engineer, but the synthesis of an entire organization, a distillation of all that knowledge.

Anything beyond a certain scope is fundamentally impossible to do effectively if you try to do so by yourself. Certainly you can solve the technical part, but not the domain and all the concerns of an entire organization or beyond, and that's what gets folks into trouble.

It's also one of the most common reasons folks failed that promotion level at more than one company.

Writing the Packet

So you've had the talks, written down all the information, made sure to calibrate it all against your engineering levels, and now you have a decent amount of evidence. How do you take that and make a packet then?

To the Point

Remember that managers are human? ...and that they have five reports to watch? Panel reviewers for promotions are often not much better, if anything they're worse. They have a grand total of maybe a few weeks to review your entire record and make a yes-or-no call based on it, then they have to do that for probably ten more people each.

Knowing this, and knowing how burnt out those reviewers can get, one of the most effective things you can go while writing packets is to keep things to the point. Use bullet points, bolded titles to draw attention to sections, keep paragraphs short and terse, explicitly call out level criteria and how you meet it.

If I had two packets, one where the manager gave me a small-scale novel and another gave me a tightly bulleted summary with links to read more I know which one I would be far more likely to promote.

Really though this is a critical skill in general, especially for talking with executives, who need the TL;DR yesterday.

What did YOU Do?

At levels below staff you're very much judged on the work of your team and what your role was in that work. Above that point they want to know how you led and delivered on larger projects. What they have in common is people want to know what specifically you did, and if that information is hard to find it will not go over well.

When assessing a promotion reviewers want to know who you are and what you've done in no unclear terms. Don't try to ambiguously latch on to the work of another engineer to make your case, as it will be far weaker for it, as well as dishonest.

Framing

I'm going to give you two examples, let me know what you think of each of them:

Jill Smith worked on Feature Flags for the Java language, helped support engineers, and wrote documentation on how to use new features.

....versus:

Jill Smith is the product owner of Feature Flags for Java and expert in the domain. She designed and shipped cloud-native support including onboarding documentation and directly onboarded consumers, integrating feedback into further improvements.

Same engineer, same work, but one clearly tells you that Jill wasn't working on features, she was leading the entire thing from start to finish. The latter one is not an embellishment, but rather a reframing to tell the full story of the scope of work.

Scope and impact are frequently the most important criteria to meet in leveling expectations, so be sure that how you frame your projects takes this into account. I do not mean to say puff yourself up, no, but give yourself credit.

If you find that you're not good at selling yourself find someone who is and have them review your packet.

Collaborative Effort

Remember that bit about managers and helping them? Packets, especially post-senior, are collaborative in nature. You build them together, and help to make sure that the packet reflects your best self.

Some might think that this is entirely the job of your manager, but that would be a mistake as even with all the notes and other information they cannot know the full context of what you've worked on no matter how well they paid attention.

That's where you step in, to make sure that everything going to that committee is what you agree with, and that the both of you have an understanding of that.

Peer Feedback

Many companies include peer feedback, with some having stricter requirements on what constitutes applicable feedback. Over there for levels beyond senior you were required to have at least two people at or above the target level giving feedback on your packet to have it accepted, with some minor leeway.

Even if that's not a hard requirement checking in with your peers is valuable from time to time. Keep discussions in the open, because sometimes passive-aggressiveness can play in hard, and you want to keep the air clean especially on teams.

For me I want people who can speak to my strengths and who have directly worked with me, but perhaps oddly I also want people who will be critical of me in an honest and constructive way.

Critical Feedback and Evaluations

I'll also make sure said critical feedback is gathered well before promotion reviews so I can adjust on that and make a case that I did for amended feedback.

As a packet reviewer in the past nothing was more suspicious to me than someone who had no negative feedback. Everyone has something to grow on, so while you should absolutely frame things well you should not actively hide growth areas either.

And no, that does not mean you should sneak in try-hard evaluations like "They care too much for their own good" unless you have something to follow that that makes a real clear case for it. In my case I made that argument because it got me involved in too many different initiatives which prevented me from focusing on the ones which mattered, which was definitely a weakness to address.

Additional Considerations

Beyond these things there are a few additional considerations that don't strictly fit into sections, as much as they are anecdotes I've heard over my career that have really helped frame things for me.

Presence

For levels beyond senior you have substantial visibility, and have to network across entire organizations if not higher. That means people have to trust you, and in some ways already see you at that level.

If I were to go to anyone in your org and ask who you are and get blank stares and shrugs chances are there's a problem and people don't know what you do. For those levels that's a huge miss, as your entire effectiveness is based on how well you communicate and negotiate with folks.

That doesn't mean to strut about and peacock, but to be sure to form relationships with those you're going to be working with as those will be essential to any high level project's execution.

Try Anyways

Not sure if you're 100% ready? Try anyways. Often times this will result in useful feedback on what the panelists would like to see next round, and can help bolster your case. You might be surprised, you might be far further along than you think you are and get the promotion anyways.

That happened to me once where I thought it was a long shot, but the feedback was that I had well exceeded the requirements and should have considered applying earlier. Lessons for future me I suppose.

Feedback

If you have a mentor or others you respect absolutely get their feedback on your packet, it can really help as often times they'll also be excellent cheerleaders to help frame your packet in a way which really captures your impact.

That said, if I were on promo panels and you asked me to look at your packet, I would recuse myself if you ended up in my group to prevent bias so do be aware that recusal is a risk you run sometimes.

Upward Feedback

Especially post-senior levels you're going to want to ask higher level EMs what their view of you is, and what if anything they would suggest you do to grow and improve. As your scope increases you will be dealing with these folks a lot more, so getting their opinions will be invaluable.

Wrapping Up

This is by no means a comprehensive list, but summarizes most of the advice that I have given folks over the past decade regarding promotions. So far that advice has helped to promote over 35 people now, with some all the way up to Staff levels, but that contains another secret:

They were already incredible engineers with stories to tell, I just helped them tell them effectively and clearly.

That's the other secret though dear reader: You're a pretty great engineer too, don't sell yourself short. Give it a try, start the conversations, and see what happens.

I believe in you, so go out and give it your best.

Top comments (0)

🌚 Friends don't let friends browse without dark mode.

Sorry, it's true.