Note: This post is result from my own experience but also borrowed from other articles where I learned some very valuable lessons. Some outstanding people I learned some of these lessons are: Lenny Rachitsky and Julia Evans

Note 2: I originally wrote this article in our internal company blog at New Relic, I adapted this to a more general audience and added some additional thoughts

A personal view on Promotions

Getting a promotion usually becomes harder as we move higher in the career ladder; as we grow our responsibilities grow as well, so it shouldn’t surprise anyone that the slope to the next level gets steeper.

At some point chasing a promotion and getting it is like going to a spinning class: we are not sure what to expect, although at first we are excited and ready to give it our all, but then we can end up feeling our whole body ache and wondering if it was worth it, while wondering why many people look so nonchalant while doing this every day. OK truth to be told, not all promotions are like that.

This article is a biased (as “from my experience, feel free to completely disagree”) take to help identify opportunities for engineers to continue on their path to continue growing in the advanced positions of the career ladder.

Why

It seems like culturally we are hardwired to consider success only the continuous growth and the non-stopping climbing across the job ladder, we don’t value much excelling in our current role as we value being promoted in the next level. Actually we don’t often see being acceptable staying put and doing a good job where we currently are, and we feel pushed to chase that next level.

I’ve been promoted before I was really ready (or even deserving, but that’s how I feel about every promotion and that’s another story) and it’s not pretty; it may have been one of the most emotionally exhausting periods of my career. The worst part is that most of the times we don’t know when we are ready, so we need to trust our manager and peers to help us there which, by the way, is one of the reasons why trusting people and building relationships is so important on our career, more on that later.

So probably the first question we should ask ourselves is “why do we want a promotion?”. If it is exclusively about monetary compensation (which I think it is a great reason by the way), a promotion may not be the only option available: Companies often have periodic compensation reviews within a broad salary window for each level and performance-based bonus as part of the recognition process. It may not be the large salary increase we are looking for, but often a promotion isn’t either and we should consider if we are ready for taking the associated increased responsibility. Not always is the best time to take more on our shoulders, because a promotion usually comes under a condition: we are expected to do more.

Regarding the reasons why people get promoted, let’s start with things that don’t get them promoted first (even though there is some common belief they do): We don’t get promotions for years of service or for just being really good at what we are expected to do.

If you think you deserve a promotion because your performance has been great, I found this quote from Tara Jaye Frank pretty spot on: “People don’t get promoted for doing their jobs really well. They get promoted by demonstrating their potential to do more”. Considering we are doing way better than most engineers at our level, doesn’t necessarily mean we are already at the next level; it means that we are really outstanding at our current one.

In other words, there is a difference between a great Staff Software Engineer and a Principal Software Engineer and it’s on the scope they are taking: A Principal Software Engineer that is underperforming doesn’t mean they are at a Staff level, and a Staff Software Engineer outperforming does not necessarily mean that they are at Principal level. It is not about performance (only) it is about scope and expectations.

How

As said before, the higher we are in the career ladder, the harder it looks to get a promotion. Many times people consider moving to an architect role or move out from their teams to have more chances to get a promotion. But as you may have guessed already I don’t think it’s about the team we belong to, it’s about showing we are ready to take over more. True, it happens that apparently some teams present better opportunities for that, but I’m going to try to challenge that opinion here.

So at this point I hope we agree that a promotion means that we are showing we are ready to take over more responsibilities, so how do we do that?

A larger impact

Actually companies always want to give more responsibilities to people who deliver results, we are often “rewarded” for our good work with more work, so if we aren’t getting the promotion we are looking for, there is a chance we are either not delivering the impact expected or that impact is not being visible enough. If you think your work impact is outstanding and it is not getting the recognition it deserves, a good option is to follow Julia Evans’ advice by writing and keeping track of a brag document. It is a great way to bring facts and make sure we remember where and how our work has impacted in a positive way the company’s business.

About increasing our impact further, I’ve seen many times people asking to change teams thinking the scope of their current team doesn’t provide them the opportunities to grow. The truth is that almost on every team there are opportunities to take over more and deliver with a larger business effect. Our impact can be both in execution and outside of it.

Impact on Execution and Delivery

On execution, here is an obvious statement: there is a difference between delivering what we are being told and excelling on what we deliver by going the extra mile. Think like you own the business, understand the value of your work for the company around efficiency, quality, customer impact, making our stakeholder’s life easier. If you are expected to deliver a feature, you can either just code it and ship it to production by strictly following the requirements or make sure it is cost-efficient, documented, provides the expected customer value, etc. If you are asked to replace a light bulb, be like Hal.

Impact beyond Execution

About impact outside the execution, it is in so many places within our teams: it is on prioritization, on raising up what is important, separating what is urgent from what isn’t and calling out what is meaningful for the business. The ownership of the roadmap is not exclusively of the managers, the engineers who have a better understanding of the technical challenges, the difficulty, the present blockers should always present an active voice when it comes to plan the work that is coming in, we are a team after all and we share the responsibility of the team’s success. If we don’t have an engineering roadmap, we are risking to build technical debt when focusing exclusively on shipping features, it is the responsibility of the engineers to call this out. This doesn’t mean the engineers are expected to do the work of the managers, this means that it is expected to support them and bring in any relevant input that may contribute to a better roadmap execution, the relationship between engineers and managers is one of partnership. Slightly related, this brings us to…

A wider scope

A great way to show we can take more responsibility is to actually take more responsibility. Proactively look for gaps in your team and your organization, here are some examples.

• Actively contribute to the team’s roadmap: Connect with product or with other teams your team has dependencies with and identify opportunities for collaboration, to improve communication, to develop something that can improve collaboration or speed up development.
• Advocate for your team: Help bring visibility of the team’s progress, lead internal and external demos, write articles explaining progress, write design and decision documents, reach out the people who have to be informed about that and open a discussion.
• Contribute with other teams: We have many dependencies and often we get blocked due to conflicting roadmaps across teams. A good way to unblock is to actually jump in and do the work even if it’s actually on the other team’s ownership. I know for sure that some teams would be thankful if someone jumps in and takes over part of their work and helps them to get it done. We have a chance to learn something new, create a collaboration relationship and we get unblocked. We have successfully collaborated with engineers from other teams on multiple occasions, and I have never seen any harm come from such collaborations. In fact, they have been beneficial.

The above is very difficult to achieve if we don’t develop some key skills, which I believe can be taught mainly through active and regular practice.

• Be a proactive communicator: Communicate regularly, share your work and ask for feedback, knowledge sharing works both ways. Look for partnerships, run away from dogma, question your beliefs and listen to new approaches, share and validate or break down your convictions with other people. We are incredibly lucky to work with a huge number of very talented and smart people, don’t waste this opportunity.
• Improve your writing skills: Be crisp (given the length of this article, don’t be like me), go straight to the point, keep in mind your audience and write for them, include the context that needs to be included, not everyone already knows the acronyms or the technical background and details of what you are writing about.
• Be professional: Listen to people in meetings, leave the camera on during video calls, let people see you are there for them, be on time and prepared. Be respectful when disagreeing, give space for others to talk, keep your cool when you see things you don’t like.
• Keep the pace: Avoid being blocked, avoid being overwhelmed. Easier said than done I know, but learn to prioritize and how, when and who to delegate. Find ways to escalate when blocked, be creative to get things moving forward.
• Have empathy: Developing empathy is crucial for building relationships and I have to tell you, no one will be ever successful alone.

Own your career

Finally and most importantly, largely a summary of all of the above: own your career. You of all people know best when you’re ready to take on more, and chasing a promotion when you’re not ready for more responsibility is the fastest way to burnout, so make sure you manage your growth pace properly.

And once you feel you are ready don’t wait for someone to tell you what you have to do next. Look for the next opportunity, see where you can be useful. For example if you are working on a new pipeline, a new framework, a new storage or whatever, make sure it has the support to continue to operate once you are done, is it you who is needed to follow up? If we are deprecating something, who will maintain whatever will replace it? Who will drive the deprecation? You know better than anyone what is the next step, where the engineering gaps are, you are the expert. Be proactive with your career.