Software Engineer Promotions

Software Engineer Promotions

Once upon a time I was a young, naive software engineer who thought if I just worked really hard and was very good at what I did things like raises and promotions would occur as I deserved them. Then one day I was complaining to my husband how I hadn’t gotten the raise I deserved and we had the following conversation:

Husband: Did you ask for one?

Me: No, I just worked really hard and did a good job so I assumed they would give me one?

Husband: So, um, let’s sit down…. we need to talk…

And that was the day I learned what now seems obvious. It doesn’t matter how much you deserve something, if you don’t ask for it you aren’t going to get it.

So how do you ask for a promotion in a way that sets you up to get one?

What is your current level?

If you work for a medium to large software company this should be easy to know. Most established companies should have defined career levels that you are hired at and promoted to. If you work for a small startup or company that “doesn’t believe in levels” this is trickier. My general rule of thumb:

  • Intern – First professional job and often still in or just out of school/bootcamp/learning. You know basic coding skills but need heavy guidance, especially on anything related to the entire process wrapped around professionally developing and deploying software in production.
  • Software Engineer – Somewhere generally in the 0 – 6 years out of initially learning to code. This has the highest range of skills since you could start at the same level as an intern and advance to the point you are working with minimal guidance on small to medium sized features and work as a member of a team on large features.
  • Senior Software Engineer – 5+ or 6+ years of professional software development experience. Exact time will often depend on what range of skills you built as a developer. At this point you should be able to mentor other developers and be able to guide a group of several other developers working with you to develop a large feature. Your influence should be across your team. This can be considered a final level for people who want to code and are not interested in leadership roles.
  • Manager/Team Lead – People report to you so that you are doing performance reviews, one on ones, hiring/firing, etc. Your team works on one or more features or products. Your influence is across your team, related teams, and possibly areas outside engineering.
  • Staff/Lead Engineer – No direct reports but provides technical leadership and mentorship across an entire team. You work with your team on multiple features and/or projects. You should be proposing technical and infrastructure work for the team to implement. You will be writing much less code than a senior engineer but your influence is across your team, related teams, and possibly areas outside engineering.

Make a Responsibility Matrix

Once you know your level and the next level grab your favorite spreadsheet software and make a responsibility matrix. It will have three columns.

  • Column 1: Headers and Sub-headers for the general areas of responsibility your organization uses to judge an engineer’s performance.
  • Column 2: Your current role at the top and then for each header/sub-header in column 1 a list of behaviors that are expected for that topic and your current role.
  • Column 3: The role you want to be promoted to and a repeat of column 2 except for that next level role instead.

If your company has a mature engineering organization then this should be easy to make because somewhere these areas of responsibility and behavior for each level should be clearly defined. I was able to make my current matrix by literally copying lines out of a company wide document that says exactly what is expected for each level.

If you are at a startup or company without levels than you will need to work with your manager. Tell your manager you want to defined out the goals you should have at your current level as well as what your goals would be if you were working at the next level. You might even be able to work with your manager to start the process of defining internal levels in general. (Note depending on the company and the startup this can be more or less tricky so tread carefully depending on your read of the space.)

As an example you might have something like:

EngineerSenior Engineer
LearningCreates opportunities for personal developmentMentors members of their team

Organize Your Brag Document by Responsibility Headers

If you don’t know what a brag document is first read Julia Even’s blog post on Brag documents.

When writing your brag document start by putting in a section for each of the headers / sub-headers in your responsibility matrix. Under each of those put two piece of reminder text, the context of column 2 and column 3. Then when you do something that qualifies as one of those activities add it to your brag document with the current date and a brief summary. Take special note of anything you do that counts as next level either by actually marking it or just mentally reviewing it as you add items.

In the end a section in your document may look something like this:


Engineer: Creates opportunities for personal development
Senior Engineer: Mentors members of their team

1/23/22 – Took a 3 day class on advanced object oriented programming
2/01/22 – Onboarded our new intern *

The most important thing to do here is MAKE TIME TO UPDATE YOUR BRAG DOCUMENT. I’m writing this in capital letters mostly because I am horribly bad at it myself. I often end up digging through past notes, PRs, documents, conversations, etc attempting to kludge together a proper brag document after the fact. Don’t be like me. If you can weekly, or at least monthly make sure your brag document is capturing what you are doing, especially when working above level.

You may have the most wonderful manager in the world but they are busy people. If you can’t keep track of the awesome things you are doing… how can you expect them to remember them all?

Use Your Brag Document To Guide Your Next Steps

Many tech companies follow the rule of backwards promotions. To get promoted to the next level you already have to be working at that level at least a large portion of the time. That puts people in the slightly awkward spot of having to work at a level before you are at a level.

This is where the responsibility matrix and brag document come into play. Over the next few months you should start to see some patterns form in your brag document. There will be areas of responsibility that fill up quickly, possibly even with next level work and there will be areas of responsibility where very little if anything is appearing. You have just found your current strengths and weaknesses.

On one hand your strengths are the places you currently shine and that are most likely the easiest for you to strengthen even more. They are the places either your natural talents and/or current org structure make it easiest for you to succeed.

On the other hand your weaknesses are the points that are significantly harder to work on. Either your natural talents are not in that area and/or your current org structure/job has not put you in a position to work on them. The problem is they are most likely to be pointed at as a reason why you may not be ready for a promotion.

I recommend taking a two part approach to these. First, look at your weaknesses. You don’t want to spend all your time on something where you struggle. Instead figure out what is the minimum you need to do or learn to get them good enough. You do NOT need to shine at everything but you do need to be able to handle the base job. Give your weaknesses enough of a focus you show you can do the base required at the next level. Ask your manager for advice on this. Ask more senior engineers. Part of their jobs should be helping you train up so lean on them until you hit the base level.

However, do not let fighting with your weaknesses pull you away from where you really shine. Look at those areas that are your strength and look for opportunities to double down on those. Some one who makes a big impact at work isn’t someone who’s good at everything. It’s someone who knows what they are good at and how to wield it for maximum impact for your organization. Use what you have done as evidence to ask your manager to let you work at a higher level.

Advocate, Advocate, Advocate!

You have two points where self advocacy should be built into the process:

  • 1 on 1s with your manager
  • Reviews

Now that you have your organized brag document you can use your 1 on 1s to keep your manager up to date on what you have been working on and why. Also use it to ask them advice on what you should be focusing on. Is their view of where you are strong and weak the same as yours? What are they looking for? By bringing them into the process by the time you reach review and promotion discussions nothing should be a surprise to either of your.

When it’s time for reviews often companies will ask employees to write a self reflection. My last self reflection came directly from the evidence in my brag document and was organized by those levels from column 1. I literally set my manager up with all the data needed to see exactly where I was working at level and above level. While I didn’t say, Rose is working above level HERE I did make sure to include those items in the list so it was obvious to anyone who knew my levels I was.


And now we circle back to the beginning. If you want a promotion you need to ask for it. Ask what you need to do to get one. Ask what time frame you should be working towards. You aren’t going to get what your manager doesn’t know you want.


With a final note, all this advice assumes a healthy engineering culture that is generally free from active biases and serious problems. If you see red flags like your boss saying:

I feel you aren’t at the level yet but I can’t tell you why.

Or you notice that no one who is like you ever gets promoted to a leadership role… well at that point the best thing you can do for a promotion is find a job that doesn’t have those problems.

2 thoughts on “Software Engineer Promotions

  1. This is great and I’ve already shared it with a person on my team.

    Regarding Senior and Staff engineers, most of the ones I’ve worked with have provided technical leadership to other engineers to implement a change in the system. There are a small percentage, however, who work on their own and are able to solve almost any technical problem the company may have. I think Will Larson calls these engineers “Solvers” in his archetypes of Staff Engineers.

    Regarding Advocacy, I agree this is important. In addition to 1:1s and reviews, I would add that building relationships across the organization with both individual contributors and managers is important, especially at the Staff/Lead level. Last year, HBR ran an article called “You Can’t Sit Out Politics” which I think is worth reading. Building relationships, “reading the room”, and understanding which issues are worth fighting for and how to effectively do so are important if you want to have influence in the organization.

Leave a Reply

Your email address will not be published.