Building an Engineering Career Ladder: Levels, Competencies, and Promotion Criteria That Scale

Most teams build a career ladder after something goes wrong. An engineer gives notice because they had no visibility into when they might get promoted. Two engineers doing equivalent work discover they hold different titles. A manager makes a promotion call and realizes there is no shared vocabulary to justify it to the rest of the team. These are not exotic edge cases. They are the default outcome when a growing engineering team treats the career ladder as an HR formality rather than an engineering artifact.

This article covers how to build a career ladder that is specific enough to be useful, honest about what promotion actually requires, and designed to scale from a handful of engineers to an organization where the founder no longer knows everyone personally.

---

Why You Need a Ladder Before You Think You Do

The inflection point is not 50 engineers. It is the moment a second manager exists with the authority to make promotion decisions. At that point, calibration problems are guaranteed without a shared framework.

Without a ladder, three failure modes compound:

Retention failures are invisible until they are not. Engineers who feel stuck rarely say so directly. They start interviewing elsewhere, get competing offers, and leave. Post-mortems on attrition almost always surface “no clear path” as a contributing factor. By then it is too late.

Title inflation becomes a negotiating lever. When there are no defined levels, every hire negotiates their title. Seniority drift follows. Within two years you can have six engineers who are all “senior” with wildly different capabilities, which breaks calibration for the next round of promotions.

Manager bias goes unchecked. Without written criteria, managers promote people who communicate the way the manager prefers, who work on the most visible projects, or who remind the manager of their younger selves. The ladder does not eliminate bias, but it forces it to be explicit, which makes it contestable.

The right time to build the ladder is before it is visibly broken, ideally when the team is 8 to 12 engineers. At that size the artifact is still manageable and the organizational debt is recoverable.

---

The IC Track: Junior Through Principal

The individual contributor track is the spine of most engineering ladders. The management track branches off it, covered in the next section.

A five-level IC track works for most organizations up to around 150 engineers:

Level	Common Title	Scope	Execution	Influence
IC1	Junior Engineer	Assigned tasks within a story	Completes work with regular guidance	Team member
IC2	Engineer	Stories within a sprint	Completes work independently, flags blockers early	Team member
IC3	Senior Engineer	Features with multiple stories	Owns delivery end-to-end, pulls in the right people	Team and adjacent systems
IC4	Staff Engineer	Initiatives spanning teams	Defines the technical approach, unblocks others	Cross-team, sets direction
IC5	Principal Engineer	Multi-quarter technical strategy	Sponsors initiatives, not just executes them	Organization-wide

IC4 and IC5 are not guaranteed for every career trajectory. They represent genuine organizational need, not just tenure. A team of 15 engineers may not need more than one or two IC4 engineers. It almost certainly does not need an IC5 yet.

The Management Track Fork

The fork typically happens at IC3. An engineer who wants to grow into engineering management moves from IC3 to EM1 (typically titled Engineering Manager). This is not a promotion in the traditional sense. It is a role change. The competencies are different. Technical skill matters less. People development, process design, and cross-functional communication matter more.

Forcing people to go through management to advance is a ladder design mistake. It produces managers who want to be ICs and ICs who feel stuck. The IC4/IC5 path and the EM path should be parallel and equally valued by the organization. If your IC4 earns less than your EM2 who manages the same-sized team, you have a compensation problem that undermines the ladder.

---

Defining Competencies Across Four Axes

Level tables answer “what level is this person?” Competency definitions answer “what does it mean to grow from one level to the next?” You need both.

The four axes that matter most:

Technical skill covers the craft: design systems that hold up under real load, write code others can maintain, make architectural decisions with explicit tradeoffs, recognize when to use simple solutions over clever ones.

Scope covers how much context the engineer can hold and operate in independently. Junior engineers work within a story. Senior engineers own a feature. Staff engineers own an initiative that cuts across teams. The scope axis is often the clearest signal in calibration because it is observable.

Execution covers reliability and judgment under uncertainty. This is not just “ships things.” It includes flagging risks early, adjusting plans when reality diverges from estimates, and pulling in help at the right time rather than too late or not at all.

Influence covers how the engineer affects others. Junior engineers influence nobody outside their own work. Senior engineers shape how their team approaches a problem. Staff engineers change how multiple teams make decisions. Principal engineers shape organizational norms.

These axes interact. An engineer with strong technical skills but narrow scope and low influence is an IC2 or IC3 at most. An engineer with broad scope and high influence but weak execution judgment is dangerous in the wrong role. The ladder needs to capture all four.

---

Writing Level Expectations That Are Actually Useful

The hardest part of building a ladder is writing expectations that are specific enough to guide growth conversations but not so prescriptive that they become a checklist to game.

Two anti-patterns to avoid:

The vague standard. “Demonstrates technical leadership” appears in dozens of engineering ladders. It means nothing without elaboration. What does technical leadership look like at IC4 vs. IC3? What would you see in code review, in design documents, in incident response?

The point system. Some teams quantify contributions: 10 points per PR merged, 5 points per design review completed. This produces engineers who optimize for the metric rather than the outcome. You will get more PRs and more design reviews and less judgment.

The better approach is writing behavioral examples at each level. Not prescriptive checklists, but “a person operating at this level would typically…” descriptions grounded in things that actually happen.

Here is a concrete example for the Technical Skill axis at IC2 and IC3:

---

IC2: Technical Skill

A person operating at IC2 can implement features within an established codebase with guidance on approach. They understand the systems they work in well enough to make local changes without breaking adjacent code. They ask good questions during design review. They write tests for their own code. They recognize when a design decision is outside their experience and ask for help before coding rather than after.

Things they are still learning: choosing between competing architectural approaches, understanding the tradeoffs of dependencies they introduce, designing APIs that other teams will consume.

IC3: Technical Skill

A person operating at IC3 can design a feature end-to-end, including its API surface, data model, and failure behavior. They identify risks in design documents written by others and articulate them clearly. They make dependency and build-vs-buy decisions with explicit tradeoffs documented. They know when a problem is a performance problem vs. a correctness problem vs. a reliability problem and attack them differently.

They produce code that other engineers cite as a reference. They can explain not just what the code does but why it is structured the way it is.

---

The difference between IC2 and IC3 here is not “more experience.” It is a qualitative shift in what independent problem-solving looks like. That distinction needs to be legible in a performance conversation.

---

The Calibration Process

Calibration is the process by which a group of managers align on who is at what level across the team. Without it, each manager operates with their own implicit rubric and the ladder is theater.

A minimal calibration process for a team of 10 to 30 engineers:

1. Self-assessment. Before calibration, every engineer writes a half-page self-assessment against the competency axes for their current level. This is not a performance review. It is a grounding document. It surfaces misaligned expectations early, which makes calibration more efficient.

2. Manager write-up. Each manager writes one paragraph per report that summarizes their assessment of current level, specific examples for each axis, and a trajectory signal (growing toward the next level, solid at current level, concerns about current level).

3. Cross-manager calibration session. Managers meet, read each other’s write-ups, and calibrate. This is where you find the cases where Manager A’s IC3 looks like Manager B’s IC2, or where someone has been at a level long enough that the trajectory question matters.

4. Documented output. Calibration produces a written record of who is at what level and why. This is not for performance improvement plans. It is the baseline for the next promotion cycle.

Calibration fails when it becomes a ranking exercise. The goal is not to force-rank engineers. The goal is to ensure that “IC3” means the same thing across the organization.

---

Promotion Packets

A promotion packet is the artifact that justifies moving someone from one level to the next. It forces the sponsoring manager to be specific and gives the broader calibration group enough information to evaluate the case without knowing the person.

A minimal promotion packet template:

Name: [redacted for calibration]
Current level: IC2
Proposed level: IC3
Sponsoring manager: [name]
Calibration date: [date]

## Summary
One paragraph: what changed, and why this person is operating at IC3 now.

## Evidence by axis

Technical skill:
- [Specific example with context: what the situation was, what they did, what the outcome was]
- [Second example]

Scope:
- [Specific example]

Execution:
- [Specific example]

Influence:
- [Specific example]

## Sustained performance signal
How long has this person been operating at the proposed level? What are two or three data points from the past six months that demonstrate it is not a single spike?

## Gaps and mitigations
What is this person still developing? How does it factor into this promotion decision?

## Compensation adjustment
[Handled separately in the official process]

The “sustained performance signal” section is the most important and most often skipped. A single impressive project is not a promotion signal. Operating consistently at the next level for 3 to 6 months is. The packet needs to make that case explicitly.

The “gaps and mitigations” section signals organizational maturity. Nobody is perfect at a new level on day one. Acknowledging real gaps and why they do not block the promotion is more credible than presenting a flawless case.

---

Common Mistakes

Too many levels too early. A six or seven level IC track makes sense at a company with thousands of engineers because they need fine-grained compensation bands. At 20 engineers, the difference between IC3a and IC3b is invisible and the overhead of calibrating across that many levels is not worth it. Start with four or five levels.

Copying FAANG ladders without context. The competencies that define a Google L6 or Meta E6 are calibrated against what those organizations need at that scale. “Demonstrates org-wide impact” means something specific when the organization has 10,000 engineers. It means something very different or nothing at all when you have 25. Copy the structure, not the content.

Title inflation during hiring. Giving every senior hire the title they negotiated for rather than slotting them into the ladder correctly creates permanent calibration problems. It is better to have the conversation during the offer and pay at the top of the band for someone who interviews at IC3 but presents themselves as “senior” at their last company.

Confusing level with tenure. The ladder defines capability expectations, not time-in-seat. An engineer who has been IC2 for four years without showing the behaviors described for IC3 should not be promoted. That conversation is hard. Having the written criteria makes it possible to have without it feeling arbitrary.

Writing the ladder once and never revisiting it. The ladder needs to evolve as the organization grows. The scope of an IC4 at 20 engineers looks different than the scope of an IC4 at 100 engineers. Schedule a ladder review annually. The criteria do not need to change much, but the examples and calibration baseline should.

---

How the Ladder Evolves from 5 to 50 Engineers

At five engineers, you do not need a ladder. You need to be hiring well and giving people direct, honest feedback. The overhead of a formal ladder exceeds its value.

At ten to fifteen engineers with two or three managers reporting to a head of engineering, you need the ladder. One manager making all promotion decisions is a single-manager operation. Two managers making independent promotion decisions without shared criteria is an immediate calibration problem.

At twenty to thirty engineers, the ladder needs to include explicit promotion packet requirements and a semi-annual calibration cycle. Informal calibration breaks down. The folk knowledge of “who is good” diverges faster than you can keep up with.

At forty to fifty engineers, you typically need at least one IC4 to function as a technical anchor for the organization. The ladder needs to reflect that. The IC4 expectations should describe what your organization actually needs from that role: RFC review, cross-team architectural consistency, mentoring IC3s toward the next level. Write it for your company, not for a generic tech organization.

The ladder also needs to reflect your hiring bar at each stage. If you are hiring IC3s but your IC3 expectations are calibrated at what your early IC4s looked like, every new hire will feel behind. Calibrate the ladder against your actual team, not against your aspirational team.

---

What Good Looks Like in Practice

A ladder is working when managers can give specific, actionable feedback in a performance conversation without referencing a different engineer as the implicit standard. “You are doing well but not at the next level yet” is not useful. “Your scope is consistently IC3, your technical skill is IC3, but your influence on the broader team is still IC2, which is what we would need to see before making the case for promotion” is a growth conversation.

A ladder is failing when engineers surprise their managers by leaving, when calibration sessions produce arguments about the criteria rather than about specific engineers, or when every promotion case is presented as unique and requires special justification.

The artifact is less important than the conversations it enables. The goal is a shared vocabulary precise enough that “she is operating at IC4” means the same thing to everyone in the room.

---

Building the ladder is the easy part. Calibrating it honestly and having the hard conversations it surfaces is the work.