Your best security engineer, or the person who understands your data platform better than anyone, tells you they're thinking about moving into management. When you ask why, they don't say they want to manage people. They say it's the only way up. On paper your company has a staff and principal track. In practice nobody in your group has been promoted on it in two years, the descriptions are copied from the product engineering ladder, and the one principal you do have got the title as a retention counteroffer. This post is about fixing that for a specialist organization: what the senior levels mean, how to write them for your domain, and how to make sure the work they describe actually exists.
How a specialist track turns into a consolation prize
Most organizations say they have a dual ladder. It only works if people believe the individual contributor side leads somewhere they want to go. These are the patterns that break that belief:
| Failure mode | What people conclude | The fix |
|---|---|---|
| Levels defined by depth alone ("deep expert in X") | Staff means "been here longest" | Define levels by scope of impact, with depth as the entry requirement |
| Staff title used to retain people or to soften a "no" to management | The title is a consolation prize | Promote only against written criteria, and say no to counteroffer titles |
| No staff-sized problems in the group | You can't get there from here | Name the problems before you promote people into them |
| Managers get decision rights, staff get "influence" | Real power sits on the other side | Give senior specialists explicit decisions they own |
| Pay bands lower than the management equivalent | The company doesn't really value it | Match bands level for level, and say so publicly |
If two or more of these apply to your group, rewriting the level descriptions alone won't change anything. You have to fix the system around them too.
Define the levels by scope, not by expertise
The most common mistake in specialist ladders is treating each level as "knows more." Expertise is necessary, but it doesn't scale on its own. A brilliant cryptographer who answers every question personally is a bottleneck. One who has changed how forty engineers handle key management is operating at a different level.
Tanya Reilly's The Staff Engineer's Path organizes staff work into three areas: big-picture thinking, project execution, and leveling up the engineers around you. That's a useful check for any level description you write. If a level only describes technical depth, it covers none of the three.
Will Larson's Staff Engineer adds another useful idea: staff roles come in different shapes. He describes four archetypes: the Tech Lead, who guides the approach and execution of a team or group of teams; the Architect, responsible for direction and quality across a critical area; the Solver, who goes deep on hard, high-risk problems one after another; and the Right Hand, who extends a senior leader's reach across the organization. Specialist groups produce a lot of Solvers and Architects. Your ladder should recognize those shapes as equally valid, not only the Tech Lead shape your product teams are used to.
Here is a starting point for levels in a specialist group. Adapt the wording, but keep the structure: scope, time horizon, and what evidence of impact looks like.
| Senior | Staff | Principal | |
|---|---|---|---|
| Scope | A system or a team's work in the domain | The domain across several teams | The domain across the company, often externally too |
| Time horizon | This quarter and next | One to two years | Two to five years |
| How impact shows | Problems solved well | Other teams decide and build differently because of their work | The organization's direction in the domain changed because of their work |
| Leveling up others | Reviews and mentors within the team | Raises the bar of practitioners across teams | Grows the next staff engineers; shapes how the company hires for the domain |
| Typical evidence | Designs, delivered systems, incident fixes | Standards adopted, platforms used, a strategy others follow | Multi-year direction, external standards or research contributions, a capability the company didn't have |
The middle row is the one to hold firm on. "Other teams decide and build differently because of their work" is observable. You can ask those teams. "Deep expert" is not.
Write the expectations in your domain's language
Generic ladder text ("drives technical direction") gives promotion committees nothing to judge against. Translate each level into what it looks like in your specialism. As an example, say you run a security group. A staff-level description might read:
- Owns the threat model for a product area spanning several teams, and those teams use it when they make design decisions.
- Has replaced at least one recurring class of manual security review with a paved path, such as a library, template or automated check, that teams adopt without being forced to.
- Can explain the security risk posture of their area to a director in ten minutes, including what the company is consciously accepting.
- Has developed at least one engineer who now handles reviews in the area without them.
Each line names an outcome someone else can confirm. Do the same exercise for a data or platform group, and for the principal level. Then test your draft against two or three people you'd already consider clearly staff. If your strongest people don't fit the description, the description is wrong, not the people.
Make sure staff-sized work exists
A ladder that describes cross-team impact is useless in a group that only ever gets team-sized problems. This is the cause of most "you can't get there from here" frustration, and it's yours to fix, not your engineers'.
Once or twice a year, list the problems in your domain that are bigger than one team:
- A recurring incident class nobody owns end to end.
- A standard that teams keep working around.
- A capability the company will need in two years and doesn't have.
- A migration everyone agrees is necessary and nobody has started.
Then match those problems to people deliberately, and say out loud that the problem is a staff-sized opportunity. Promotion should follow sustained impact on problems like these, not precede them. Promoting someone and then hoping they find staff-level work usually produces a staff engineer doing senior work with a bigger title, and a team that notices.
If you can't find a list like this, that's useful information too. Your group may not have room for more staff engineers right now, and saying that honestly is better than leaving people to work it out after two failed promotion cycles.
Give senior specialists decisions, not just influence
"Influence without authority" is a real skill, but if it's the only tool your senior specialists have, the management track will always look like the place where things actually get decided. Write down which decisions the specialist side owns. For example:
- Approving or rejecting new technology in the domain, with the manager owning budget and staffing.
- Setting and changing the domain's standards, including granting time-limited exceptions (see Exceptions to engineering standards that expire instead of piling up).
- Final technical call in design reviews within their scope.
- A seat in the planning conversation where next year's domain roadmap is set, not a briefing afterwards.
Share that list with the managers in your group, because their decision rights shrink a little and they need to know where the line is. A one-paragraph note per staff role covering scope, the decisions they own and who they work most closely with prevents most of the friction later.
Run promotions on evidence
When a promotion case reaches calibration, it should stand on evidence against the level description, not on how much the room likes the candidate. A simple case template:
- Candidate and target level.
- Scope: which part of the domain, across which teams, for how long.
- Two or three impact examples: for each, the problem, what they did, what changed, and who outside their team can confirm it.
- Leveling up: who is more capable now because of them, and how you know.
- Gaps: where they don't yet meet the level, stated plainly.
- Archetype: which shape of staff work this is, so they aren't judged against the wrong one.
The "who can confirm it" question does most of the work. If every confirmation comes from the candidate's own team, the impact probably isn't at staff scope yet. For how to prepare the room itself, see Preparing for calibration so your ratings hold up.
Two rules keep the track credible. First, no title as a counteroffer. If someone is at the level, promote them through the normal process; if they aren't, a retention title tells everyone the criteria are negotiable. Second, keep pay bands level for level with the management track, and make that visible. Engineers notice quickly when "equivalent" levels aren't paid the same.
Where to start this quarter
Pick one of these, depending on where your group is:
- No usable ladder yet: Draft the scope table above for your domain and test it against three people you'd already call senior, staff and principal.
- A ladder nobody believes in: Count promotions to staff in your group over the last two years and list the reasons for each "not yet." If the reasons were mostly "no cross-team scope," your problem is the work supply, not the people.
- Staff engineers who feel stuck: Write the decision-rights note for each one and review it with them and their peer managers.
The question to ask yourself: if your best specialist asked you today what they would need to do to reach the next level without managing anyone, could you give them an answer they'd believe? If not, start there. The PTMS study guide covers the wider practice of building specialist capability and passing on knowledge that a track like this supports.