She was exactly the kind of engineer you build a team around—technically excellent, respected by peers, consistently delivering on difficult problems. When she resigned, her manager was blindsided.
"I've been asking about promotion for two years," she told me. "Nobody could give me a clear answer about what it would take. I don't know if it's politics or if there's a real bar. I just know I can't wait anymore."
The company offered a counter—significant raise, promise of promotion "in the next cycle." She declined. She'd already accepted an offer at a company that had shown her their career framework during interviews. She knew exactly what Senior Engineer meant there, what Staff Engineer required, and how decisions were made. The contrast was too stark.
| Level | Scope of Impact | Technical Expectations | Leadership Expectations |
|---|---|---|---|
| Junior | Task-level | Completes assigned work | Asks good questions |
| Mid | Feature-level | Designs simple features | Mentors occasionally |
| Senior | Project-level | Owns complex features | Guides junior engineers |
| Staff | Team/Multi-team | Sets technical direction | Influences roadmaps |
| Principal | Org-wide | Defines architecture | Shapes engineering culture |
This pattern repeats constantly. I've worked with over 40 engineering organizations on their promotion frameworks at SmithSpektrum, and the story is always similar: talented engineers don't leave because they can't advance. They leave because they can't see the path[^1].
Why Frameworks Fail
Most engineering organizations have something they call a career ladder. Few have frameworks that actually work. The difference matters.
The most common failure is vagueness. I've reviewed career documents that say things like "Senior Engineers demonstrate senior-level impact" and "Staff Engineers operate at the Staff level." This tells engineers nothing. What does senior-level impact look like? How would you know if you were demonstrating it? The document exists to check a box, not to guide careers.
Another failure is inconsistency. Different managers interpret the same criteria differently. An engineer who would be promoted on Team A is told they're not ready on Team B. Word spreads that promotion depends on which team you're on or which manager you have. Trust in the system evaporates.
Then there's the moving goalposts problem. An engineer works toward specific feedback, accomplishes what was asked, and is told at promotion time that "actually, we're also looking for X now." When the bar shifts unpredictably, people stop believing the bar means anything.
And finally, many organizations conflate performance with readiness. Being excellent at your current level isn't the same as being ready for the next level. A brilliant mid-level engineer who hasn't led a project isn't necessarily ready for Senior, even if their individual output is exceptional. Frameworks that don't distinguish performance from readiness create confusion and frustration.
What Actually Works
The promotion frameworks I've seen succeed share common characteristics.
They're specific enough to be useful. Rather than "demonstrates technical expertise," they say things like "Has shipped systems that are in production and processing meaningful traffic, with evidence of good architectural decisions and thoughtful tradeoffs." Specificity makes the criteria assessable and gives engineers concrete targets.
They separate dimensions. Rather than reducing everything to a single rating, effective frameworks evaluate engineers across multiple dimensions: technical skill, scope of impact, independence, leadership, and communication. These dimensions are weighted differently at different levels—junior promotion emphasizes technical growth, while senior-to-staff emphasizes leadership and organizational impact.
They include calibration. No matter how well-written your criteria are, interpretation will vary. Calibration meetings—where managers discuss promotion candidates across teams—catch inconsistency. They surface cases where one manager's "definitely ready" is another manager's "almost there." Over time, calibration creates shared understanding of what each level actually means.
They demand evidence. Opinions are cheap; evidence is expensive. Strong frameworks require specific examples supporting each dimension. "She's a strong communicator" becomes "Her design doc for the payments migration was circulated as an example of clear technical writing, and she successfully explained the rollout plan to the executive team." Evidence keeps promotion conversations grounded.
They're transparent. If engineers don't understand how promotion works, the framework isn't serving them. Everything should be documented: the levels, the criteria, the process, the timeline. Engineers shouldn't have to guess what their manager is evaluating or when decisions get made.
Defining Your Levels
Engineering levels vary by company, but the basic structure is common. What matters is defining each level clearly enough that people know where they are and what they're working toward.
For most organizations, the critical distinction is between Senior Engineer and Staff Engineer. Junior to Mid to Senior is relatively well understood—it's primarily about growing technical skill and independence. Senior to Staff is the first major inflection point, where the job fundamentally changes.
At Senior, you're expected to own and deliver projects independently. You should be able to take a well-scoped problem, design a solution, implement it, ship it, and support it—all without significant oversight. You mentor more junior engineers. You contribute to technical discussions and code reviews. You're a multiplier within your team.
At Staff, you're expected to have impact beyond your team. You identify important problems—not just solve assigned ones. You shape technical direction for your domain. You're a multiplier across teams, helping other engineers grow and aligning technical approaches across organizational boundaries. The scope of your work expands dramatically.
This is the transition where many engineers get stuck, because the job changes more than the level title suggests. A brilliant project executor isn't necessarily ready for Staff if they haven't demonstrated cross-team influence and strategic thinking.
Beyond Staff, you get Principal and Distinguished and Fellow, which have varying definitions by company. The common thread is increasing scope—Principal engineers typically influence their entire organization, Distinguished engineers influence the whole company or represent the company externally.
The exact level names matter less than the clear definition of what each level requires. Some companies use E1-E7; others use Junior/Mid/Senior/Staff/Principal; others invent their own terminology. What matters is that your people understand what the levels mean.
Defining Your Criteria
For each level transition, you need specific criteria that can be evaluated with evidence.
Let me walk through what I recommend for the most common transitions.
Mid to Senior. This is primarily about independence and technical depth. I look for evidence that the engineer can take a feature or project from ambiguous requirements through to production delivery, making sound decisions along the way. They should be able to debug complex problems without significant help, write code that others can understand and maintain, and mentor more junior engineers effectively. Specific evidence might include: shipped features they owned end-to-end, technical decisions they made and their reasoning, code reviews that improved others' work, and junior engineers they helped grow.
Senior to Staff. This is about expanding scope beyond assigned work. I look for evidence that the engineer identifies important problems and drives solutions—not just executes well on what they're given. They should have demonstrated influence beyond their immediate team: maybe they led a cross-team technical initiative, established patterns that other teams adopted, or mentored senior engineers on other teams. They should be able to communicate effectively with leadership, translating technical concepts for non-technical audiences. Specific evidence might include: initiatives they identified and drove, cross-team influence they had, technical direction they shaped, and how they've developed other senior engineers.
For each dimension you care about—technical skill, scope, independence, leadership, communication—define what "meets the bar" looks like at each level. Be concrete enough that managers can evaluate it and engineers can work toward it.
The Promotion Process
A fair process has defined steps, multiple inputs, and built-in calibration.
The process I recommend starts with managers identifying promotion candidates and gathering evidence. This shouldn't be a surprise—if an engineer is being considered for promotion, they should know it, and they should have been getting feedback about their progress toward that goal.
Evidence comes from multiple sources: the engineer's self-assessment (what do they think they've accomplished?), the manager's assessment (what has the manager observed?), peer feedback (how do colleagues experience working with them?), and concrete work products (what have they actually built and shipped?). No promotion should depend on a single person's opinion.
Then comes calibration. All managers at a level meet to discuss their promotion candidates. Each manager presents their candidates and the supporting evidence. The group discusses whether the evidence meets the criteria, and importantly, whether the bar is being applied consistently. Would Engineer A be promoted if they were on a different team? Is Manager B's "definitely ready" matching the group's standard?
Calibration is where frameworks become real. Without it, criteria are just words on a page that each manager interprets differently. With it, criteria become shared understanding of what each level actually requires.
After calibration, decisions are made and communicated. For promotions, this is usually straightforward: congratulations, here's your new title and compensation. For non-promotions, communication is harder but more important.
When the Answer Is No
The hardest part of promotion frameworks is communicating "not yet" in a way that doesn't demoralize and does develop.
The wrong approach: "You're not being promoted this cycle." Full stop. No explanation, no path forward. This leaves the engineer confused about what they did wrong and uncertain about whether they'll ever advance. Many engineers hearing this start looking for other jobs immediately.
The right approach: "You're not being promoted this cycle, and here's specifically why." The feedback should reference the framework's criteria. "You've been strong on technical delivery, but the calibration group didn't see evidence of cross-team influence yet. Here's what that would look like in our context..." Then: "Here's what would change the outcome, and here's how we'll help you get there."
A "no" should always come with a development plan. What specific gaps need to be addressed? What opportunities exist to demonstrate the missing capabilities? What support will the manager provide? What's the timeline for reassessment?
The best managers I work with treat promotion conversations as coaching opportunities. The goal isn't just to decide who's ready; it's to help everyone get ready eventually.
The Dual-Track Question
Most engineering organizations struggle with the IC versus management dual track.
The concept is simple: engineers should be able to advance without becoming managers. Staff, Principal, and Distinguished are parallel to Engineering Manager, Director, and VP in terms of scope and compensation. Individual contribution is not inferior to management.
The execution is harder. Many organizations claim to have dual tracks but actually don't—IC titles exist, but there are few ICs at high levels, and the ones that exist have less organizational influence than their management counterparts.
When I work with companies on their frameworks, I push them to make the dual track real. Are there actually Staff and Principal engineers, or just managers at those levels? Do ICs at those levels have real influence over technical direction, or are they titled but not empowered? Is compensation truly equivalent, or do management roles pay more at similar levels?
If you want senior engineers to stay as individual contributors rather than feeling forced into management, you need to demonstrate that the IC path leads somewhere. That means having visible, respected ICs at high levels, paying them equivalently to their management counterparts, and giving them real authority over technical decisions.
Communicating the Framework
A framework that exists but isn't understood is useless.
Every engineer should be able to answer these questions: What level am I? What does the next level require? How will I be evaluated? When do promotions happen? How can I get feedback on my progress?
This means documentation—publicly accessible, clearly written, regularly referenced. It means managers discussing the framework in one-on-ones, connecting day-to-day feedback to framework criteria. It means new hire onboarding that explains the career progression early.
Some companies resist transparency, worried that explicit criteria will become "checkboxes" that people game. In my experience, the opposite is true. When criteria are vague, people game through politics—building relationships with decision-makers rather than building capabilities. When criteria are specific, people game by actually meeting them—which is exactly what you want.
The engineer who left for a company with a clear framework? She was promoted to Staff within a year at her new company. Not because the bar was lower, but because she knew what the bar was and could work toward it deliberately.
Her former company rebuilt their promotion framework after her departure—and several others like it. They defined specific criteria, implemented calibration, and committed to transparency. They haven't lost a "couldn't see the path" resignation since.
Talented engineers don't need guarantees. They need clarity. Give them a visible path, and they'll run toward it. Hide the path, and they'll run somewhere else.
References
[^1]: SmithSpektrum retention and promotion framework advisory, 40+ organizations, 2019-2026. [^2]: Larson, Will. "An Elegant Puzzle: Systems of Engineering Management," 2019. [^3]: Fournier, Camille. "The Manager's Path," O'Reilly Media, 2017. [^4]: Levels.fyi, engineering level comparison data, 2026.
Need help building an engineering promotion framework? Contact SmithSpektrum for level design and process implementation.
Author: Irvan Smith, Founder & Managing Director at SmithSpektrum