Career paths and competency frameworks: answering "how do I progress here?
How to define competency levels and make career paths visible. Development goals, promotion criteria and how this differs from performance reviews.
Among the reasons people leave a company, one follows immediately after pay: progression isn't visible. If someone doesn't know what they have to do to reach the next level, the only place they can find out is the job market.
A competency framework exists to remove that uncertainty — not to guarantee promotion, but to make the criteria visible.
What is a competency framework?
A framework has two axes: competencies (what someone is expected to know or do) and levels (how that expectation changes at each step).
Take "problem solving": at level one you solve defined problems, at level two you define the problem yourself, at level three you enable others to solve it, at level four you build the system that stops the problem occurring.
Once that table is written, what emerges is less an assessment tool than a shared language. Manager and employee start using the same words to mean the same thing.
Who should write it?
The most common mistake is HR writing the framework alone. The result is generic text that fits everyone and helps no one.
What works is each function writing its own framework with its own practitioners. A software team's technical competencies won't match a sales team's. The only thing that must stay common is the number and naming of levels, so comparison across functions remains possible.
How many levels? Four or five is enough for most companies. Eight-level frameworks look detailed on paper; in practice the difference between two adjacent levels becomes impossible to explain.
Specialist and management tracks
Making management the only route to promotion is the classic mistake that turns good specialists into poor managers. A healthy framework has two parallel tracks: expertise and management. Having both at the same level and in the same pay band is the only evidence that the distinction is real.
Switching tracks must also be possible; moving from management back to expertise should be a choice, not a failure.
Development goals
A framework alone isn't enough; what the person will do on the way to the next level has to be written. That's where a development goal comes in, and it differs from an OKR: an OKR concerns the outcome of work, a development goal concerns the person's capability.
A good development goal has three parts: which competency, through which concrete piece of work, in what timeframe. "Improve communication" isn't a goal; "run two team meetings next quarter" is.
Keeping the two apart is worthwhile — we cover the reasoning in our OKR article.
How it differs from a performance review
These are frequently confused. A performance review looks backwards: what was delivered this period? A competency assessment looks at the present: at what level is this person working?
The first feeds bonus and pay decisions; the second feeds promotion and development decisions. In companies that merge them into one form, the development conversation usually disappears — everyone focuses on the money.
A practical suggestion: separate the two conversations in the calendar. Even in the same month, separate sessions produce separate conversations.
The limit of transparency
The competency framework should be fully open to everyone — who sits at which level should not be. Open criteria and private assessments is the right balance.
It is enough for the person, their manager and HR to see an individual assessment. That restriction must be enforced in the data layer; performance and career data is among the most sensitive information in an intranet.
Self-assessment
Having the employee also complete the competency assessment markedly improves the quality of the conversation. The gap between the two assessments gives you the agenda directly: if someone rates themselves above their manager, there is an expectation gap; below, there is usually invisible contribution.
The gap itself isn't the problem; not discussing it is.
Measurement
- Framework coverage — how many functions have a defined framework?
- Development goal rate — what share of employees has a current development goal?
- Internal promotion rate — how many open roles were filled from within?
The last is the only external indicator that the framework actually works. We cover internal postings and applications in our jobs article, and the learning side in our training article.