How to build a career ladder: a step-by-step guide

A career ladder answers the question every growing team eventually asks: what do I need to do to get to the next level? In a company of 15 people the founders can answer it in a conversation. At 40 or 80 people, with several managers and more than one department, the answers start to differ from manager to manager — and people notice.

This guide is for companies of roughly 20 to 200 people that want a career ladder without a dedicated HR team. It works for engineering, sales, support, product, design and operations alike. You will go through seven steps, see a worked example, and get a list of the mistakes that most often turn a good ladder into a document nobody opens.

What a career ladder is, and what it is not

A career ladder is a sequence of roles within one line of work, ordered by level, with a clear description of what is expected at each step. "Support Associate Support Specialist Senior Specialist Support Lead" is a ladder. When you put several ladders side by side for one department — for example an individual-contributor track next to a management track — and add the competencies each role is measured on, you have a career framework.

The vocabulary used in this guide:

• Department — a group with its own ladder: Engineering, Sales, Customer Support.
• Track — one path within a department, such as individual contributor or people management.
• Level — a step on a track, comparable across tracks: level 3 in one track is roughly as senior as level 3 in the other.
• Role — the job at a given level on a given track: "Senior Account Executive".
• Competency — an area people are assessed on, such as communication or technical depth. Each competency is described separately for every level.

A career ladder is not a list of job titles, and it is not a pay scale. Titles say what someone is called; the ladder says what they are expected to do. Pay can be linked to it later, but a ladder that starts with salary bands tends to become a negotiation tool rather than a development tool.

Before you start: scope and owners

Three decisions save weeks later.

Start with one department. Pick the one where the question "how do I grow here?" comes up most often — usually the largest team or the one hiring fastest. Building every department at once spreads the effort thin and delays the moment anyone benefits.

Name the owners. The department head owns the content. One or two experienced people from the team help write it, because they know what the work really looks like at each level. One senior person — often the CEO, CTO or COO — owns the overall structure so that levels mean the same thing across departments.

Decide what the first version is for. A ladder that is only used during promotion decisions gets opened twice a year. A ladder that structures regular career conversations gets opened every month. Decide now that it will be used for both, because that shapes how you write the expectations.

Step 1: Map the roles you already have

Before designing anything, write down what exists. List every person in the department with their current title, who they report to, and roughly what they do. Then group people who do similar work at similar scope.

You will usually find three things:

1. Title inflation in places. Someone hired as "Senior" at a time when there were only three people, who now works at the same scope as colleagues without the word in their title.
2. Gaps. Nobody between the most junior people and the team lead, which means there is nowhere to grow without becoming a manager.
3. Hidden tracks. A person who is clearly the go-to expert but has no reports, sitting next to a manager who has reports but less expertise. Those are two different paths.

Do not fix anything yet. The inventory is the raw material for the next steps, and it will be your test data: when the ladder is drafted, every person on this list should fit somewhere that feels right to them and to their manager.

Step 2: Choose your tracks

Most departments of 20 people or more need two tracks:

• An individual-contributor track, for people who grow by deepening their expertise and widening their impact without managing people.
• A management track, for people who grow by leading a team.

The point of two tracks is that nobody should have to become a manager to be promoted. Your strongest specialist may be a poor manager and an unhappy one; a separate track lets them keep growing.

Make the tracks comparable: a level on one track should carry similar scope, influence and pay to the same level on the other. A common pattern is that the management track starts one or two levels up, because a first-time manager has usually been a solid senior individual contributor first.

Smaller departments — a five-person support team, say — can start with a single track and add the second when the first manager is appointed.

Step 3: Decide how many levels

Fewer levels than you think. Each level must describe a real, observable difference in what someone does. If you cannot write two sentences explaining how level 4 differs from level 3, you have one level, not two.

Too few levels and people wait three years for a promotion, which feels like no progress at all. Too many and the differences between levels become wording games that managers apply inconsistently.

Name levels neutrally. Numbers (L1–L5) or short labels work better than inventive names. Keep job titles separate if you need them for the market — a "Senior Account Executive" can sit at level 3 without the title changing every time the ladder does.

Step 4: Pick five to eight competencies

Competencies are the rows of your framework: the areas in which you describe each level. Aim for five to eight per department. Fewer, and important parts of the job go unmentioned; more, and every review turns into a long checklist.

Mix two kinds:

• Shared competencies that apply across the company — communication, ownership, collaboration, helping others grow. Write them once and reuse them in every department.
• Department-specific competencies that describe the craft itself.

Examples by department:

• Engineering: technical depth, system design, code quality and review, delivery, operational ownership.
• Sales: pipeline building, discovery, negotiation and closing, forecasting, account growth.
• Customer support: resolving issues, product knowledge, written communication, process improvement, customer advocacy.

If you are unsure where to start, a ready-made set is faster than a blank page: the software engineer, customer support and account executive templates each come with levels and competencies you can adapt.

Step 5: Write the expectations for every level

This is the core of the work, and where most ladders succeed or fail. For every competency, write what someone at each level actually does. Three rules make the difference.

Describe behaviour, not adjectives. "Strong communicator" means nothing until you say what a strong communicator does. Compare:

• Weak: "Excellent written communication."
• Useful: "Writes customer replies that resolve the issue in one message in most cases, and drafts help-centre articles that others can publish with light edits."

Show scope growing. The same competency should widen in reach from level to level: from one's own tasks, to the team, to several teams, to the department.

Keep every level self-contained. Each cell should make sense on its own, without "as above, but more".

Here is one competency, written for four levels of a customer support ladder:

Write the first draft quickly and in the team's own words, then review it with two or three people at different levels. Ask them one question: "Reading your level, do you recognise your job?"

Step 6: Place people and calibrate

Take the inventory from step 1 and place every person at a level on a track. Each manager does this for their own team first, then the managers meet for a calibration session: one or two hours where you compare placements across teams and ask "is this person really at the same level as that one?"

Calibration is where inconsistencies surface — the generous manager, the strict one, the person whose title promised more than their work shows. Settle them before anyone sees the result.

When someone lands lower than their current title suggests, do not demote them on the spot. Explain the new structure, show them what the level above asks for, and agree on how they will get there. Keeping existing titles for a transition period is usually kinder and costs nothing.

Step 7: Publish it and put it to work

Publish the ladder to the whole department, not just to managers. Hold a short session to walk through it: why it exists, how levels and tracks work, how promotions will be decided from now on. Then make it part of how the team works, or it will be forgotten within a quarter:

• Career conversations. Run regular check-ins in which each person assesses themselves against the expectations for their role and the manager does the same. The gaps between the two are the agenda.
• Development plans. Turn the gaps into a few concrete actions with due dates, rather than a vague "improve stakeholder management".
• Promotions. Ask the manager to write a promotion case that points at the expectations of the target level, and have someone above them decide. The ladder becomes the shared reference for the decision.

This is the workflow LadderKit is built around: each department gets its own career ladder with tracks, levels and roles, kept in draft until you publish it; the skills matrix sets the level each role expects; check-ins are pre-filled with exactly those skills; and promotions go through a written case and a decision by the reporting line.

A worked example: a 60-person software company

Consider a company of 60 people: 25 in engineering, 12 in sales, 8 in customer support, and the rest in product, design, marketing and operations.

Order. They start with engineering, where three senior engineers have asked how to grow without managing. Sales follows a quarter later; support after that.

Engineering tracks and levels. Two tracks and five levels on the individual-contributor track. The management track starts at level 3.

Competencies. Six for engineering, as in the software engineer template: technical delivery, system design, quality and reliability, collaboration and communication, ownership and product impact, and mentoring and team growth. The last one is shared with every other department.

Placement. Of 25 engineers, 22 land where everyone expected. Two people titled "Senior" land on level 2; each agrees a plan with their manager and keeps the title for six months. One engineer who has been leading most technical decisions without a title moves to level 4 — the first visible promotion under the new ladder.

Rollout. The ladder is published in week four. Every engineer has a first check-in against it within two months, and each check-in ends with two or three growth actions.

Sales, a quarter later, reuses the shared competencies and the five-level structure, adds its own four craft competencies and a single management level, and is ready in two weeks instead of four.

Common mistakes

• Copying a big-tech ladder wholesale. A ladder written for a 5,000-person company describes scope that does not exist in yours. Use it for ideas, then rewrite in your own terms.
• Too many levels. If the difference between two levels is one adjective, merge them.
• Adjectives instead of behaviour. "Excellent", "strong" and "proactive" are judged differently by every manager.
• Only one way up. Without an individual-contributor track, you will promote good specialists into management to keep them, and lose some of them anyway.
• Writing it alone. A ladder written by one person in a weekend reads like one person's opinion. Involve people at different levels.
• Publishing and walking away. If the ladder is not used in check-ins and promotion decisions, people stop believing in it.
• Starting with money. Pay ranges invite negotiation about the boundaries. Settle the expectations first.

Keep it alive

A career ladder is never finished. Review it once a year, and whenever a new kind of role appears or a department reorganises. Keep a short changelog: what changed, why, and from when it applies, so that a check-in held in March is not judged against a level description written in October.

Small, frequent corrections beat big rewrites. If the same expectation is misread in three check-ins, rewrite that one cell — do not wait for the annual review.

Where to go from here

If you are starting from scratch, pick the template closest to your largest department and adapt it: the software engineer and engineering manager templates cover both tracks of a typical engineering department.

If your levels already live in a spreadsheet, that is a fine place to start: move only when keeping the ladder, the check-ins and the promotion cases in step by hand starts to cost you. And if you want the ladder, check-ins, growth actions and promotions in one place, you can start LadderKit on the free plan with your first department.