What is a career progression framework? A career progression framework defines the levels within each job family, the competencies expected at each level, the promotion criteria employees must demonstrate, and the career tracks available (IC and management). It makes advancement explicit, objective, and visible to every employee.

Most organizations have career progression in practice — they promote people, they expect certain things from a senior engineer that they don't expect from a junior one — but they haven't written any of it down in a way employees can actually use.

The result is a system that works fine for employees who are visible, who advocate for themselves loudly, and who happen to have managers who are good at articulating advancement criteria. For everyone else, promotion feels opaque, development conversations are vague, and the only way to find out what the next level requires is to watch someone else get promoted.

A career progression framework fixes this. It is not a bureaucratic formality — it is the document that lets every manager have the same development conversation, and every employee see the same path forward.

Why career progression frameworks fail

Before building one, it is worth understanding why most frameworks end up unused. The pattern is consistent: HR spends months writing a framework, leadership approves it, it gets announced — and six months later it sits in a folder nobody opens.

The failure has three common causes:

  • Vague criteria. Behavioral descriptions like "demonstrates leadership" or "thinks strategically" tell employees nothing they can act on. A framework is only useful if its criteria are observable and can be evaluated consistently by different managers. "Has led a cross-functional initiative that affected more than one team" is observable. "Shows strategic thinking" is not.
  • Not connected to reviews. A framework that exists separately from the performance review process is decoration. The framework only becomes real when managers use it as their evaluation rubric — when calibration sessions reference it, when promotion decisions are argued in terms of it.
  • Not visible to employees. If employees have to ask their manager to find out what the framework says, it is not functioning as a progression tool. The framework's job is to make advancement self-service — employees should be able to look at it, compare it to their current ratings, and know exactly what they need to work on.

Our article on building a career framework engineers will actually trust covers the psychological patterns behind framework skepticism in more depth.

The 4 components of a career progression framework

A complete career progression framework has four interdependent parts:

  1. Career levels. The discrete stages of progression within each job family — how many levels exist, what each is called, and what fundamentally distinguishes them. Most organizations use 4–7 levels per job family. See our career levels guide for definitions and examples.
  2. Competencies per level. The specific skills, behaviors, and capabilities expected at each level. Competencies are the "what" — communication, technical depth, ownership, delivery, leadership. Each competency must have behavioral descriptions at each level so the difference between L2 and L3 communication is concrete and consistently interpretable.
  3. Promotion criteria. The evidence an employee must demonstrate to advance from one level to the next. Promotion criteria are the "proof" layer — they answer "how do we know someone is operating at the next level consistently?" Typically a combination of competency ratings above a threshold, scope demonstrated, and time-in-role minimums.
  4. Career tracks. The paths available within and across job families — individual contributor (IC) track, management track, and lateral paths to adjacent functions. Organizations that only define vertical progression implicitly tell employees that career growth means management. See our career pathing guide for why lateral paths matter.

How to build a career progression framework in 7 steps

For a deeper how-to on the competency layer specifically, see our guide on how to build a competency framework. This section covers the full framework process.

Step 1: Scope by job family

Do not try to build a framework for every function simultaneously. Start with the job family where talent competition is highest or career clarity is most requested — typically Engineering, Sales, or wherever your retention problem is most acute. Building one excellent framework creates a reusable template for the rest.

Step 2: Define the level structure

Decide how many levels exist in the job family and what each level represents in terms of scope and autonomy — not just title. A useful framing: L1 works within defined parameters with significant guidance; L2 works independently on well-scoped problems; L3 works independently on complex problems and begins influencing scope definition; L4 operates across teams and shapes direction; L5+ is organizational scope.

Keep it to 5–7 levels for most job families. More than that creates false granularity that makes calibration harder, not easier.

Step 3: Define 6–10 competencies per track

Identify the competencies that determine success in the job family. Most frameworks combine:

  • Core competencies (3–5): communication, ownership, collaboration, delivery — applicable to all levels and tracks.
  • Functional competencies (3–5): role-specific technical or domain skills — system design for engineers, pipeline management for sales, product sense for PMs.

Fewer is better. A framework with 20 competencies takes a full day to evaluate and produces noise. Eight to twelve is the practical ceiling for a framework that will actually be used.

Step 4: Write behavioral descriptions per level

For each competency, write a one-to-two sentence description of what that competency looks like at each career level. The test is: could two managers independently read this and reach the same conclusion about whether a specific employee demonstrates it?

Use active, observable verbs: "consistently drives projects to completion without prompting" rather than "demonstrates ownership." The behavioral description should describe what the person actually does, not a personality trait they embody.

Step 5: Define promotion criteria

Promotion criteria answer: what evidence is sufficient to advance someone? Typically:

  • A minimum average competency score (e.g., 3.5+ on the 1–5 scale) with no competency below 3.
  • Demonstrated operating at the next level for a minimum period (commonly 1–2 quarters).
  • Specific scope criteria — "has led a project with 3+ cross-team stakeholders" for L2→L3.
  • Manager endorsement and calibration session confirmation.

Do not set criteria so high that only rare exceptional performers advance on schedule. Calibrate against your actual team: if only 5% of your people could theoretically meet L3 criteria, your criteria are aspirational, not operational.

Step 6: Add career tracks

Define at least two tracks: IC (individual contributor) and management. The IC track should extend far enough that your best technical people have a path beyond "become a manager or leave" — typically to Staff, Principal, or Distinguished Engineer. Make the crossover point explicit: at which level can someone choose to enter the management track, and what is required to do so?

If your job family has natural lateral paths — design into product, engineering into data, support into customer success — document those too. Each lateral path should name the transferable skills and the gaps that need to close.

Step 7: Validate, publish, and connect to reviews

Before publishing, review the framework with 3–5 experienced managers and 3–5 senior ICs. Check that the level boundaries feel right (L2 vs L3 is a meaningful distinction, not a paperwork difference), that the behavioral descriptions are actually observable, and that your current team maps sensibly to levels.

Then publish it — not just to managers, but to all employees. And integrate it into your next review cycle as the evaluation rubric. Without that integration step, the framework will not survive contact with reality.

IC vs. manager dual-track design

The biggest structural decision in a career progression framework is whether and how to separate the IC and management tracks. The failure mode is a framework where the management track starts at L4 and there are only two IC levels above L3 — which implicitly signals that serious career growth requires becoming a manager.

A well-designed dual-track framework has:

  • Equivalent prestige. The top IC level (Staff, Principal, Distinguished) and the top management level (VP, Director) should be treated as equivalent in compensation band and organizational status. If they are not, you have a framework on paper and a management ladder in practice.
  • A defined crossover point. Clearly state at which level the management track branches off, and what the criteria are to enter it. Common: M1 (engineering manager) requires demonstrated operating at L3 IC, plus explicit leadership competencies.
  • Two-way movement. Allow people managers to transition back to the IC track without penalty. This is rarely used, but its existence signals that management is a choice, not a one-way door.

Career progression framework examples by size and function

Context Levels Track approach Notes
Early-stage startup (10–50) 3–4 levels Single IC track only Speed matters more than completeness; build the management track when you hit 3+ managers
Growth-stage (50–200) 5–6 levels Dual IC + management, brief lateral paths This is where most promotion frustration shows up — the framework becomes urgent
Mid-size (200–1,000) 6–7 levels Full dual track, documented lateral paths Calibration consistency becomes critical — framework must be specific enough to prevent manager drift
Engineering function IC1–IC7 + M1–M4 Strong IC track parity with management Engineers care most about IC track depth — see our engineering career ladder guide
Sales function 4–5 levels IC track with quota-based criteria + management Promotion criteria often tied to consistent quota attainment + deal complexity
People / HR function 4–5 levels Often smaller team; single track common early HR rarely builds frameworks for their own team first — a credibility gap worth addressing

Free career progression framework template

To get started immediately, download our free competency matrix template — it includes a role × competency grid with 1–5 proficiency scales, gap analysis, and an engineering team example. Use it as the operational layer of your framework.

For the overall framework structure (level definitions, promotion criteria, track branching), the template works best alongside the competency framework how-to guide, which walks through validation and rollout in more detail.

Once you have a framework, Harmny's competency framework tool moves it from a spreadsheet into a live system — employee ratings update against the framework in every review cycle, career gaps are visible to both managers and employees, and promotion readiness is tracked continuously rather than reassessed from scratch each cycle.

Frequently asked questions

What is the difference between a career progression framework and a career ladder?
A career ladder is a visual representation of levels within one job family — the rungs from junior to senior. A career progression framework is the full system: the ladder structure plus the competency definitions, behavioral descriptions, promotion criteria, and multiple career tracks. A career ladder is one component within a career progression framework. You need the framework for the ladder to function as a genuine development tool rather than just a title chart.
How many levels should a career progression framework have?
For most job families at growth-stage and mid-size companies, 5–7 levels strikes the right balance. Fewer than 4 levels creates long promotion gaps that frustrate early-career employees; more than 7 creates false granularity that makes calibration harder without adding clarity. Engineering and technical functions often benefit from more levels (IC1–IC7 is common) because technical depth compounds in ways that justify fine-grained differentiation. Non-technical functions can usually manage with 4–5 levels.
How often should a career progression framework be updated?
Annual review is the minimum; a two-year review cycle is reasonable for stable job families. The triggers for an off-cycle review are: the organization's strategy has meaningfully changed (what success requires at L3 Engineering is different now than it was), a job family has restructured significantly, or manager feedback suggests the criteria have drifted from what the team actually values. Small wording updates to behavioral descriptions should not require a full framework revision — those can be iterated continuously. Major structural changes (adding a level, splitting a track) should go through a deliberate process with manager input.
Who owns the career progression framework — HR or managers?
HR owns the structure, consistency, and tooling. Managers own the content within their domain. A framework that HR writes in isolation and hands to managers tends to not get used — the criteria feel abstract and disconnected from how the work actually runs. A framework that managers write without HR tends to drift, become inconsistent across teams, and resist calibration. The right model: HR provides the template and process, experienced managers in each job family write the behavioral descriptions, and HR ensures consistency before publishing. Treat it as a co-authorship.
Should career levels match job titles?
Ideally yes — each level in the framework maps to one external job title, so the title is a reliable signal of the employee's career stage. In practice, many organizations have title inflation from past promotion cycles and cannot cleanly enforce a one-to-one mapping. The pragmatic approach: use the internal framework levels (L1–L5) as the canonical reference for all compensation and development decisions, and allow some title variation externally for market-facing roles. Do not let title inconsistency prevent you from building the framework — the framework governs how people are developed and compensated, independent of the title printed on a business card.