The bar for Senior isn't mysterious. It's published. Dropbox, Stripe, and levels.fyi all describe it in writing. The problem is that most engineers treat it as a single bar when it's actually two. They work hard on one track and wonder why the promotion committee keeps saying "not yet." This post gives you the diagnostic to find out which track you're missing - and a 90-day plan to close the gap.
If you've read our guide on getting promoted as a software engineer and wanted something more specific, this is the self-assessment version. That post covers the promotion process. This one covers where you're stalling on the way there.
TL;DR
- Senior promotion requires demonstrating competencies on two distinct tracks: technical depth AND team impact. Most engineers over-index on one.
- Technical depth: system design ownership, code review leadership, architectural ownership (ADRs you've authored or co-authored), and technical debt triage you've led - not just flagged.
- Team impact: a junior engineer you've mentored, a cross-team deliverable you owned as SWE lead, a project with a named outcome, a business-impact translation your manager can reference, and a contribution your manager cited unprompted.
- These groupings come from public engineering ladders at Dropbox, Stripe, and levels.fyi - not criteria invented for this post.
- A 90-day plan targeting one gap on each track produces more promotable evidence than open-ended self-improvement.
Is Senior the right move for you right now?
Targeting Senior when you've been in your current role less than six months is usually the wrong sequence. The promotion process at most companies requires concrete examples tied to your current codebase and team - examples you won't have yet. The move is to spend the next one to two quarters building two or three strong evidence cases, then reassess. Rushing the timeline doesn't compress the evidence-building phase.
Before you commit to the 90-day plan below, two quick filters.
The first is time-in-role. If you've been at your current company for six months or fewer, a promotion push is unlikely to land. That's not a character judgment - it's that the committee needs evidence attached to this team, this codebase, this set of stakeholders. Engineers who switch companies hoping to jump levels often find they've reset the clock instead. Stay long enough to build real examples.
The second is whether you're looking for the right thing. If you're looking for someone to validate that you're "basically ready" without doing a structured gap analysis, a mentor is the wrong tool to start with. Use this guide first. A mentor's value is calibrating your evidence against your specific company's undocumented bar - not reassuring you. If you go into a mentorship session without knowing which competency track you're weak on, you'll get generic advice. Generic advice is what got you stuck.
On compensation: Senior Software Engineer salaries in the US generally run from $130,000 to $200,000 or more in total compensation, with significant variation by company tier, geography, and whether equity is included. At top-tier tech companies, the range extends to $250,000 and above with equity. Mid-market companies cluster in the $130,000 to $160,000 range. Bay Area and New York roles still pay a premium even with remote work common.
What Senior actually is - and what it isn't. More tickets, faster PRs, or being the most technically skilled person on the team gets you to mid-level done well. Senior is the level at which you stop being a solo contributor who ships well and start being a force multiplier on the people and systems around you. You don't get promoted and then start doing the senior job. As _michaellin wrote in the DEV Community post "Why You're Not Getting Promoted as an Engineer": "You start doing the job and then get promoted."
What senior software engineering actually involves
Senior engineers spend most of their week on things that don't appear in a git log. Code is part of it - but system design discussions, cross-team technical reviews, architectural decision records, mentoring sessions, and project planning are where senior-level expectations actually live. If your current output is almost entirely tickets and PRs, that's the first gap to close, not a reflection of your technical ability.
Kunal Ganglani put it directly in his 2026 analysis "Senior Engineer Hidden Roles: 4 Skills Beyond Code": senior engineers spend 50-70% of their time on activities that never show up in a git log. If that number feels wrong, track your week for five days. Count hours on code versus hours on design discussions, cross-team coordination, code review strategy, and mentoring. Most mid-level engineers are surprised.
Here's what the shift looks like in practice. A mid-level engineer receives a cross-team technical request - say, an adjacent team needs your service to expose a new API for their feature. The mid-level engineer picks a ticket, implements it, and ships it. A senior engineer does something different: they meet with the adjacent team to understand their downstream requirements, consider how the API design affects other potential consumers, write a short architectural decision record explaining the tradeoffs, and make sure the adjacent team lead agrees before committing to implementation. Same output. Completely different footprint.
| What mid-level engineers own | What senior engineers own |
|---|---|
| Individual tickets and PRs | System design decisions and their rationale |
| Code quality within their scope | Code review quality across the team |
| Implementing existing architecture | Authoring and advocating for new architecture |
| Identifying technical debt | Scoping and leading technical debt remediation |
| Their own output | Outcomes across their team and adjacent teams |
The two-track competency assessment
Senior promotion committees are looking for evidence on two distinct tracks - not just technical skills. Most frameworks lump everything into "technical and soft skills," but the engineering ladders at Dropbox, Stripe, and aggregated data from levels.fyi describe something more specific. Technical depth is one track. Team impact is the other. You can be strong on one and still not get promoted - because the committee is looking for evidence on both.
This section is a tool. Complete it. Don't just read it.
Track 1 - Technical depth
Most engineers stall on system design ownership, not code quality - and that single gap blocks more Senior promotions than any other. Technical depth for this level breaks into four areas: system design ownership (you drive the design, not just contribute to it), code review leadership (your reviews improve the design, not just the syntax), architectural ownership (you've written or co-authored an ADR that was adopted), and technical debt triage (you've scoped and led a refactor, not just identified the problem). The key word is ownership. Strength on one area without ownership evidence on another is still a gap the committee will find.
These four areas come from the engineering ladders at Dropbox and Stripe, and from aggregated Senior SWE criteria at levels.fyi. They're not invented here - they're the framework the committee is already using.
Rate yourself on each one:
| Competency | Evidence format | Self-rating |
|---|---|---|
| System design ownership | Design doc or ADR you authored | Doing this / Not doing this / Never shown it |
| Code review leadership | Review comments that changed the design | Doing this / Not doing this / Never shown it |
| Architectural ownership | ADR adopted by team | Doing this / Not doing this / Never shown it |
| Technical debt triage | Led scoped refactor | Doing this / Not doing this / Never shown it |
"Doing this" means you have a recent concrete example - not that you understand the concept. "Not doing this" means you're capable but haven't been doing it in your current role. "Never shown it" means you don't have a clear example even if you were asked in an interview.
One of our mentees, Michele, came from a small university in southern Italy and landed a Tesla internship after working with his MentorCruise mentor. His mentor, Davide Pollicino, helped him close gaps in algorithms and system design, refine his resume, and prepare through mock interviews. Read Michele's full story
The principle carries. Structured, targeted work on specific competencies moves faster than general preparation. Michele wasn't weak overall - he had specific gaps, addressed them specifically, and produced a concrete outcome. The same logic applies if you've been shipping code for two or three years and haven't built a system design ownership example yet - the gap isn't your overall ability, it's one specific row in this table. A system design mentor can do exactly that for the design ownership row.
Track 2 - Team impact
Team impact at senior level isn't about being likeable. It's about five specific things the Dropbox and Stripe ladders name as evidence: you've mentored a junior engineer who became more effective; you've owned a cross-team deliverable where you were the technical point of contact; you own at least one project end-to-end; you've translated a technical decision into business terms your stakeholders understood; your manager can name your contributions without you prompting them.
The reason team impact catches engineers off guard is that it's not on the standard "technical skills" checklist - but it's the track that gets deferred longest. Engineers who reach mid-level competent often coast on technical output and never build the evidence base for team impact. By the time they're targeting Senior, they have a year's worth of strong code and zero examples of owning a cross-team outcome.
Rate yourself:
| Competency | Evidence format | Self-rating |
|---|---|---|
| Mentoring / onboarding | A junior engineer you can name who grew under your support | Doing this / Not doing this / Never shown it |
| Cross-functional technical leadership | Cross-team project where you were the SWE owner | Doing this / Not doing this / Never shown it |
| Project ownership | Project with named outcome you owned end-to-end | Doing this / Not doing this / Never shown it |
| Business-impact visibility | Technical decision you translated into business terms | Doing this / Not doing this / Never shown it |
| Manager-acknowledged contribution | Contribution your manager referenced in a 1:1 unprompted | Doing this / Not doing this / Never shown it |
Ivan Novak has led engineering teams at multiple startups through hypergrowth. On MentorCruise, he helps engineering managers navigate the transition from IC to leader - a path he's walked himself and coached dozens of others through. The same evidence-building logic applies to team impact: you can't assert you've been doing senior-level work, you have to have examples someone else can corroborate. An engineering management mentor like Ivan can tell you whether your team impact evidence is strong enough before you bring it to a promotion conversation.
How to close the gaps - a 90-day plan
Once you've run the two-track assessment, pick the one competency where you're rated "Not doing this" on each track - not "Never shown it." "Not doing this" is a promotion gap you can close this quarter. "Never shown it" is a hiring gap that takes longer. A 90-day plan targeting one gap per track produces more promotable evidence than spreading effort across everything.
The three phases:
Days 1-30: Diagnose
Complete both track self-assessments in full. Every row gets a rating - no blanks. Exit criterion: you can walk through each row and explain which rating you gave and why. If you're vague on any row, that's useful data - it means you don't have a clear example, which puts it in "Not doing this" at best.
Days 31-60: Close one gap on each track
Technical depth: pick one competency rated "Not doing this" and move it to "Have a concrete example I can speak to." Exit criterion: a specific PR, design doc, or ADR that demonstrates the competency - not what you plan to do, a real artifact that exists. If your gap is system design ownership, write an ADR for the next non-trivial decision on your team, even if it's a one-pager.
Team impact: same standard. Pick one competency rated "Not doing this" and produce a real example. Exit criterion: a real outcome, a person's name, a project name, a business metric. "I've been mentoring someone informally" doesn't count - name the person, name what they can do now that they couldn't before.
Days 61-90: Build visibility
Your manager needs to know you're targeting Senior and has seen evidence. Exit criterion: you've had an explicit conversation with your manager about the promotion criteria at your company and received specific feedback on your gap. Not a general 1:1 - a promotion-criteria conversation. You can name one thing your manager said you need to demonstrate. "My manager knows I want to get promoted" doesn't pass. "My manager told me I need one more cross-team ownership example before they can make the case" does.
The reason Day 61-90 is its own phase: visibility is where most engineers fail even when their evidence is solid. Promotion committees rely on the manager's read. If your manager can't speak to your technical depth and team impact from memory, you're not promotable yet - regardless of what you've built.
Common roadblocks - and how to get past them
The most common promotion blocker isn't missing skills - it's missing visibility. Your manager can only advocate for you in a promotion committee if they can name your contributions without you telling them. If you've been doing senior-level work quietly, the solution isn't to do more - it's to surface what you're already doing. Ask for a 1:1 specifically about promotion criteria, not a general catch-up.
Four specific blockers:
Missing visibility. You've been shipping senior-level work and your manager doesn't know. The fix: ask directly - "I'd like to have a conversation about the promotion criteria for Senior and where I am relative to those criteria." Most managers will appreciate the directness and give you a clear answer.
No concrete examples. The self-assessment tables identify the exact next evidence case to build. Use them as a task list. Pick the lowest-friction gap to close first - often it's the team impact row for manager-acknowledged contribution, because you can create that by surfacing existing work explicitly rather than building something new.
Undocumented company bar. Every company's leveling criteria differs. Dropbox and Stripe make their engineering ladders public, and those are the best starting frame you have - but your company has undocumented expectations on top of those, things the committee weighs that aren't written anywhere. This is the calibration gap that generic guides can't close. The only instrument that reads it is someone who has been on the other side of your company's (or a closely similar company's) promotion committee.
"I'm basically ready" without evidence. Readiness is in the evidence, not the feeling. If you're looking for someone to confirm you're ready, use the assessment first. "I'm basically ready" as a starting position almost always means you've been operating at mid-level competently and assumed that converts to promotion evidence. It doesn't.
Tools, mentors, and next steps
The self-assessment tells you where your gap is. A mentor who has been on the other side of a promotion committee at a company like yours tells you whether your evidence is strong enough to actually close it. That's a calibration problem that generic guides can't solve. Company-specific promotion bars are undocumented by design - the only instrument that reads them is someone who has been inside.
The combination that works: complete the two-track assessment yourself, then bring your specific gap to a mentor for calibration. Live sessions are useful for mock promotion conversations - working through how you'd present your evidence to a committee. Async review (sharing a design doc, a promotion writeup, or a manager conversation you're prepping for) is where detailed feedback happens. You don't need broad coaching. You need targeted calibration on one question: "Is this evidence strong enough, and what does the committee at a company like mine actually want to see?"
Ivan Novak has coached dozens of engineers through IC-to-leader transitions on MentorCruise - and he's been on the other side of those conversations. We accept under 5% of mentor applicants, so when you find one here, you're getting judgment you can trust. Find a senior software engineering mentor
Recommended next reads:
- Our guide on getting promoted as a software engineer covers the promotion process in detail - this post gives you the self-assessment to run first.
- The leveling guide from junior to senior maps the full IC progression if you want the broader context.
- Technical leadership goes deeper on the skills side of the team impact track.
FAQs
How long does it take to get promoted to Senior Software Engineer?
Most engineers reach Senior between three and six years into their career, though the range is wide depending on company, role, and how deliberately they're closing specific gaps. The timeline compresses when you're intentional - an engineer who spends a quarter building system design ownership moves faster than one who waits for opportunities to appear. At fast-growing startups, the timeline can be shorter. At larger companies with structured leveling processes, expect 12 to 18 months from a deliberate push.
What's the salary range for a Senior Software Engineer in the US?
US Senior Software Engineer salaries generally run from $130,000 to $200,000 or more in total compensation, with significant variation by company tier, geography, and whether equity is included. Top-tier tech companies often pay $180,000 to $250,000 and above with equity. Mid-market companies cluster in the $130,000 to $160,000 range. Geography still affects pay even with remote work common - Bay Area and New York roles pay a premium.
Do I need to switch companies to get promoted to Senior?
No - most Senior promotions happen at the engineer's current company. Switching can accelerate the title if you join at a higher level, but it resets your context and relationship capital, which are the same assets the team impact track is building. The case for staying: your manager already knows your work and can advocate for you. The case for switching: if your company has a promotion freeze or a slow leveling process, the math changes. Run the self-assessment at your current company first.
How do I know if I'm ready to be a Senior Software Engineer?
You're ready when you have concrete evidence on both competency tracks - not when you feel ready. Complete the two-track self-assessment in this post. If you have at least three rows rated "Doing this" on each track, with specific examples you could describe in a review, you're in the promotable window. If most rows are "Not doing this," you're in the gap-closing phase. Readiness is in the evidence, not the feeling.
What's the difference between a Senior Engineer and a Staff Engineer?
Senior engineers own outcomes within their team and immediate stakeholders. Staff engineers own outcomes across teams - they drive cross-org technical decisions, write proposals that affect multiple teams, and are the go-to authority for technical problems without a clear owner. The jump from Senior to Staff is primarily about scope and influence, not technical depth. Senior is a prerequisite for Staff; it's not a smaller version of the same role.
How does a mentor help with getting promoted to Senior?
A mentor closes the calibration gap - the difference between knowing what the bar looks like (public frameworks, this post) and knowing whether your evidence meets the bar at your specific company. Every company's leveling criteria differs slightly, and the undocumented expectations matter as much as the official ladder. A mentor who has been on the other side of a promotion committee at a company like yours can tell you whether your work is strong enough - or what evidence you still need to build.
