The senior engineer was ready to quit. She'd been at the company three years, received excellent performance reviews, taken on increasing scope, and led critical projects to success. But when she asked about promotion to staff engineer, her manager said she "wasn't ready yet"—without being able to explain what ready would look like.
"I asked what I needed to do," she told me. "He said I needed to 'demonstrate more impact.' I asked what that meant specifically. He couldn't tell me. He said I'd know when I saw it."
She'd seen colleagues promoted to staff with similar track records. The difference, as far as she could tell, was that they had different managers—managers who advocated more forcefully in promotion discussions, managers who had better relationships with the leadership team. The criteria for advancement seemed to be less about performance and more about politics.
She was right. Her company's career ladder was a political fiction. It had level definitions on paper, but the definitions were vague enough to justify almost any decision. "Demonstrates technical leadership" could mean anything. "Has significant impact" could mean anything. The real criteria were unwritten: having the right sponsor, being visible to the right people, not threatening anyone powerful. The ladder provided a veneer of objectivity over what was fundamentally an arbitrary process.
This is common. Most engineering career ladders don't work—they're either too vague to guide actual behavior, too rigid to accommodate different kinds of contribution, or too disconnected from how promotion decisions actually get made. Engineers see through the fiction quickly, and when advancement feels arbitrary, they leave for places where it might be more fair or at least more lucrative.
At SmithSpektrum, I've helped over 30 companies build or rebuild their engineering career ladders[^1]. The ones that work share certain characteristics: clear behavioral expectations, multiple valid paths to advancement, calibrated decision-making processes, and genuine connection between the ladder and actual promotion outcomes. The ones that don't work are surprisingly consistent in their failure modes.
Why Ladders Fail
Career ladders fail in predictable ways.
Vague criteria create arbitrary decisions. "Has significant impact" means whatever the evaluators want it to mean. A manager who likes someone can find evidence of significant impact; a manager who doesn't can find evidence of insufficient impact. The same performance gets different outcomes depending on who's evaluating, which makes the ladder meaningless as a guide for development.
Exclusive focus on technical depth excludes legitimate contributions. Traditional ladders reward engineers who go deep on hard technical problems—system architecture, performance optimization, technical innovation. But engineering teams also need people who excel at collaboration, mentorship, project leadership, cross-team coordination. If these contributions don't count for advancement, the people who make them stop making them or leave.
Output measures instead of behavior measures create gaming. If the ladder says "ships large features," engineers optimize for shipping large features—even if smaller features would be more valuable, even if the large features are scope-inflated to look impressive. Ladders should measure how someone approaches work, not just what they produce.
Disconnection from actual decisions breeds cynicism. If the ladder says one thing but promotions happen based on something else entirely—visibility, sponsorship, politics—engineers learn that the ladder is fiction. They stop using it to guide their development because it doesn't actually matter.
Insufficient levels at senior stages create bottlenecks. A ladder with junior, mid, senior, and staff creates a bottleneck at senior—everyone competent reaches senior and then has nowhere to go. If promotion to staff is rare and criteria unclear, you'll lose good seniors to companies where advancement is more accessible.
What Makes Ladders Work
Effective career ladders share certain characteristics.
Behavioral specificity makes expectations concrete. Instead of "has significant impact," the ladder describes specific behaviors: "identifies and addresses systemic problems that affect multiple teams," "builds consensus on technical direction across the organization," "develops expertise that others in the company rely on." These descriptions are specific enough that observers can agree on whether someone exhibits them.
| Level | Scope of Impact | Technical Bar | Leadership Expectations |
|---|---|---|---|
| Junior (L1-L2) | Tasks, features | Completes with guidance | Asks good questions |
| Mid (L3) | Features, small projects | Independent delivery | Helps teammates |
| Senior (L4) | Projects, team-level | Designs solutions | Mentors, influences |
| Staff (L5) | Multi-team, org-level | Sets technical direction | Shapes roadmaps |
| Principal (L6) | Org-wide, company-level | Defines architecture | Influences strategy |
Multiple dimensions acknowledge diverse contributions. A good ladder has multiple tracks or multiple dimensions within a single track. Technical depth is one dimension. Cross-team influence is another. Mentorship and team development is another. Project execution is another. Different engineers can advance by excelling in different combinations—there's not one path to staff that requires everyone to become a system architect.
Behavioral examples make criteria concrete. For each level transition, provide examples of what the behaviors look like in practice. "A staff engineer might identify that three teams are solving the same caching problem differently and lead an effort to create shared infrastructure." Examples help calibration—they give evaluators shared reference points.
Clear expectations for scope and autonomy distinguish levels. Junior engineers need significant guidance and work on well-defined tasks. Mid-level engineers work independently on features. Senior engineers take ownership of components and lead small projects. Staff engineers operate across teams and shape technical direction. The scope and autonomy differences should be explicit.
Connection to reality requires that actual promotion decisions use the ladder criteria. The criteria aren't just documentation—they're the actual basis for decisions. If someone demonstrates the behaviors, they get promoted. If they don't, they don't—regardless of tenure, visibility, or politics.
Structuring Levels Effectively
The number and structure of levels matters.
Too few levels creates bottlenecks. If you only have four levels (junior, mid, senior, staff), most engineers will be senior for years before any promotion opportunity exists. This feels like stagnation even if they're growing within level.
Too many levels creates meaningless distinctions. If you have ten levels, the difference between levels 6 and 7 becomes trivial. Promotions feel like participation trophies rather than meaningful recognition.
For most companies, six to eight individual contributor levels work well: two entry levels (new grad and a step above), two mid levels, two senior levels, and one or two principal/distinguished levels. This provides enough granularity for meaningful progression without creating artificial distinctions.
Management levels should be distinct from IC levels. The transition from individual contributor to manager is not a promotion in the traditional sense—it's a role change with different responsibilities and different success criteria. A senior engineer who becomes an engineering manager isn't higher on the ladder; they're on a different ladder.
Creating parallel IC and management tracks at senior levels is essential. The path to advancement shouldn't require becoming a manager. Staff engineers, principal engineers, and distinguished engineers should have compensation and impact opportunities that rival director-level managers. Otherwise, you push your best technical people into management they don't want.
Defining Level Transitions
Each level transition should be defined by what changes.
The transition from new grad to mid-level is about developing independence. New grads need guidance on how to approach problems, how to navigate the codebase, how to get work done in this organization. Mid-level engineers can take a problem and solve it independently—they know how to find information, make reasonable decisions, and deliver working code without hand-holding.
The transition from mid to senior is about ownership and scope. Senior engineers don't just execute tasks; they own outcomes. They take a vaguely defined project and drive it to completion—defining requirements, making technical decisions, handling the unexpected. Their scope expands beyond individual features to components or systems.
The transition from senior to staff is about impact beyond their immediate team. Staff engineers identify problems that span teams and solve them. They influence technical direction that others follow. They develop expertise that benefits the organization, not just their own projects. Their scope is the organization, not just their component.
The transition from staff to principal or distinguished is about exceptional impact. Principal engineers are recognized externally for their expertise. They shape the direction of their technical domain across the industry. They attract talent who want to work with them. This level is rare and should be—it represents truly exceptional contribution.
Each transition should have behavioral indicators that are observable and evaluable. Not "is ready for the next level" but "currently demonstrates the behaviors expected at that level."
The Evaluation Process
The ladder is only as good as the process that applies it.
Self-assessment starts the process. Engineers should evaluate themselves against the ladder criteria, providing evidence for each dimension. This forces engagement with the criteria and surfaces where engineers believe they're performing.
Manager assessment provides a second perspective. Managers evaluate the same criteria, noting agreement or disagreement with self-assessment. Where assessments differ, there's a conversation to be had—either the engineer has a blindspot, the manager has a blindspot, or there's a communication gap.
Peer feedback provides additional signal. Peers observe behavior that managers don't see. Collecting structured peer feedback on specific ladder dimensions improves accuracy. This is particularly important for dimensions like collaboration and mentorship that are hard to observe from above.
Calibration sessions make decisions consistent. Managers present their assessments to a panel (skip-level managers, peers, HR) who calibrate across the organization. Someone who'd be rated "ready for promotion" by one manager should be rated similarly by another. Calibration corrects for manager variance.
The decision should follow logically from the evidence. If someone demonstrates the behaviors expected at the next level, they're promoted. If they don't, they get feedback on what's missing. The decision shouldn't be mysterious—it should be traceable to specific behavioral evidence.
Common Pathologies to Avoid
Certain patterns predictably undermine ladders.
"Time in level" requirements create unnecessary frustration. If someone demonstrates staff-level impact after one year at senior, why should they wait two more years? Time-based requirements tell high performers that their performance doesn't matter, only their patience.
Stack ranking against peers is toxic. If only 10% can be promoted regardless of how many people are ready, you're creating zero-sum competition that undermines collaboration. Promotion should be about meeting criteria, not beating colleagues.
Visibility weighting rewards self-promotion. If getting promoted requires "being visible to leadership," you're rewarding political skill rather than actual contribution. The engineer who does excellent work quietly shouldn't lose to the engineer who does adequate work loudly.
Manager favoritism corrupts the process. If promotions depend more on manager advocacy than on evidence, the ladder is fiction. Strong managers will promote their people regardless of merit; weak managers will fail their people regardless of merit. Calibration must correct for this.
Retroactive criteria changes destroy trust. If someone is told to demonstrate X for promotion, demonstrates X, and then is told actually they needed Y—trust is destroyed. The criteria must be stable and honestly applied.
Making Ladders Useful for Development
The best ladders aren't just evaluation tools—they're development tools.
Ladders should guide career conversations. Managers and engineers should review the ladder together regularly, identifying which behaviors the engineer already demonstrates and which are development areas. The conversation shifts from "what do you need to do to get promoted" (transactional) to "what skills do you want to develop" (developmental).
Ladders should suggest learning paths. If the ladder says staff engineers "build consensus on technical direction," the implied development path includes learning how to write persuasive technical documents, how to navigate organizational disagreement, how to build coalitions. The behaviors suggest the skills to develop.
Ladders should help people find projects. If someone wants to develop cross-team influence, they need opportunities that involve cross-team work. Managers should help engineers find projects that let them practice and demonstrate the behaviors they're developing.
Ladders should enable honest conversations about fit. Not everyone wants to become a staff engineer—and that's fine. Some people want to go deep on technical problems within a narrow scope. Some people want to manage. Some people want to stay at senior forever. The ladder should help people understand their options and make authentic choices rather than assuming everyone's goal is the top of the IC ladder.
Evolving Ladders Over Time
Ladders need maintenance and evolution.
New roles and team structures require ladder updates. If you adopt a platform engineering model, does the ladder account for platform engineer contributions? If you add a security engineering function, are there clear paths for security engineers? Ladders that don't evolve become misaligned with actual work.
Feedback from users improves ladders. Engineers who use the ladder for development and managers who use it for evaluation have opinions about what works and what doesn't. Collect that feedback systematically and use it to iterate.
Calibration data reveals problems. If certain dimensions are evaluated inconsistently, they may need clearer definition. If certain levels have extremely low promotion rates, the criteria may be unrealistic. If certain managers consistently differ from calibration norms, they may need coaching. The data from operating the ladder informs its improvement.
Industry norms evolve. What "senior engineer" means has evolved over time and varies by company. If your ladder is significantly misaligned with industry norms—if your senior is the industry's mid-level, for instance—you'll have difficulty attracting talent and retaining people who realize they're being underleveled.
The senior engineer who couldn't get a straight answer about promotion to staff? She joined a company with a clearer ladder.
The new company's ladder had specific behavioral expectations for each level. The promotion process involved self-assessment, manager assessment, peer feedback, and calibration. She could see exactly what was expected at staff level—and could see that she already demonstrated several of those behaviors while having clear growth areas in others.
Eighteen months later, she was promoted to staff—not because she'd played politics, but because she'd developed the behaviors the ladder defined and could demonstrate them to calibrators. The process felt fair because it was fair.
"The ladder isn't the magic," she told me. "It's the commitment to actually using it. Having clear criteria only matters if the criteria actually drive decisions."
References
[^1]: SmithSpektrum organizational design, career ladder development, 30+ companies, 2018-2026. [^2]: Progression.fyi, Engineering Career Ladder Database. [^3]: Dresscode, "Engineering Ladder Framework." [^4]: Will Larson, "Staff Engineer: Leadership Beyond the Management Track," 2021.
Building or improving your career ladder? Contact SmithSpektrum for organizational design and leveling framework development.
Author: Irvan Smith, Founder & Managing Director at SmithSpektrum