Everyone wants to get promoted. You get a title change. You get a compensation increase. You can work on larger-scope projects. But what does it take to get promoted? What are the steps to take so that one does not stagnate in his or her career?
There is no one perfect way to get promoted as a software engineer, but following these tips should set any developer for success!
1. Work on Multiple Projects
The main objective is to ensure that you can work on multiple projects and drive them to completion. You need to prove that you are a competent coder.
When selecting which projects you want to work on, you must ask yourself these questions and make sure the project satisfies these requirements. If not, discuss with your manager to see if it is possible to work on a different project that can meet these requirements.
i.) Is it significantly impactful?
This question can be answered in numerous ways. Does it improve the team’s operational load significantly? Does it improve the reliability of your services? Does it support new, important use cases for other external teams?
All projects are impactful in some sense. The keyword here is significant. If you are not sure about the impact of the project, ask your manager for clarity.
ii.) Is it high visibility?
You want to work on a project that many people are waiting on and are excited for it to be completed. Working on a high visibility project will require you to collaborate with multiple teams, which has several benefits.
First, it will foster relationships with various engineers and teams. You will start to understand what are the different projects that each team is working on and how they all fit together.
Second, you will increase your scope of influence. External teams may start asking you for feedback in evaluating their new services or feature changes.
These skills are the essential characteristics of any staff engineer as well as even a senior engineer. These two skills take a long time to build, and that is why it is important to start early.
iii.) Will I be the project lead?
You need to get clarity if you are leading the project or if someone else is leading the project. It may be that in your first project or first two projects, you are not the project lead, which is expected, since you may still be onboarding onto the team.
However, in subsequent projects, you may want to start taking on project lead responsibilities one at a time. You want to show proof that you can be an independent engineer as well as an engineer that can drive projects to completion. That would include tasks, such as writing technical design documents, planning the milestones, communicating to external teams for collaboration if necessary, etc.
If the project satisfies all 3 checkboxes, then it is a good project to work on! This will help you write an effective promotion document when the time comes.
![](https://cdn.mentorcruise.com/cdn-cgi/image/width=1200,format=auto/https://cdn.mentorcruise.com/M782086acbe9f48126642e093bf6ba151-He8f3af67a2-Fjess-bailey-WeCoLo0Rxp4-unsplash%20(1).jpg)
Photo by Jess Bailey on Unsplash
2. Be an Active Reviewer
You also need to be to demonstrate that you are an effective reviewer. Yes, coding is a big chunk of software engineering, but it should not encompass all 100% of your time. Reviewing code and reviewing design documents is just as crucial. I would say I dedicate about 30% of my week to reviewing.
Effective reviewers for code or design documents think about edge case scenarios. They are able to propose any new alternatives if any. They also ensure that the new changes will not break the existing services and will not lead to performance loss.
For instance, I recently reviewed an engineer’s migration plan. I commented on what are the rollback plans if the migration failed. How would we know if the migration failed? How can we ensure that service performance is not regressing with the migration?
For code reviews, I always check that they write up test cases for new feature changes. If the code change impacts the performance of our services, I always ask for metrics on a before and after. I also ensure that the code is written in a manner that is flexible to business requirement changes.
Being a reviewer on a project that you are not working on can be challenging because you may not have enough context about the project. You may have to read prior documents or set up meetings with fellow teammates to understand the project completely. By being an active reviewer, you will start acquiring the skills to be able to onboard onto any project easily.
Furthermore, reviewing code will foster and strengthen your relationship with your teammates. This is crucial since your manager will collect feedback about you from your teammates when the promotion review comes.
3. Write Strong Technical Documents
You need to also demonstrate that you can write technical documents, which can include technical design documents, post-mortems, migration plans, performance analysis, etc. These documents will illustrate that you have a thorough understanding of the service architecture, which is a strong indicator that you are a competent engineer.
Technical design documents are the best documents to write up because they also require you to practice system design, which is a skill you need for acing software engineering interviews, especially for roles that are mid-senior and above. In my opinion, system design is difficult to practice and improve from reading books. This skill is best improved from on-hand practice.
![](https://cdn.mentorcruise.com/cdn-cgi/image/width=1200,format=auto/https://cdn.mentorcruise.com/M782086acbe9f48126642e093bf6ba151-Hc9277bd880-Fpexels-christina-morillo-1181288%20(1).jpg)
4. Be able to put out fires
This applies to engineers who have oncalls. Getting paged can be a daunting experience since it indicates the service is not behaving to SLA (Service Level Agreement). If it is not fixed within a reasonable amount of time, it can yield disastrous effects, which could be revenue-impacting.
You need to prove that you can solve emergency pages independently. Typically, these emergency pages are customer-impacting, and they probably require a post-mortem writeup. Being able to put out these types of fires requires you to be proficient in several areas.
i.) You can read logs and pinpoint what is causing the issue.
ii.) You can read performance metrics and understand the overall picture. For instance, you may see that there may be a huge spike in GC and a huge increase in traffic. This may mean that your service is under capacity.
iii.) You understand the operational workflow thoroughly— which services can be restarted, whether or not you can kill the whole service in a single batch, how to rollback a service with a previous binary, etc.
Pray that these high severity pages do not happen to you, but if they do happen, you need to be prepared to resolve them on your own. You cannot consistently call your teammates in the middle of the night for a page. That is a sign of an inexperienced engineer.
Final Thoughts
Getting promoted in software engineering is not just cranking out more code. You have to demonstrate that you are a well-rounded engineer, and hopefully, these tips will help you get closer to your promotion!
Resources
I do resume/interview workshops with clients applying for software engineering jobs. I have worked with over 50+ clients, and they have landed competitive job offers at companies like Facebook, DoorDash, Square, and Amazon.