Promotion in Action: What everyone should know to get to the next level
Tags: careerdevelopment, careergrowth, leadership, engineeringmanagemen
Published: 2021-01-08 16:40:15

---
title: Promotion in Action: What everyone should know to get to the next level
published: true
date: 2021-01-04 16:11:59 UTC
tags: careerdevelopment,careergrowth,leadership,engineeringmanagemen
canonical_url: https://medium.com/@wparad/promotion-in-action-what-everyone-should-know-to-get-to-the-next-level-4cc3fb488bda
---

Being in a leadership position for a while now there are a couple of things that I can help point to. While there is some good advice in this post which could help, I first want to focus on the misconceptions:

### Misconceptions

- Years of experience does not equate to “Seniority”. It is a common mistake to associate these and for junior developers it may seem obvious to do so, but in reality there are a lot of aspects that are important for being a “Senior Software Engineer”. I’ll talk about them next. There is an adage of 1000 hours of practice makes the master, but what is usually missing from that is **deliberate** practice. The years of experience aren’t an indication, but in a lot of cases can be cause for concern when you see a junior developer with 10 years of experience.
- I’m not quite sure what getting a Masters has anything to do with getting promoted. In general your level is associated with your ability and outcomes that you impact. Whether you have a masters degree or not is less relevant than what you are doing with that degree. If you go get it and on the day you come back, you magically start performing at the Senior level I would expect to promote you, but in reality that just doesn’t happen. You are still the same person before and after, so that isn’t something you can leverage.
- What you are currently working on or its size isn’t the important criteria for a promotion. It is important that you are showing your impact, but how **visible** it is, isn’t important. As a matter of fact I try to pay close attention to the impact that someone is having and not the size of the project. For example just because you think what you are working on isn’t big doesn’t mean that it doesn’t have value for the rest of the organization.
- Management is the continuity of engineering. What’s important to point out is that this is a **role change** , you are fundamentally doing something different than before. It also is completely independent from managing a team. It is unfortunately common to couple these together, and it is a mistake. Just because you can manage a team, doesn’t mean you are a Tech Lead, and just because you have the technical abilities of a Tech Lead doesn’t mean you can manage a team. I’m not going to go further into that distinction here.

### Possible Criteria for Promotion

Here are my criteria for a promotion. The roles aren’t that important, but the level of the different criteria go with the role change, so Junior (L1) to Senior (L2) has similar criteria to Senior (L2) to Tech Lead (L3), but the level of those criteria are different. There are three criteria I care about for promotion, they are **Expertise** , **Influence,** and **Impact**. For each of these promotions, I expect the following:

#### Expertise

What you do and who it impacts is less important, what is important is what do you know and how well do you know it. Take a simple example of a programming language: “I know language X”. That is great for an L1, but for an L2, I expect the following:

- How often do you know immediately the best way of solving a problem. If you saw a question on stack overflow or from your team in a code review, you would instantly say “you should try Y”.
- Knowing isn’t enough, after careful consideration, you make sure to attend the right tech conferences which will improve your ability to understand language X, as well engage with others.
- New innovations in language X are in your news feed (at work, home is for relaxation). You see these and answer online posts about others trying out similar things, not only do you want to help them, but you want to expand your understanding.
- You are able to take problems that aren’t well defined and run with them. You can see a ticket on a kanban board with some vague requirements and create the user story, follow up with the user who requested it, understand the request, why it is the right request to solve, and then drive it to conclusion.
- If there is something that you don’t understand you ask for clarification, but you don’t ask for the answer.
- You can own the features you work on and make sure they get delivered without needing someone else to drive that towards completion. You help others deliver their work.

I expect you to be an expert in TWO areas that fit into that category. For the L3, you can take this to the next level, specifically by adding in these:

- You have an online repository which others are commenting on, sharing, and contributing. You created that community and drive it forward. This doesn’t have to be a thousand star repo.
- Others in your team learn about the technology just by being in close proximity to you, it isn’t an accident. When you suddenly stop doing the work, they will step up, because they know you are the expert there to help.
- You know what you don’t know, and every passing day you think about how to bridge that gap and understand more about it.
- It isn’t about being a world renowned expert, but it is something that you have considered, and you understand who those people may be.

I expect you to be an expert in THREE areas that fit into this category. Consider how many you have, consider how you improve those around you and contribute to their growth. There are the areas that you do that, and do that in confidence. Others know of your ability there.

#### Influence

Who do you convince and share information with? Influence in your immediate team is important, but what is also expected is influencing those around you. Think of those that you work with, team members, adjacent teams, customers, how do you collaborate with them? Can you join those conversations and contribute to the problem at hand, share knowledge, and gain knowledge? Do you know when to Share and when to Listen? (I want to quote the [ladder of leadership](http://ladderofleadership.com) here.) Are you able to solve problems without discussions (L1), or are you bringing up discussions with your immediate team (L2). Everyday do other team members become better because you have engaged with them? I want my L2 to do that work. I want them to think:

> I’m going to solve these technical problems for the team and it will make the team better.

You can influence others without ever having an expertise, it isn’t required. What is important is that they can listen, this is an important aspect of being a leader.

To go further, influencing your immediate team (L2) is important, but what is also expected is influencing those around your team (L3). I’ll liken this to a network. Think of those that you work with, adjacent teams, customers/users, leaders in your organization, do you share information with them? It is important that when you work with a lot of people you know when to Tell, when to Intend, and when to Lead. When you discuss issues, is it just with your immediate team (L2) or are you discussing and impacting those teams around you (L3). Everyday do other teams become better because you have engaged with them? I want my L3 to do that work. I want them to think how being always on stage causes others to do the right thing.

You can influence others without ever having an expertise, it isn’t required. What is important is that they know when to listen and know when shut down a topic, this is an important aspect of being a leader.

#### Impact

The last important aspect is impact, separate from your expertise and influence is how use utilize your skills and what meaning they have relevant to the business. It is the value you deliver. For an L2, I’ve calculated it as $300K per year. I want to see the business relevance context and value delivered of this amount. It doesn’t matter if you have expertise or influence, if you deliver high amount of business value. You’ve found a problem, and can think of a solution to deliver on it. You may have done that by yourself, but you worked with the team. The work was relevant for the team to be successful, whatever that means for you team.

For an L3, I’ve put the bar at $2 Million per year. Having the relevant business context (L2) is important, but being able to join the feedback from internal, your users, and your competition is what get’s you to this next level. The problem is only the focus, but instead of doing it by yourself, what’s more important is that you lead the delivery of that. I want to see that you are able to capitalize on what is actually relevant for business.

Sometimes that is a new innovation not yet thought of, other times it simply changing some lines of existing code, here or there, but you did it, you figured it out.

#### The Result

These are three important areas for me, while there are ways to excel at all of them, what is important is growth in each category. You could find one of these, for example technical expertise, to be your calling. You love writing code. You can be the best software engineer, paid the most in the company, and revered for your engineering knowledge — for your solutions, but you aren’t necessarily a senior (L2) or a Tech Lead (L3). A careful balance is the key.

### Next Step

Given all that, here is what to do next:

- Your organization may not work the same, and as a matter of fact, I have no doubt that it works totally differently. What is important is to set expectations with your manager about what the Senior role actually means and where you are currently at. Do you know what are these roles, what is expected, and where your gaps are? Understanding these is really important for two reasons. First you need to be aligned with what your organization actually cares about. If you think that making coffee will get you promoted but your manager doesn’t think so, you are going to have a bad time. The second reason is because you might be missing the expertise to get to the next level, and to work on a problem, you need to understand that this is the gap.
- For me, I expect my team to come to me and say “ **I’m ready** to be promoted, here’s why…” And I’ll just respond with “I agree” and then promote them. No, they don’t need to actually use those exact words, but part of being a leader is knowing where you are and being aligned. And if that’s the last part they are missing, I’ll help them say those words.
- Actually work on the challenges laid out in front of you. You likely would have been promoted already if it was the right thing to do. Sure you could work in a backwards industry or environment which doesn’t recognize what you’ve been doing, but chances are someone can tell. If you are growing and your company doesn’t acknowledge that by either promotion or feedback on how to improve, please go somewhere else. You’ll be doing them a favor so they learn about creating a culture of growth, as well as yourself, and possibly all the future engineers that will work in that environment.
- Perform that role for 6 months, the difference between before being promoted and after is literally only the title. I expect that most of our team members already agree that you are a senior or a lead long before the title is there. Getting promoted and then start doing a new role is the cause of “Being promoted to your level of incompetence” and creates an organization of all people who can’t do their jobs. Because if they did their job well they would get another one and another one, until we found one that they couldn’t do.