Most (tech) companies I know expect the promotion process to be mostly driven by the candidate. Even where this is absolutely true, I think that Engineering Managers play a crucial role in supporting their candidates throughout the process.
Candidates that don’t receive enough support from their managers usually have a steeper hill to climb. Below are just some of my learnings helping engineers succeed in that journey. It mainly reflects my experiences as an Engineering Manager at Spotify.
Carve out the time and do the work
This is a critical process for the individuals you manage and usually they are very invested in making that happen. However, this is a process that requires a big amount of effort, not only from the individual seeking the promotion but also from you as his or her manager. It takes time and effort to put together a promo packet, which usually involves a lot of writing and reviewing from both parties. The first lesson to be learnt, therefore, is that you should allow enough time to handle that. You should clearly communicate and agree with your report on a timeline to hit specific milestones for that process.
Once you have that timeline in place, you should treat that as a commitment and really deliver on your end of the bargain as agreed. Failing to do that can significantly erode the trust between you and them. It also considerably increases the amount of stress your report will experience because it usually means less time to review and fix issues with the packet.
A timeline I usually adopt with my reports is as follows:
-
8-10 weeks before the deadline: manager and report start working on their respective parts of the promotion material.
-
4 weeks before the deadline: (i) a first draft of all relevant documents is ready for review; (ii) full review started.
-
3 weeks before the deadline: (i) both manager and report have fully reviewed all artefacts; (ii) packet is shared with other managers and/or relevant engineers for extra review round.
-
1 week before the deadline: all relevant suggestions have been incorporated into the documents.
-
2-3 days before the deadline: final read to spot grammar/typos issues in the text.
-
Deadline day (or before): submit all the relevant material to the committee or person responsible for collecting this. Try to get confirmation that everything has been received properly.
Obviously, the timeline outlined above is just a rough approximation and may vary depending on the complexity and novelty of your case. A junior engineer promotion process will most likely require less preparation time than a staff engineer one. Likewise, if this is your first time sponsoring a candidate for a specific role, this also might involve more time than the preparation needed to sponsor a candidate for a role you have done many times. Sponsoring multiple candidates from your team in the same cycle will also demand more from you, and, therefore, you should reflect that in the timelines you agree to.
You should be realistic when devising that timeline. Don’t forget to consider holidays, time-off periods, and company off-sites when planning that work. Again, allowing enough time to work with that packet (or packets) will translate into stronger applications and a less stressful journey for everyone.
Also, don’t underestimate the amount of effort to review all the material. Developers are not well-known for being great writers of prose text. There are more insights about this, but I’ll leave it to another post.
As mentioned before, try really hard to keep your promises. If you say you will review something by the end of the week, review it. For me, the key here is to stay organised. Getting organised will not only help you with your promises but also help you prevent overpromising.
Elements of a successful promotion packet
It’s very important to thoroughly review all the artefacts needed for a promotion. When doing so, you are not only looking for errors in your writing, like typos and similar grammatical mistakes, but most importantly, you want to make sure that all the elements for a successful application are there. These elements may vary slightly from company to company, and, for most of them, the baseline will be different depending on the level someone is applying for. Still, usually, they revolve around the following aspects: consistency, business impact, technical complexity, and leadership. Although insufficient, I believe these are necessary conditions for a successful promotion application.
Consistency
In 1969, Laurence Peter and Raymund Hull published a book titled The Peter Principle. In that book, they popularised the idea that in many organisations, people tend to rise to their level of incompetence. In other words, employees get promoted based on their success in previous roles and levels until they reach a point at which they are no longer competent. Even though the book was intended to be a satire, it widely resonated with the corporate world nevertheless. Some companies today, especially tech companies, have set up their promotion processes in order to mitigate that problem. That means that in order to be promoted to a certain level, you probably already need to be operating at that level consistently to some extent.
So, for example, if someone is trying to get promoted to a staff engineer level at Spotify, they need to consistently demonstrate the ability to deliver high-impact projects at a level that is usually wider than a single team. They need to showcase that they have the skills and drive to impact multiple teams, usually under the same org. The stronger the evidence in their promotion packet that this is the case, the higher the chances of promotion success. As a manager, therefore, you must be able to ensure that this consistency is there before you submit the packet to the promotion committee.
Ideally, before agreeing to sponsor someone’s promotion, you should already have enough confidence that the consistency is there. Sometimes, however, after writing the packet up and reviewing it, you might end up in a situation where you realise the consistency is not there. This usually means one of two things: the person has done the work but failed to articulate it well in the promotion packet, or you mistakenly assessed that the person was ready.
If it’s the former, work alongside them to make sure that enough examples and situations have been described to convince the committee that consistency is there. From my experience working with promotion committees, the higher the level, the longer the committee wants to see evidence for. That means that, on average, to go from an Engineer I to an Engineer II it will take less time than to go from an Engineer II to a Senior Engineer position, for example.
On the other hand, if you realise that actually there’s not enough evidence to support that promotion, you should be very straightforward with your report and seek their understanding that it would probably be best to postpone it until the consistency is there. Obviously, as a manager, you should use this as an opportunity to devise (or update) a development plan that will help this engineer to overcome these gaps. In many cases, this translates to finding the right opportunities to enable them to demonstrate their ability to operate at the desired level.
Business Impact
Rich Hickey, the father of the Closure programming language, once said that we, software engineers, are in the business of solving problems, not in the business of shipping features. I totally agree with that assessment. If a promotion packet is all about the features someone has done or simply the technology they have used, it will most likely fail the impact test.
This is particularly important with software engineers. Understandably, most of us decided to pursue this career because of our passion for technology. Sometimes, though, when writing about our accomplishments and examples for a promotion, we fail to articulate well the problems we solved and the resulting impact in the first place.
As a manager, you should make sure that the value this individual brought to the company is captured well. The more objectively you can articulate this, the better. Has their work contributed to your operational efficiency? Capture that. Have they contributed to key company goals and/or metrics? Make sure this story is told. Have they distinguishably unlocked someone else’s work to allow them to hit company goals? Write about that.
Finally, and this is even more important the more senior the candidate is, I found that showing how this candidate is able to balance business and tech priorities is an important hidden trait to call out. Being aware of these trade-offs and explicitly calling them out when someone consistently makes good choices is an important hallmark of seniority.
Technical complexity
This is a very debatable topic but one that I’ve seen applications failing on the basis of. The more senior the role someone is applying for, the stronger the evidence they need to show on their ability to tackle technical complexity. This can manifest itself in different forms. An obvious one is when someone solves a complex problem, technically speaking. A less obvious example includes successfully solving important problems that require working with legacy systems where documentation is lacking, and the original authors are not around anymore. Or when someone needs to navigate the complexities of a multi-stakeholder project in order to deliver for the company.
It’s also important to pay close attention to the quality of one’s outcomes. At Spotify, sometimes a promotion committee will also be in charge of analysing that person’s notable PRs (Pull Requests), and key RFCs produced. When analysing PRs, committee members want to see the quality of the code produced and the quality of the PR itself in terms of descriptions and aids for reviewers. They also want to see how the author engaged with reviewers to make sure high-quality code is being merged. It goes without saying, of course, that everyone should pay attention to these things regardless if they are aiming at a promotion or not.
Leadership
Demonstrating leadership at the next level is usually a requirement. A candidate usually needs to showcase their ability to lead technical initiatives independently. The higher the level, the more complex and wide in scope these initiatives should look. Someone trying to get into a senior staff engineer role will probably need to demonstrate the ability to drive big, impactful efforts that will often involve several different stakeholders and multiple teams across different organisations. On the other hand, someone trying to get into a senior engineer role will probably need to demonstrate the ability to drive single-squad efforts.
Regardless of the level, the skill to influence and collaborate with others in order to solve a given problem should be there. What will vary with the level is basically how wide-reaching these abilities should be.
I also like to include under leadership someone’s ability to help others to grow. As engineers, especially more senior ones, it’s also a valuable trait the ability to create space for others. Examples of such activities are knowledge-sharing sessions, pair programming with less experienced members of the team, mentoring other engineers, onboarding new team members, etc.
Engineers that succeed in leading initiatives at the appropriate level and at the same time act as force multipliers by helping others to grow, when combined with the other elements outlined here (consistency, business impact, and technical complexity), present a really strong case for promotion. Managers and engineers should try to ensure that all these points have been clearly articulated and also make sure that other important aspects of their companies not covered here have been captured.
Key takeaways
-
Allow enough time to work on the promotion material.
-
Have a realistic timeline that both you, as a manager, and the candidate are comfortable with.
-
Keep your promises and deliver according to the timeline agreed upon.
-
Make sure the promotion materials are polished (i.e. professionally presented), but also that the following aspects have been sufficiently covered with evidence and examples: consistency, business impact, technical complexity, and leadership.