How to Get Promoted from MTS to SMTS Software Engineer at Salesforce
Building your promotion case?
Get AI coaching on what to document and how to present it.
You've been an MTS at Salesforce for a couple of years. Your code is solid, you ship on time, and your manager has no complaints. But "no complaints" isn't a promotion case. The MTS to SMTS jump is where Salesforce separates engineers who execute reliably from engineers who lead technically, and that distinction trips up a lot of people who think they just need to keep doing what they're doing, only faster.
Senior Member of Technical Staff is the first terminal level at Salesforce. Many engineers spend their entire career here. The company doesn't pressure you to advance beyond SMTS the way they pressure AMTS engineers to reach MTS. That means the promotion is genuinely earned, not expected. It also means the bar is meaningfully higher than AMTS to MTS.
What Changes from MTS to SMTS
| Dimension | MTS (Member of Technical Staff) | SMTS (Senior Member of Technical Staff) |
|---|---|---|
| Scope | Owns features end-to-end within your team | Owns medium-to-large projects, sometimes spanning adjacent teams |
| Technical leadership | Contributes to design discussions | Authors design docs, drives architectural decisions for your area |
| Independence | Works with minimal oversight on assigned work | Identifies problems worth solving without being told |
| Mentorship | Helps teammates when asked | Actively mentors AMTS/MTS engineers, shapes how junior engineers grow |
| Codebase knowledge | Understands your team's code and adjacent services | Deep understanding of your cloud product's architecture and cross-team dependencies |
| Communication | Surfaces status and blockers | Represents your team's technical perspective in cross-team discussions |
The core difference: at MTS, you execute on problems other people identify. At SMTS, you identify the problems yourself, propose solutions, and bring people along. You're no longer just a contributor. You're a technical voice on the team.
How the Promotion Works
Same twice-yearly cycle as every Salesforce engineering promotion. Manager nominations happen in November and May, announcements in February and August.
But MTS to SMTS is where the manager-driven process gets harder to navigate. Your manager needs to show more than "this person ships good code." They need to demonstrate that you're operating at SMTS scope: owning larger projects, mentoring others, making technical decisions that affect the broader team. If your work looks exactly like what every other solid MTS does, your manager doesn't have a strong case to make.
The fastest known MTS to SMTS promotion at Salesforce is about 9 months, based on discussions among verified Salesforce engineers. But that's an outlier. Most promotions take 2-3 years at MTS.
How Long MTS to SMTS Should Take
| Pace | Timeline | What's happening |
|---|---|---|
| Fast | 18 months-2 years | Strong technical leadership, clear design doc ownership, visible mentorship |
| Standard | 2-3 years | Building the case steadily across multiple promotion cycles |
| Slow (investigate) | 3.5+ years | Either missing a dimension (design, mentorship, scope) or manager isn't building the case |
Median total compensation jumps from roughly $208K at MTS to $248K at SMTS based on Levels.fyi. The increase comes from base salary, larger RSU grants, and the performance bonus target increasing from 10% to 15%.
One important comp detail: below LMTS, stock refreshers require an "Exceed Expectations" performance rating. At MTS, this means that even meeting expectations well won't grow your equity over time. Getting to SMTS doesn't change this rule, but the higher base and bonus target make the total package more meaningful.
What Actually Gets You Promoted
Author a design doc that ships
The single strongest signal of SMTS readiness. At MTS, you contribute to design discussions. At SMTS, your name is on a design document that the team executed. This doesn't need to be a multi-quarter architecture overhaul. It could be a well-reasoned proposal for migrating a data pipeline, redesigning an API contract, or solving a performance bottleneck. What matters is that you identified the problem, designed the solution, got buy-in from stakeholders, and the team built it.
If you've never authored a design doc, start by co-authoring one with a senior engineer. Then take the lead on the next one.
Mentor junior engineers deliberately
At MTS, helping teammates when they ask is baseline behavior. At SMTS, mentorship is expected and visible. Take on an AMTS engineer. Help them ramp up. Review their design approaches, not just their code. Give feedback that shapes how they think about problems, not just how they format their PRs.
Your manager should be able to point to a specific person you've helped grow. "This AMTS engineer is now shipping features independently, and their mentor was [you]" is a concrete data point for a promotion case.
Develop cross-team awareness
Salesforce's multi-cloud architecture means your code doesn't live in isolation. SMTS engineers understand how their team's work connects to adjacent teams and the broader cloud product. When a bug crosses team boundaries, you trace it instead of filing a ticket and forgetting about it. When another team is designing something that affects your area, you participate in the review and offer useful input.
Start attending design reviews for adjacent teams. Read their architecture docs. When you see a dependency between your team's work and theirs, bring it up before it becomes a problem.
Show you can identify problems, not just solve them
The hardest part of the MTS to SMTS jump. At MTS, your manager and tech lead point you at problems. At SMTS, you're expected to notice gaps, tech debt, reliability risks, and missing tooling on your own, and then propose fixes. This is what Salesforce means by "creating scope."
Look at your team's on-call rotation. What keeps breaking? Look at the codebase. What's fragile? Look at your product's user feedback. What's frustrating? These are SMTS-scope problems waiting for someone to name them.
Mistakes That Keep Engineers at MTS
Doing excellent MTS work instead of SMTS work. This is the most common trap. You're fast, reliable, and your code quality is high. But doing more of the same work at the same scope doesn't build an SMTS case. Your manager needs to see evidence of scope growth, not speed increases at your current level.
No design doc with your name on it. If you've been at MTS for two years and haven't authored a design document, you're missing the most visible artifact of SMTS readiness. The promotion conversation becomes harder for your manager because they don't have a concrete deliverable to point to.
Limited visibility outside your immediate team. Your manager sees your work. Does anyone else? At SMTS, your impact should be visible to at least adjacent teams. If nobody outside your team knows who you are or what you've built, you're operating at MTS scope regardless of how complex your work is.
Not mentoring anyone. If your manager can't name a junior engineer you've helped develop, you're missing a key dimension of the SMTS case. Mentorship isn't optional at this level. It's expected.
Ignoring V2MOM alignment. Your work needs to map clearly to your team's and manager's V2MOM priorities. If you're pursuing interesting technical problems that don't align with stated priorities, your manager has a harder time building the promotion case, no matter how good the work is.
Waiting for your manager to bring up promotion. Your manager has many direct reports and plenty of their own work. If you haven't had a direct conversation about what SMTS looks like for you and what's missing from your case, schedule one. Ask specifically: "What would you need to see to nominate me for SMTS in the next cycle?"
Frequently Asked Questions
How long does it take to get promoted from MTS to SMTS at Salesforce?
Most engineers who get promoted spend 2-3 years at MTS. The fastest documented MTS to SMTS promotion is about 9 months, but that's rare. The more typical fast track is 18-24 months with strong design doc ownership and clear mentorship evidence.
Is SMTS the terminal level at Salesforce?
Yes. SMTS is the first terminal level, meaning there's no organizational pressure to advance beyond it. Many engineers spend their entire career at SMTS and that's perfectly acceptable. The role is roughly equivalent to a mid-senior level at companies like Google (around L4). Advancing to LMTS requires a different kind of impact: cross-team, cross-cloud, and more organizational.
What's the biggest difference between MTS and SMTS work?
Scope identification. At MTS, someone tells you what to work on and you execute well. At SMTS, you're expected to find problems worth solving on your own. Your manager should be able to point to a project where you said "this is broken, here's how I'd fix it, and here's the design" without anyone asking you to do it.
Do stock refreshers change at SMTS?
The policy is the same: below LMTS, stock refreshers require an "Exceed Expectations" performance rating. Meeting expectations won't grow your equity. However, the SMTS performance bonus target increases from 10% to 15% of base salary, and your base and RSU package are both larger at SMTS, so total compensation grows even without refreshers.
CareerClimb tracks your wins, maps them to what Salesforce evaluates at each level, and tells you exactly what evidence you're missing. When the next nomination window opens, your case is already built. Download CareerClimb