Yashveer Singh
Connect
<- All posts
Startup Technical Strategy12 min read

The Engineering Career Ladder That Engineers Trust

An engineering career ladder defines the expectations and behaviors at each engineering level. A ladder that engineers trust is one where the criteria for advancement are specific and observable, the differences between levels reflect real capability differences, and promotions happen based on demonstrated performance rather than tenure or favoritism. Most ladders fail on at least two of these three dimensions.

Written by Yashveer Singh, founder of Yashveer Labs.

What you actually need to know

  • Vague criteria are not neutral. They produce promotions that appear arbitrary and damage trust.
  • The difference between levels must reflect real capability differences that the team can observe, not years of tenure.
  • Senior engineer to staff engineer is the hardest transition. Define it clearly or every senior engineer will expect promotion to staff on tenure alone.
  • Consistency in application matters as much as the criteria themselves. One promotion that appears to violate the criteria undoes six months of trust.
  • The ladder is a management tool. If it is not being used in performance conversations, it is a document, not a system.
LevelCore ResponsibilityScope
Junior (L1-L2)Completes well-defined tasks with guidanceIndividual tasks
Mid-level (L3)Owns features end-to-end independentlyFeature scope
Senior (L4)Owns complex systems, mentors othersProject scope
Staff (L5)Multiplies team effectiveness, shapes architectureTeam scope
Principal (L6+)Defines technical direction across teamsOrganization scope

The core argument

The engineering career ladder that engineers do not trust has one common problem: the stated criteria do not explain the promotions that actually happen. An engineer who reads "promotes senior engineers who demonstrate strong technical leadership and mentorship" and then watches a colleague get promoted for being friendly with the engineering director has learned that the stated criteria are not the real criteria. That engineer has also started updating their resume.

The damage from an untrustworthy ladder is not just to the engineers who were not promoted. It is to the engineers who wonder why their colleague was. It is to the manager who now has to explain a decision they cannot defend. It is to the next recruiting conversation where a candidate asks about career growth and the manager cannot give an honest answer.

A ladder that engineers trust has three properties. First, the criteria are specific and observable. Not "demonstrates technical excellence" but "designs and implements systems that are used across multiple teams without requiring significant rework." Second, the criteria are applied consistently. If two engineers reach the same milestone in the criteria, their cases for promotion are treated equivalently. Third, the promotions track the criteria. When engineers look at the people who were promoted, they see the criteria reflected in those decisions.

Building a ladder with these properties is harder than writing a document. It requires the engineering leadership to make difficult decisions explicitly, to explain those decisions to the team, and to hold the criteria even when it is uncomfortable.

Writing criteria that are actually evaluable

The test for a good criterion: can two different engineers, evaluating the same person, independently reach the same conclusion about whether the criterion is met? If yes, the criterion is evaluable. If not, it is vague.

Vague: "Strong communicator." Evaluable: "Regularly writes technical documents that stakeholders outside engineering use to make decisions, without editing from the engineering leader."

Vague: "Demonstrates leadership." Evaluable: "Has led a project where at least two other engineers were contributing, delivered the project on time, and can speak to the decisions made and why."

Vague: "Strong technical skills." Evaluable: "Has designed and implemented a system that serves production traffic and has been in production for at least three months without a significant regression."

The evaluable criteria are longer and more specific. That specificity is the point. It makes the evaluation consistent and makes the expectation clear to the engineer who is trying to grow.

The senior-to-staff transition

The senior to staff transition is the one where most career ladders fail to be specific enough. The result is that every senior engineer who has been at the level for two or three years expects to be promoted to staff. When they are not, the explanation is unconvincing.

The difference between senior and staff is not more of the same. A senior engineer who does everything a senior engineer does but faster is still a senior engineer. A staff engineer does something categorically different: they make other engineers more effective.

The specific things that characterize staff engineers: architectural decisions that improve the entire system rather than just the component they are working on, mentorship that demonstrably accelerates the growth of junior and mid-level engineers, technical proposals that shape the team's roadmap rather than just the next sprint, and the ability to operate effectively in ambiguous situations where the problem definition is not given to them.

If these things are not described specifically in the staff-level criteria, the promotion conversation will be about effort and tenure rather than impact. Effort and tenure are easy to argue. Impact on the team and system is specific and observable.

Common mistakes engineering leaders make with career ladders

  1. Writing the ladder once and not updating it. As the company grows, the definition of staff-level impact changes. A ladder written for a 10-person team does not work for a 40-person team.
  2. Not using the ladder in performance conversations. If the ladder is not referenced in 1-on-1s and performance reviews, it is a document, not a system. Every career development conversation should be anchored to the ladder.
  3. Making exceptions for strong performers that undermine the criteria. A promotion exception for one engineer establishes that the criteria are negotiable. This damages the ladder's credibility for everyone.
  4. Not defining the IC and management tracks separately. A senior engineer who becomes an engineering manager is on a different track. If the ladder does not account for this, engineers who want management roles do not know how to move toward them.
  5. Not gathering engineer feedback on the ladder annually. The engineers who use the ladder are the best evaluators of whether it is fair and specific. Annual feedback sessions reveal the places where the criteria are unclear or inconsistently applied.

Where to start: a 3-step ladder improvement

Step 1: Take the current ladder criteria and test them. For each criterion, write three observable behaviors that would demonstrate the criterion is met. If you cannot write three specific behaviors, the criterion is too vague.

Step 2: Apply the criteria to the last five promotions. For each one, identify which specific criteria were met. If the mapping is clear and consistent, the ladder is working. If the mapping is unclear or required significant interpretation, the criteria need to be more specific.

Step 3: Share the criteria with the team and ask for feedback. Ask engineers to identify any criteria they find unclear or inconsistently applied. Their feedback reveals the gaps that management cannot see from inside the system.

What Career Frameworks Reveal About Engineering Culture

Yashveer Singh. Founder of Yashveer Labs. The career ladder is the engineering team's contract with itself. How specific it is, how honestly it is applied, and whether promotions track the criteria reveal more about an engineering culture than any stated value. If you are building an engineering team and want a perspective from someone who thinks carefully about how technical teams function, the contact page is there.

Related reading

FAQ

Frequently asked

Author

The work I take and why

I take work that compounds. I do not take work that is rework with extra steps. Yashveer Singh, founder of Yashveer Labs. If the topic on this page is what you are dealing with, the question is not whether it can be solved. It can. The question is whether you want to solve it once or four times. I am the person who solves it once.

Related reading