I talk to many people who feel stuck at the mid-level and can’t break into senior/staff-level engineering roles. The chasm you need to cross widens with each role, so it gets harder and harder with each jump.
Many places adopt an “up or out” strategy, meaning that you need to get to a senior-level role, which is seen as a “cruising altitude” role where you can stay indefinitely. I wouldn’t feel pressured by this if you’re a mid-level engineer. This commonly takes around 2-6 years to achieve, depending on your personal growth rate. Of course, it doesn’t hurt to grow faster, but I would advise against “speedrunning” to senior and focusing more on your impact, as it’ll have better long-term gains in your career. Working on a massive, impactful project you can talk about publicly is better than just focusing on hitting all of the goals to get to the next level in the long run.
Level Archetypes
This is an overview of the levels at most tech companies. Of course, it’s company-dependent, with FAANG roles generally having more levels in between. This is commonly just Junior, Junior++, though, and they are usually done to increase salary little and often. I find archetypes helpful for understanding how the role operates at a high level, so I’ve included them for each.
Junior - Think of this as the journeyman archetype; they spend their time learning and growing. Juniors are a net productivity loss to the company, and really, all we look for is a base level of skill, enthusiasm, and high growth rates. Almost everyone can do this, and most will make it to the next level within 1-2 years. We want you to be able to contribute and reach mid-level as quickly as possible.
Mid-level Engineer - Think of this as the farmer archetype; they work independently on the land they’re given. They should be able to complete most of the work independently, being handed simple projects with reasonable scope and provided with relatively little guidance. In engineering, mid-level engineers are responsible for doing a lot of the day-to-day work that might not be glamorous but needs to be done. Feature tickets, smaller projects, maintenance work, and general day-to-day tasks that come up.
Senior Engineer - Think of this as the hunter archetype; they’re responsible for leading and training. Senior engineers are expected to lead projects end to end, from planning, managing, delivery, and retro. They document the work they do and present the outcomes. They evaluate the impact of their work in advance and pick the highest priority items. At most, they are given a problem space but never solutions by their manager. They delegate work to mid-level engineers to help them grow, eventually letting mid-levels lead. Senior engineers are usually the bulk of most tech companies, as they can deliver decent outcomes with little oversight. They may need some direction on what problems to focus on, but generally, a solid senior engineer will do the right thing 80% of the time.
Staff+ Engineer - Think of this as the explorer archetype; they go on adventures to find new lands. Staff engineers need to work at breadth, not on projects but on large-scale programs that touch multiple groups inside the company. These programs measurably improve company and team-level goals, ideally with staff+ engineers responsible for finding new goals. They delegate heavily, focusing on architecture and training, but can roll their sleeves up and get stuff done if required. A good chunk of engineers will likely never reach staff level, and many will take 10+ years to achieve it, but there are always outliers.
Leveling Details
You are expected to fully operate at the next level before getting promoted. This means meeting most of the criteria for the next level and acting somewhere in the middle of the band for that role. This is because managers don’t want to promote you, only for you to perform poorly in your new role and get bad ratings. We want to encourage you to take on a role where we know you’ll thrive.
When creating a promotion document for review, always tie it back to:
- Your company leveling structure criteria
- How you delivered on your team and company goals
- Always focus on your impact rather than your actions. Use the classic SBI model (Situation, Behaviour, Impact).
Common Questions and Mistakes
With the levels set, you should have an idea of what you need to do, but just because you know the direction doesn’t mean you know the entire path to get there. Some of the common problems I heard from mentees are the following:
“There are no opportunities for senior/staff-level projects.” - This is common in larger companies and more operational-focused teams. To some degree, you have to create your own opportunities, but it is easier on some teams than others. For operational teams, consider looking at trends in operational work and driving projects to reduce some of that work. For SREs or incident responders, this may include looking at incident data, picking the most impactful issues, and driving solutions to those problems with yourself as the project lead. Ensure you measure the impact as you go, and only pick impactful things; avoid minor 1-2% increments. For larger companies, you may consider moving to other teams either temporarily through a secondment or permanently to open up more doors for yourself.
“I’m already acting at the next level, but I can’t get promoted.” - I advise focusing on evidence. Often your packet will be reviewed by a neutral third-party, this means your work needs to speak for itself. Similar to math homework, you need to “show your thinking.” Document the whole process from planning to delivery; consider also presenting or blogging your work after the fact as a form of documentation. Think of your projects as stories; they need a beginning, a middle, and an end. If you miss any part of this, it can be jarring for the reviewer. Commonly, the part most missing is the beginning, as people often don’t measure impact at the start but only at the end. The problem here is you can get to the end and find you only made a minor improvement, which isn’t a good use of time, and even if you did a good job, it could be down to luck, which isn’t going to come across as well to the reviewer. Focus heavily on the impact of your work rather than the actions you took. “Contributed 3 features which have 1m combined MAU and on track to grow 5% per year” is better than “Worked on these 30 projects”. Always assume the reviewer has no idea what you do, so set the scene at the start of the packet about what good looks like in your role.
“My manager doesn’t put me up for promotion.” - Good managers, in good circumstances, care for the well-being of their team. That being said, not every manager is good, and many are overworked with giant teams they can barely keep up with. It doesn’t hurt to be direct with your manager. Tell them you are looking to get to the next level since we often have many engineers at cruising altitude who are happy to keep going as they are. I recommend preparing a document with evidence about how you are meeting the criteria of your company-specific promotion requirements. Be realistic with yourself when completing this, and try to look at it from the evidential standpoint of a third party with no knowledge of your work. Review this with your manager in your 1:1s and identify gaps. As you get closer to filling in your gaps, consider asking your manager to work on a promotion document with you, as you can more easily find issues when the document is created.
“I’ve hit the glass ceiling for my role.” - Of course, we can’t all keep progressing, and the glass ceiling comes for all of us at some point. My advice to these people is that it depends on what role you’re in and what aspirations you have. If you’re in tech support, where the glass ceiling is low, consider reaching out to other teams looking for secondments and an eventual move if that’s what you feel like. You could also make a lateral move to some other role. As a security manager, I’ve hired a ton of people from our tech support teams, especially those who bring me interesting security issues and show a keen enthusiasm for it. There are always alternatives if you’re feeling like you want something new. Now, if you are a staff-level engineer looking for something more, that’s different. It’s unlikely in many places that you’ll get to higher levels without putting in some serious work, and even then, it might not be enough. I don’t want to sound like a therapist but consider finding joy in something else at this point. If you are still dedicated, do a side gig, join a startup, contribute to open source, or just volunteer. Diversify your time for greater rewards.
“My only option to grow is to become a manager.” - Generally, in the tech industry, managers and ICs (independent contributors) have separate tracks that progress at the same rate and get paid the same. In some classic sectors, you must become a manager to progress further. I do recommend that everyone try being a manager even once. I was a reluctant manager myself but decided to give myself a year of doing it seriously to see if I liked it. Since then, I’ve changed my tune, and this is where I feel home is for me (with a few stints back to IC for exciting projects). Some people I know did a year, bounced off it, and never went back, but all of them said it was a good experience that made them a better IC, so don’t let it hold you back.
“I’m too busy to document all of the work and present what I do.” - This is fine in bursts; sometimes you’ve got an urgent project or even a secret one you’re not allowed to document, and it just needs someone to put in the hard work to get it done. However, if this goes on for longer than two or three months, you should try to find balance. Find a couple of hours each fortnight to document the basics, and block that time out on your calendar if possible. Usually, it only takes a couple of extra hours to fully document a project, which can have less tangible benefits like helping train others and acting as examples for similar projects. At some point, you have to prioritize yourself, and if you keep taking on urgent projects, you’ll only be rewarded with more urgent projects.
“I’m embedded in a different team and nobody has an idea what I do.” - Admittedly, this is a difficult one. Some functions, such as program managers, security, and data, can often be embedded into other teams that lead their performance reviews. I have two pieces of advice here: you should aim to be a leader, and you should align your impact to the team’s goals. First, rather than helping people out with projects all the time, you should aim to analyze what’s going on and make suggestions for projects. Even though it may not be your day-to-day domain, don’t be afraid to act as a subject matter expert. The second point is that the more you can tie your work to the team’s goals, the better. If you are on the data team, you can show how you analyzed some data, found a pattern, spun up a project, and then measured the results. This is tangible evidence to show your impact to the wider team, in a way that they will understand.
Conclusion
Hopefully, this blog will give you an idea of how to overcome the barrier to the next level. I truly believe that if you pass the interview process and you make it to a mid-level engineer, then 95% of the time, with some hard work, you should be able to make it to senior at the very least. Staff engineer is usually less than 10% of the company, and the principal is generally less than 1-2%, so be realistic here. Most companies don’t rank engineers against each other, but it’s almost impossible not to do so at the principal level and above because there is often no set criteria for what they do.
Every company I’ve worked at has had a running joke that “the only way to become staff-engineer is to leave and come back again,” but most commonly, the people who do that leave for somewhere with amazing mentors and opportunities, working on new and interesting stuff to them. This is a risky strategy that does pay off for some, and did for many in the hot tech market of the past ten years, but you rarely hear about the ones who get a new role and underperform, only to get managed out, which is more commonly happening at these levels today. An alternative is to meet with others in similar roles, build a community, and learn from them. Take what they teach and apply it in your company. If you are stuck on ideas, then the best approach is to get out of your day-to-day and do something different, sometimes this is a new role, but theres always other alternatives.