Anatomy of a promotion - Part 2
Details Matter!
In the last post, we discussed the high-level path a manager should take to get an employee promoted. This post is about how to put together a convincing promotion document.
If your company/organization doesn't have a standard template for promotion documents, feel free to steal the template from this post. In general, the goal of a promotion document is to show evidence that the employee can perform at a level higher than they are right now.
Here is the template that I typically use with my teams
Employee Information
Name of employee:
Title:
Years in role:
Years in company:
Last promotion date:
Evidence:
Reasons not to promote:
Feedback (minimum of 4 pieces of feedback)
Feedback provider name:
Title:
Level:
Supportive of Promotion:Y/N
Situational Feedback:
Let's unpack each section, but before that, here are some general tenets to keep in mind while writing your promotion document.
Stay away from weasel words and phrases like, "X is awesome," "Y is an invaluable asset for the team," "Z has unparalleled coding skills," "It will be a mistake not to promote them," and so on.
Clearly showcase outcomes. What happened after the project was delivered? How did it impact the team/organization/company? Do not showcase in-progress projects in a promotion document, as they don't add value and could potentially derail the conversation.
Stick to the facts and don't embellish them. The promotion document is not a resume. Also, if you do embellish the facts there is a decent chance that someone in the room will call you out.
Employee Information
Name of employee:
Title:
Years in role:
Years in company:
Last promotion date:
This is probably the easiest section to fill out. The 'Years in role' is how many years the employee has spent in their current role in their current company and not in their entire career. Even though this section looks simple, I have seen promotions getting cratered in this section.
If the 'Years in role' is under a year and/or the 'Years in company' is under a year, it is a yellow flag. For most promotions, it is tough to gather evidence in under a year, except maybe for early career promotions. In some companies, the HR department won't even consider the promotion if the employee has spent less than a year in their current role. So, if you are putting someone up for promotion who has less than a year in the role or at the company, be prepared to present truly compelling evidence that showcases that they are operating at the next level. In my experience, these promotions are very rare, and they only show up when the company/team is going through extreme stress. Extreme stress creates extreme opportunities that allow exceptional employees to shine and punch above their weight class. There is, however, one exception to the rule worth discussing, and that is a mis-leveled employee.
If you believe your employee was mis-leveled in their interview, it is worth considering a promotion even if they have been in the company less than a year. In those cases, I recommend going back to the employee's interview notes, finding out why this employee was down-leveled, and gathering evidence that fills those gaps. Another thing worth considering is re-leveling outside of a promotion cycle so that the employee gets the right title sooner rather than later. If the employee's compensation is well above the mid-point (and in band for their next level) of their compensation band, which is usually the case with mis-leveled employees because they recently joined the company, then definitely do it outside of a promotion because they most likely won't need a compensation change. These situations should be rare, and if you are constantly fixing mis-leveled employees as part of your promotion process, I recommend re-looking at your interview process and fixing the calibration there.
Evidence
Typically, the promotion evidence for software engineering roles is centered around three key dimensions, namely
Coding
System design
Team Player
As I mentioned before, there might be company-specific nuances, but generally, they are structured around those three dimensions.
Coding
Coding proficiency involves showcasing evidence on two fronts. First, evidence that proves the engineer can get their code reviews through without a ton of back and forth and re-work. It is okay if there is some back and forth, but what you are trying to showcase is that most of their code reviews are non-events, and when there is valid feedback, the engineer accepts it graciously.
Second, the engineer gives valid code review feedback on other engineer's code reviews. The best type of feedback to showcase are ones that prevented a bug (security bugs are the best to showcase!) from getting through to production. Extra points for showcasing evidence of the engineer giving good feedback on a code review authored by someone who is at a level above them. Some engineers going up for a promotion end up overdoing this and give long-winded, rambling feedback in pull requests about inconsequential things like syntactic sugar, etc, so watch for those and nip them in the bud.
Lastly, coding proficiency becomes less of a promotion lever for very senior promotions like senior to staff and staff to principal and above. System design and team/organizational impact matter more for those promotions.
System Design
For anyone going up for a senior+ promotion, it is critical to collect and showcase evidence of being able to design an end-to-end system that solves a real business problem. The scope and scale of the design scales with the promotion. E.g.
Associate -> Mid-level = Being able to design and deliver parts of a major system, like, for example, a net-new endpoint on an existing service, net-new UI component within an existing page, enhancements to a build system that reduces built times, etc.
Mid-level->Senior = Being able to design and deliver a complicated end-to-end system that facilitates a major use case. For e.g., a net-new end-to-end service, a net-new UI framework that powers multiple pages, researching and deploying a new application hosting framework like EKS, etc.
Senior->Staff = Help multiple teams design complicated end-to-end systems. For example, a net new product area that requires multiple services, UI components, and infrastructure to be built.
Staff->Principal = Help the CTO set design and development standards.
One of the things that new managers don't showcase clearly in their promotion case is the complexity of the system design, and they often confuse complexity with the level of effort. For promotions, complexity is more important to showcase than level of effort.
In the context of promotion evidence, the level of complexity is proportional to how many seemingly workable options the engineer had to analyze and research before settling on the one they used in the end. If there is only one clear solution to a problem, its complexity is low.
Here are a few examples-
Lastly, new, greenfield feature development projects are not the only ways to showcase system design prowess. Infrastructure projects, operational excellence initiatives, quality automation optimizations, etc, are also great areas for employees to tackle.
Team Player
Anyone going up for a mid-level+ promotion will need to showcase that they are actively engaging in activities that make the team better as a whole. This includes taking on projects on their own that help the team, making team documentation better, fixing operational metrics, jumping in to solve production issues, jumping in and helping a colleague, etc. However, the strongest evidence to capture and showcase is coaching and mentorship. For senior+ promotions, it is a requirement (IMO) that the employee has strong evidence of mentoring and coaching junior and peer employees. Bonus points for employees who helped other junior employees get promoted!
Reasons not to promote
This is my favorite section in the promotion document to dig into with the manager because it shows how thorough, objective, thoughtful, and realistic the manager really is. I have encountered numerous managers who basically put in nothing in the "Reasons not to Promote" section, and all had a tough time getting their employees promoted. If your company's promotion template doesn't have a 'Reasons not to promote' section, suggest adding it!
All promotions are leaps of faith to a certain extent and hence have some (or a lot) risk associated with them. This section captures the risks associated with the promotion. To put it simply, this section captures all the ways the employee could potentially fail at the new level.
This section should include all the areas where the employee is still developing their skills. For example, an engineer going up for a senior promotion might not have had enough opportunities to work in the infrastructure stack, so it is fair to call that risk in this section. It is also okay to call out some evidence to counterbalance the risk. For example, if the employee had worked in other areas before that were outside their comfort zone successfully, then feel free to call that out as risk-mitigating evidence. But remember to stick to the facts here, and if there is no counterbalancing evidence to the risk you called out, leave it as is and let the group come to their conclusions. Yes, you are trying to get your employees promoted, but you are also trying to make sure they don't fail at the next level, and this section is where you can pressure test that decision.
Feedback
And finally, you need feedback from others that adds further credibility to your promotion case.
Here are some tenets to keep in mind while collecting feedback
I recommend collecting feedback from at least four folks. Three team members and one stakeholder (for example, a product manager).
Feedback providers should be at the level (or above) the employee is trying to get promoted to. It's silly, but a lot of managers mangle this step. They go looking for validation from anyone and everyone regardless of the level of the feedback provider.
Another common mistake that managers make is to share previously collected feedback with feedback providers. They create a single doc for collecting feedback and send it to all the feedback providers. This is a mistake as it biases the feedback providers' feedback. I recommend creating copies of the promotion doc, one per feedback provider, so that the feedback is unbiased.
Feel free to tell the feedback providers why you are collecting this information.
Explicitly ask the feedback provider in the doc if they support the employee's promotion or not.
Ask the feedback providers to provide general feedback in the STAR (situation, task, action, and result) format as much as possible and stay away from platitudes.
When collecting evidence from junior employees (e.g., collecting evidence of coaching), do not tell them you are collecting evidence for a promotion and don't include their feedback in the official feedback section, but include them in the 'Evidence' section.
Multiple pieces of negative feedback are a clear sign that the employee is not ready for a promotion. When you encounter negative feedback, use the opportunity to dig into the feedback with the feedback provider to develop actionable next steps for the employee. On rare occasions, I have seen promotions go through with one negative feedback, but I usually put people up for promotions only if all the feedback providers independently agree that the employee is ready for the next level.
Sometimes, you can get 'mean' feedback. If you feel that the feedback provider wasn't objective with their feedback but rather using the opportunity to settle personal scores, talk to your manager about excluding that piece of feedback. Also, never share the details of the people who provided negative feedback with the employee. It never ends well.
Lastly, as you are putting this together, feel free to review the draft versions of this with your peers and your manager. The more eyes you have on this before the group review, the less drama there is in the group discussion.
And that is it! Now you have a well thought out promotion document to take to the Thunderdome!
P.S - Readers, if you want me to provide feedback on your promotion document, shoot me a note at sensibleexec@gmail.com . I am happy to help out!
P.P.S - If you enjoyed reading this and believe someone else might benefit from this post, consider sharing the post with them!