How to Get Promoted as a Software Engineer

I got passed over for a promotion once. I was furious. I'd shipped more features than anyone on my team that quarter. My code was clean. My PRs got approved with minimal revisions. I stayed late. I volunteered for on-call rotations. And the promotion went to someone who I thought was a worse engineer than me.

It took me a year to realize what happened. The person who got promoted wasn't doing better work. They were doing more visible work. They were solving the problems the VP cared about, not the ones buried in the backlog. They wrote a one-page summary after every project and sent it to their manager. They asked their manager directly what they needed to demonstrate to get promoted, then they went and did exactly those things. I was sitting at my desk writing good code and assuming someone would notice.

Nobody noticed.

Here's what I've learned since then, both from my own career and from watching hundreds of developers go through the promotion process at companies ranging from 20-person startups to FAANG. Getting promoted as a software engineer has very little to do with being the best coder on the team. It has everything to do with strategy, visibility, and alignment with what your organization actually rewards.

This guide is the playbook I wish I'd had. No vague advice about "working hard" or "showing initiative." Concrete tactics with specific examples that you can start using this week.

Understand What Promotions Actually Reward

Most software engineers think promotions reward technical skill. They don't. At least, not directly. Promotions reward demonstrated impact at the next level. That's a crucial distinction. Your manager isn't asking "Is this person a good engineer?" They're asking "Is this person already operating like a Senior/Staff/Principal engineer?"

At most companies, the typical promotion timeline looks roughly like this. Junior to mid-level takes about 1 to 2 years. Mid-level to senior takes another 2 to 4 years. Senior to staff can take 3 to 7 years. And the jump to principal or distinguished engineer takes many more. These are averages. Some people move faster. Some people sit at the same level for a decade because they don't understand how the game works.

Google's engineering levels (L3 through L11) are well documented. An L3 new grad typically reaches L4 in 1.5 to 2.5 years. Getting from L5 (Senior) to L6 (Staff) is notoriously difficult and takes many engineers 4 to 6 years if they make it at all. Meta has a similar structure with E3 through E10. Amazon's system runs from SDE I through Principal Engineer. The specifics differ, but the principle is the same everywhere.

What all these systems share is that they promote based on scope and impact, not on hours worked or lines of code written. A junior engineer solves assigned problems. A mid-level engineer solves problems independently. A senior engineer identifies problems that need solving and drives solutions across a team. A staff engineer shapes technical direction across multiple teams. At each level, the scope of your influence grows.

If you want to get promoted, start by getting your hands on the leveling rubric at your company. Most mid-size and large companies have written engineering career ladders. Ask your manager for the document. Read it carefully. Identify the specific gaps between where you are now and where you want to be. Don't guess. Know exactly what the next level requires.

The Promotion Conversation Your Manager Needs to Have With You

John Sonmez nailed this in The Complete Software Developer's Career Guide. He wrote about asking your manager directly what you'd need to accomplish to get promoted, doing those things, then going back and asking for the promotion. Simple. Powerful. Almost nobody does it.

Here's exactly how that conversation works. Schedule a 1-on-1. Don't ambush your manager in Slack. Say something like: "I'm interested in growing to [next level]. Can you help me understand what I'd need to demonstrate to get there, and what timeline makes sense?" That's it. You're not demanding anything. You're not being aggressive. You're showing you're serious about your career and asking your manager to be your partner in that process.

A good manager will give you specifics. They'll say things like "You need to lead a cross-team project end to end" or "You need to show you can mentor junior engineers" or "You need to improve your system design skills and demonstrate that in a real project." Write all of it down. This is your promotion checklist. Now you have something concrete to work toward instead of vague feelings about whether you're "ready."

A bad manager will give you nothing useful. They'll say "Just keep doing what you're doing" or "We'll see how things go." If that happens, push harder. Ask for specific examples of what other people who were recently promoted had demonstrated. Ask if there's a formal rubric you can review. If your manager still can't articulate what you need, that's a red flag about your growth prospects at this company.

Revisit this conversation every quarter. Not every week. You don't want to be annoying. But every three months, check in. "Here's what I've accomplished since we last talked about my growth. Am I on track? What should I focus on next?" This keeps your promotion top of mind for your manager and creates a documented trail of your progress.

Build Your Brag Document (This Is Non-Negotiable)

Julia Evans coined the term "brag document" in her widely-shared blog post, and it's one of the single most effective career tools I've ever used. The concept is brutally simple. You keep a running document of everything you accomplish professionally. Every feature shipped, every bug fixed that saved the company money, every junior developer you helped onboard, every architecture decision you drove, every time you stayed up debugging a production incident.

Why does this matter? Because promotion decisions at most companies happen during calibration meetings, where managers from across the organization sit in a room and advocate for their reports. Your manager has to make your case to people who have never met you and probably don't know what you do. If your manager can't articulate specific accomplishments with concrete metrics, you're dead in the water.

Your brag document is the ammunition your manager needs. Here's what a good entry looks like: "January 2026: Led the migration of our payment service from REST to gRPC. Reduced average response latency from 340ms to 45ms. Required coordination across the payments, checkout, and billing teams. Wrote the design doc, ran two design reviews, and implemented the core service changes. The migration was completed with zero downtime."

Compare that to: "Worked on the payment service migration." The first entry gives your manager something they can actually use. The second one is useless.

For every entry, include what you did, why it mattered, and what the measurable result was. Use numbers whenever possible. "Improved test coverage" is weak. "Increased integration test coverage from 43% to 87% on the auth service, catching 3 bugs before production in the first month" is strong.

Update your brag document every Friday. Set a calendar reminder. Spend 10 minutes at the end of each week writing down what you did. If you try to reconstruct six months of work right before performance reviews, you'll forget half of it. The weekly habit makes this effortless.

The Visibility Problem (And How to Fix It)

There's a painful truth in software engineering. The best engineers don't always get promoted. The most visible engineers do. I hate that this is true. But pretending it isn't true won't help you.

Visibility means that the people who make promotion decisions know your name and associate it with good work. If you're at a 500-person company and the VP of Engineering has never heard of you, getting promoted to senior will be harder than it should be. If your skip-level manager couldn't name a single project you worked on, you have a visibility problem.

This doesn't mean you need to become a self-promoting blowhard. There are authentic, non-cringey ways to increase your visibility. Writing internal tech blog posts or design docs is one of the best. When you make a significant technical decision, write it up. Explain the problem, the options you considered, why you chose the approach you did, and what the results were. Share it with your team and your manager. These documents create a permanent record of your thinking and judgment.

Presenting at team meetings, engineering all-hands, or internal tech talks is another high-impact move. Even a 10-minute presentation on something you learned or a problem you solved puts you in front of people who might not otherwise know your work. I know most developers hate presenting. Do it anyway. The discomfort is temporary. The visibility is permanent.

One tactic from Sonmez's playbook that I've used to great effect is the weekly status report. At every job, he sent his manager a detailed weekly email covering what he worked on, what progress he made, and any issues he saw coming. It made his boss's life easier (managers love not having to chase people for updates), it created a paper trail of productivity, and it was "iron-clad defense against any accusations of not pulling my share." It's such a simple thing. Almost no developers do it. The ones who do stand out immediately.

Cross-team work is another visibility multiplier. When you work only within your own team, only your teammates see your contributions. When you work on a project that touches multiple teams, engineers and managers across the organization notice you. Volunteer for cross-team initiatives, migration projects, platform work, or anything that requires coordinating with people outside your immediate group.

Pick the Right Projects (Not Just the Hardest Ones)

Not all projects are equal when it comes to promotions. I've seen engineers spend six months on incredibly complex, technically brilliant work that nobody cared about because it didn't align with the company's priorities. I've also seen engineers get promoted for relatively simple projects that happened to solve a problem the executive team was worried about.

You need to understand what your company's priorities are. What does the CEO talk about in all-hands meetings? What are the OKRs for this quarter? What keeps your VP of Engineering up at night? Those are the problems you want to solve. Not because you're playing politics, but because impact is measured by business outcomes, not technical difficulty.

At Google, the promotion committee looks for evidence of "Googleyness" and impact. At Amazon, they want to see leadership principles in action. At most startups, they want to see you moving the needle on revenue, retention, or growth. Whatever your company values, align your project choices with those values.

Here's a framework I use for evaluating projects: Is this project visible to leadership? Does it have a clear, measurable outcome? Does it require me to operate at the scope of the next level? If the answer to at least two of those is yes, it's a promotion-track project. If the answer to all three is no, it might be important maintenance work, but it probably won't get you promoted.

That doesn't mean you should refuse un-glamorous work. Fixing flaky tests, reducing tech debt, and handling on-call pages are all part of being a professional. But if you're spending 100% of your time on invisible maintenance and 0% on high-impact projects, your promotion timeline is going to stretch way longer than it needs to.

I talked to a senior engineer at Stripe who told me something that stuck. She said: "I spent two years doing excellent technical work that nobody saw. Then I spent six months working on a project the CTO personally cared about. Guess which period got me promoted." She wasn't bitter about it. She'd just learned how the system works. Now she deliberately balances her time between technical excellence (which maintains her credibility) and high-visibility projects (which drive her career forward).

Demonstrate Next-Level Behaviors Before You're at That Level

This is the part most developers get backwards. They think the sequence is: get promoted, then start doing senior/staff-level work. It's the opposite. You have to demonstrate that you can do the work first. Then you get the title. I know that feels unfair. It is what it is.

If you want to get promoted to senior engineer, start behaving like a senior engineer right now. Senior engineers mentor juniors. Start mentoring. Senior engineers write thoughtful code reviews that teach, not just approve. Start writing those reviews. Senior engineers drive design decisions. Start writing design docs and presenting them to your team.

If you're targeting staff engineer, the bar is higher. Staff engineers think across team boundaries. Start identifying problems that affect multiple teams and proposing solutions. Staff engineers influence technical direction. Start writing RFCs and getting them adopted. Staff engineers are known across the organization. Start building relationships with engineers on other teams.

The key is to do this for long enough that it becomes your reputation, not just a brief experiment. If you mentor one junior developer for two weeks and then stop, nobody will remember. If you consistently mentor juniors for six months and they visibly improve, that becomes part of how people see you. "Oh, that's the person who's great at growing junior developers." That's a promotion-ready reputation.

Sonmez was direct about this. He wrote that effective software developers get promoted, "not the ones who just have the good ideas, but the ones who communicate those ideas effectively." Technical skill is table stakes. Communication, influence, and leadership are what separate engineers who plateau from engineers who keep climbing.

Make Your Manager's Job Easier

Your manager is the single most important person in your promotion process. In most companies, your manager is the one who nominates you for promotion, writes your promo packet, and advocates for you in calibration meetings. If your manager isn't actively pushing for your promotion, it's probably not going to happen.

So how do you get your manager on your side? Start by making their life easier. Anticipate what your manager needs before they ask. If your manager is stressed about a deadline, don't wait to be assigned tasks. Figure out what's blocking progress and handle it. Sonmez described this as "getting stuff done without having to be asked" and called it one of the most valuable things you can do. A manager who doesn't have to spend time managing you will spend time advocating for you instead.

Self-reporting is another powerful move. Send your manager a brief weekly update. What you worked on. What you shipped. Any blockers. Any risks you see coming. This takes five minutes to write and saves your manager from having to chase you down. It also creates a written record that your manager can reference months later when writing your promo packet.

Take responsibility beyond your own code. When a teammate is struggling with a task, offer to help. When a cross-team dependency is blocking your project, step up and drive the resolution instead of waiting for your manager to handle it. When there's an urgent production issue, be the person who responds first. These behaviors signal leadership, and leadership is what promotions reward.

One more thing about managers. If you've been doing all of this for 12 months and your manager still isn't advocating for your promotion, you have three options. First, have a direct conversation about what's happening and why. Second, find a different manager within the same company (internal transfers can reset the dynamic). Third, leave for a company that will give you the title and compensation you've earned. Sometimes the fastest promotion is a new job offer.

The Promotion Packet: How to Build an Airtight Case

At many companies, especially larger ones, promotions require a formal document. At Google it's called a promo packet. At Meta it's a performance summary. At Amazon it's woven into the review process. Whatever your company calls it, you need to understand what goes into it and make sure the content is strong.

Don't leave this entirely to your manager. Even if your manager writes the formal document, you should provide them with all the raw material. Pull from your brag document. Organize your accomplishments by the categories in your company's leveling rubric. If the rubric has categories like "Technical Skill," "Execution," "Communication," and "Leadership," map your accomplishments to those categories.

For each accomplishment, follow the STAR format. Situation: what was the context? Task: what needed to happen? Action: what specifically did you do? Result: what was the outcome, with numbers? This isn't just corporate HR fluff. It genuinely makes your accomplishments easier to evaluate and compare against the leveling rubric.

Peer feedback matters more than most engineers realize. At companies with peer review processes, get endorsements from people who've seen your best work. Don't just pick your best friends on the team. Pick people on other teams who you've collaborated with on cross-team projects. Their feedback carries extra weight because it shows your impact extends beyond your immediate group.

PromoReady, a service specifically for big tech promotion coaching, recommends sharing your brag document with peer reviewers so they can reference specific examples in their feedback. This is smart. Most people who write peer feedback are doing it in a rush and will default to vague statements like "great engineer, pleasure to work with." If you hand them a list of specific projects to reference, their feedback becomes much more useful.

Common Promotion Killers (And How to Avoid Them)

I've watched talented engineers sabotage their own promotions in predictable ways. Here are the most common mistakes.

Doing excellent work in isolation. This is the number one killer. You ship great code, solve hard problems, and never tell anyone about it. Your performance review comes around and your manager struggles to list your accomplishments because they simply didn't know about half of them. The fix is everything I've described above: brag documents, weekly updates, and deliberate visibility.

Focusing only on technical depth. You become the world's leading expert on your team's codebase, but you never lead a project, never mentor anyone, and never step outside your comfort zone. Technical depth is necessary but not sufficient. Promotions require breadth of impact.

Being the hero who fixes everything. Counterintuitive, right? But the engineer who personally fixes every production outage and never builds systems that prevent outages is actually demonstrating junior-level behavior. Senior engineers build processes and tools that prevent problems. They multiply the team's output instead of being a single point of dependency.

Ignoring politics entirely. "I just want to write code." I get it. I used to say the same thing. But office dynamics are real, and pretending they don't exist puts you at a disadvantage. You don't need to be manipulative. You need to be aware of who makes decisions, what those people value, and how to make sure your work is positioned to be seen by the right people.

Never saying no. If you say yes to every request, you'll spend all your time on low-impact tasks that other people don't want. Learning to say "I can do that, but it would mean deprioritizing X" is a senior-level skill. It shows you understand trade-offs and can make strategic decisions about where your time creates the most value.

Changing jobs too frequently. I know job-hopping can be lucrative for salary bumps. But if you're switching companies every 12 months, you never stay long enough to demonstrate the kind of sustained impact that promotions require. Most promotion cycles take 18 to 24 months minimum. If you leave before that, you're resetting the clock every time.

The Promotion Timeline: What to Expect at Each Stage

Let's get specific about timelines. These are based on data from levels.fyi, Blind, and publicly shared career progressions.

Junior to Mid-level (1-2 years). This is usually the easiest promotion. You need to show you can work independently on well-defined tasks without constant guidance. Ship features on your own. Write tests. Handle code reviews. Participate in on-call. Most companies promote this level almost automatically if you're not struggling.

Mid-level to Senior (2-4 years). This is where things get real. You need to demonstrate technical leadership within your team. Own projects end to end, not just individual tasks. Make design decisions. Influence your team's technical direction. Mentor more junior engineers. Write design docs that others follow. This promotion requires active effort and a deliberate strategy.

Senior to Staff (3-7 years). The senior-to-staff gap is where most careers stall. Staff-level engineers operate across team boundaries. They identify and solve organizational problems, not just team-level problems. They shape technical strategy. They're recognized as technical authorities by people outside their immediate team. Many excellent senior engineers never make staff because they can't or won't expand their scope beyond their team. Becoming a tech lead is one path that can help bridge this gap.

Staff to Principal (5-10+ years). At this level, you're shaping the direction of a large engineering organization. Principal engineers at Google, Meta, or Amazon influence technical decisions that affect thousands of engineers. These promotions are rare and typically require industry-recognized expertise and a track record of organizational-scale impact.

These timelines are averages. Some people move faster by deliberately targeting the right projects, building visibility, and aligning with their company's promotion criteria. Others move slower because they don't have a strategy or because their company's promotion process is broken.

When to Jump Ship for a Promotion

Sometimes the fastest path to a promotion isn't an internal one. It's an external one. If you've been consistently performing at the next level for 12+ months and your company isn't promoting you, it might be time to look outside.

There are legitimate reasons companies don't promote people who deserve it. Budget freezes. Headcount caps. Reorgs that reset promotion timelines. Managers who don't know how to navigate the promotion process. None of these are your fault, and none of them should hold your career back.

The external market often values you more accurately than your current employer. A 2024 survey by Robert Half found that professionals who changed jobs saw an average salary increase of 13% to 20%, compared to the typical 3% to 5% internal raise. If your company won't give you the title and compensation you've earned, someone else will.

That said, don't jump ship too quickly. Give your current company a fair chance. Have the promotion conversation. Do the work. Build the case. If after a genuine effort (at least 6 to 12 months) nothing changes, then it's time to update your resume and start interviewing. Your brag document makes this easy, by the way. It's basically a pre-built resume.

One more nuance: getting hired at the next level externally is usually easier than getting promoted internally. Companies have more flexibility with new-hire leveling than with internal promotions, which often require committee approval. An engineer who can't get promoted from Senior to Staff at their current company might get hired as Staff at a new company next month. The system is imperfect. Use it to your advantage.

Your 90-Day Promotion Action Plan

Stop reading and start doing. Here's what the next 90 days should look like if you're serious about getting promoted.

Week 1: Start your brag document. Write down every significant accomplishment from the last 6 months. For each one, include what you did, why it mattered, and the measurable result. Get your company's leveling rubric from your manager or HR. Read it. Identify the specific gaps between your current level and the next one.

Week 2: Have the promotion conversation with your manager. Ask what you need to demonstrate. Get specifics. Write them down. Ask for a timeline. If your manager gives you vague non-answers, push harder or start thinking about whether this manager will ever champion your promotion.

Weeks 3-4: Start your weekly status report habit. Every Friday, 10 minutes, send your manager an update. Also look at your current project portfolio. Are you working on anything high-visibility? If not, identify a project that aligns with company priorities and involves cross-team coordination. Volunteer for it.

Month 2: Start demonstrating next-level behaviors. If you're targeting senior, pick a junior teammate to mentor informally. Write a design doc for a project your team is planning. Present something at a team meeting. Build your visibility deliberately and consistently.

Month 3: Check in with your manager. Review your progress against the criteria they gave you in Week 2. Share your brag document with them. Ask if there are gaps you're not seeing. Adjust your plan based on feedback. Line up peer reviewers who've seen your best work.

Ongoing: Update your brag document every Friday. Keep sending weekly status reports. Keep your productivity systems sharp. Keep choosing projects strategically. Keep building relationships across teams. Promotion isn't a single event. It's the result of sustained, visible, high-impact work that's aligned with what your organization values.

The engineers who get promoted aren't smarter than you. They're not writing better code. They've just figured out that writing code is only half the job. The other half is making sure the right people know about it and positioning yourself to be the obvious choice when a promotion slot opens up. Start doing that today. Your future self will thank you.