Job title
Career Paths Break When Level Is Confused With Capability
A progression ladder needs levels; it also needs a way to recognise capability acquired sideways. Otherwise the path becomes a record of prior titles rather than potential work.
What the wrapper says
Career paths sequence possible moves, while job families supply local levels and role groupings that can be confused with the capabilities required for the move.
The all-clear
Career frameworks and levels make expectations, advancement decisions, pay architecture, and accountability more transparent.
What is durable
Evidence that a person can perform the destination work at its required scope and responsibility.
Your arrows run from IC1 to IC2, and IC2 to IC3, and, in a separate shade of blue, “aspirational lateral movement.”
All of it inside Career_Pathways_FINAL_actually_final.xlsx.
The arrows are very clean.
The people are less obliging.
One of your employees runs a runtime platform.
She has built deployment automation, handled incidents, made architectural decisions across teams, and inherited a service with a changing cast of owners and no documentation.
A software-engineering opening appears.
Your internal marketplace says she is not eligible, because she has never held Senior Software Engineer.
That is an impressively efficient way to confuse a predecessor label with the ability to do the destination work.
A level is an institutional claim about progression. Capability is evidence that the next work can be performed.
They meet in a career path.
They should not be merged there.
The ladder has a proper job
A six-tier individual-contributor track can run from Associate Engineer through Professional, Senior, Staff and Principal to Distinguished Fellow.
Alongside it, a managerial track runs from Team Lead to Vice President.
That arrangement answers useful institutional questions.
It creates visible progression without telling your capable technical people that management is the only respectable outcome.
It gives compensation, promotion and succession planning a shared frame.
It also ends the annual debate about whether a Staff Engineer is “sort of a manager, but not in a difficult way.”
Technical review committees are the serious version of the same discipline.
Senior fellows and domain experts convene twice a year to assess promotion portfolios independently of the candidate’s own management line.
Principal Engineer candidates get evaluated against standardised impact rubrics.
Cross-organisational architectural impact.
External technical leadership.
Authorship of five to ten core patents or major open-source repositories.
That is a framework doing its job.
It makes the bar visible, and it puts evidence in front of reviewers.
None of it is accidental paperwork.
It is job architecture: a method for making employment decisions consistently inside one employer.
The problem starts when IC2 to IC3 to IC4 gets read as a list of universal capability dependencies.
It is not.
It is a local route through a local structure, calibrated by people who knew your organisation, its grades, its work, and possibly the person who authored the original framework in PowerPoint_final_approved.pptx.
That route can be good evidence.
It cannot be the whole test.
A predecessor title is not a capability threshold
The error would be to turn the committee’s eventual title into the evidence the committee reviewed.
An IC5 title earned in one organisation signals a stringent portfolio, a particular pay structure, a particular review process, and a particular set of local opportunities.
It does not automatically express every task required by another organisation’s IC5 role.
Adjacent disciplines make this painfully practical.
Software engineering owns production application code and business logic.
Site reliability owns availability, scalability, security and runtime environments, against service-level objectives measured in nines.
Those are different primary deliverables.
A production feature is not a deployment platform with a better logo.
Data science has another kind of evidence again.
Statistical inference.
Machine-learning models.
Pipelines.
Defensible causal claims from a data set.
So “Senior” cannot be the threshold.
It tells a useful story about one employer’s level calibration.
It does not say whether the person has designed production software, operated a high-availability runtime, or validated a model.
Seniority and task scope are related. They are not synonyms.
The compensation world worked this out years ago, because title matching burned it.
The WorldatWork 80 percent content-match rule permits a formal survey match only when an internal role matches at least 80 percent of the external benchmark’s core accountabilities, technical scope and required capabilities.
Identical titles can mean wildly different jobs.
So a content test is required.
Internal mobility deserves the same intellectual hygiene.
For each destination role, define your capability threshold in the work itself.
The task.
The expected outcome.
The autonomy.
The complexity.
The decision rights.
The conditions.
Then say what evidence qualifies for it.
A role sequence can remain useful evidence.
It does not get to be the only evidence because it fits in a dropdown.
Lattices are where sideways evidence becomes visible
A ladder describes vertical progression through a role or discipline.
A lattice describes lateral and diagonal moves that create new evidence across functions, projects and adjacent roles.
Calling both a “career path” is convenient right up until you treat every sideways move as a pause in the real career.
Someone who handles an infrastructure migration can demonstrate systems thinking, risk judgment, technical leadership and delivery under operational constraint.
Someone who moves from business analysis into product management can demonstrate part of the destination work through customer research, prioritisation and accountable outcomes.
That evidence will not always clear the destination threshold.
Which is why a threshold exists.
But your system should be able to see the evidence before it declares a gap.
Staffing ratios offer a small warning against title arithmetic.
A product manager typically supports five to eight engineers.
A technical programme manager can support twenty-five to forty.
Both work near product delivery.
Their operating leverage and accountability are not the same.
So a lateral path has to name the capability being tested, rather than announce that a nearby title is “basically the next role.”
A profile describes a position. Evidence describes a person.
This is a data-model problem wearing a development-programme lanyard.
The Position Analysis Questionnaire is a useful reminder that a job can be described in more than a title.
It carries 194 job elements across six divisions: information input, mental processes, work output, relationships with other people, job context, and other job characteristics.
Evaluators rate each on a six-point scale, from does-not-apply to extreme importance.
The questionnaire is not an internal-mobility oracle.
It is evidence that task analysis has dimensions.
Your destination profile can do the same.
Identify what work matters, what judgment it requires, what relationships it entails, and under what conditions it happens.
Then the person record holds projects, assessments and validated outcomes against those dimensions.
The profile and the person are not interchangeable records.
Nor are the title, the family, the level and the pay grade.
Store each with its definition and version.
A change to a family code or a display title should not rewrite a prior mobility decision.
Any more than a renamed folder turns a completed project into a different project.
Sometimes the next rung does not exist
Career ladders also fail when the organisation has removed the ladder.
Your framework promising orderly vertical movement after a restructuring is mostly decorative infrastructure.
Smaller employers face the same arithmetic without the reorganisation memo. There simply are not many senior openings, and no amount of tasteful competency-card design creates one.
That is not a reason to abandon career development.
It is a reason to stop selling title sequences as the only development story.
When vertical moves are scarce, lateral projects, rotations, scoped assignments, mentoring and externally portable evidence all matter more.
Your durable question stays the same throughout.
Has this person demonstrated the destination capability, at the required scope and responsibility?
AI learns the route and mistakes it for the work
Career-path algorithms train on what you already record.
Titles, families, levels, promotion dates, managers, and a few fields extracted from performance documents.
That is convenient because the records are tidy.
Not because they are complete.
The model sees that past IC4s usually held IC3 in the same family. It sees that a given staff role follows a familiar internal road.
Then it learns that the road is a requirement, rather than a pattern your own structure produced.
Now a person arrives with the right project evidence, from infrastructure, from business analysis, from another employer entirely.
The model treats the unfamiliar history as a deficiency.
It has reproduced local promotion routes as universal capability dependencies.
At speed.
In a very helpful interface.
The control is straightforward, if not glamorous.
A mobility recommendation keeps the destination role version, the capability threshold, the evidence type, the task scope, the source family, the source title and the decision rationale.
It distinguishes evidence from context.
It records when a reviewer accepts or rejects a move, and why.
Then monitor for title-history bias.
Compare recommendations and exclusions for people who meet the same destination threshold, but who arrived through different families, titles, projects and prior employers.
If the model consistently favours the dominant predecessor title after equivalent evidence is present, it has learned your org chart rather than the work.
That finding is not an indictment of the people who built the ladder.
It is an instruction to stop asking the ladder to be a lattice, an assessment, and a universal theory of human potential.
The level can stay what it is: a transparent local promise about progression.
The capability threshold decides whether the next work is possible.
What the record establishes
- Model vertical ladders and lateral career lattices as separate mobility mechanisms.
- State destination capability thresholds in tasks, scope, autonomy, complexity, and outcomes rather than predecessor titles.
- Recognise project work, rotations, assessments, and validated outcomes as lateral evidence for a move.
- Distinguish a local seniority level from the task scope and responsibility required by a destination role.
- Keep job-family, level, title, pay-grade, and capability records distinct and versioned.
- Use content matching rather than title matching when comparing roles and calibrating mobility decisions.
- Monitor title-history bias when mobility models learn from prior promotion routes.
Asked in the review
- Is a career ladder the same thing as a career lattice?
- No. A career ladder sequences vertical moves through levels in one role or discipline. A career lattice includes lateral or diagonal moves that build capability across functions, projects, or adjacent roles. An Internal Talent Marketplace supports lattice movement by matching employees to cross-functional projects and short-term gigs without necessarily changing the primary reporting relationship. A workforce system needs both models because a useful lateral assignment is not a failed promotion.
- Does someone need the previous title before moving into the next role?
- No. A predecessor title is local evidence of a prior employer's progression and calibration process; it is not proof that a person lacks the destination capability. A move should test whether documented work, assessment, project outcomes, and demonstrated judgment meet the destination role's required scope and responsibility. The title remains useful context, but it does not become an eligibility gate by itself.
- What should a capability threshold for a career move actually say?
- A capability threshold states the destination work, expected outcomes, required autonomy, complexity, scope, and evidence needed for a decision. A software-engineering role can require production-code design, writing, testing, and review; a systems-infrastructure role can require reliability, automation tooling, and platform operation. A threshold describes the work to be performed, rather than assuming that a local level label carries the same meaning across job families.
- What counts as lateral evidence for a move?
- Lateral evidence can include a completed cross-functional project, a rotational assignment, an assessment, a validated work outcome, or documented work in an adjacent role. Internal Talent Marketplaces commonly make this evidence visible through approved project gigs lasting 3 to 6 months, with staff allocating 10 to 20 percent of contracted time while retaining the primary manager. The evidence needs its task, scope, outcome, and review context recorded.
- Why is a senior title not enough to show that someone can do the destination job?
- A senior title is a local seniority label, while destination work has specific deliverables and operating conditions. Software Engineering focuses on production application code; Systems Infrastructure and SRE focus on runtime reliability, automation, and deployment platforms; Data Science and Analytics focus on statistical inference, models, and data pipelines. Similar seniority labels across those families do not establish equivalent task scope, responsibility, or demonstrated capability.
- Are levels and career frameworks still worth keeping?
- Yes. Levels and career frameworks make expectations, pay decisions, progression criteria, reporting relationships, and accountability more transparent. A Job Profile can store a job-family identifier, management level, default pay grade, and job-description object, and a family commonly links 6 to 12 progressive profiles. The framework becomes misleading only when its local level or family code is treated as a complete record of individual capability.
- How should an organisation compare a lateral candidate with a destination role?
- An organisation compares the content of the candidate's demonstrated work with the destination role's core accountabilities, technical scope, and required capabilities. The corpus's WorldatWork guidance uses an 80 percent content-match rule for formal external survey benchmarking, explicitly rejecting title-only matching. The same discipline makes mobility decisions more defensible: a label can prompt review, but the work content supplies the decision evidence.
- What does a Technical Review Committee add to a technical career path?
- A Technical Review Committee provides independent review of technical promotion portfolios by senior technical fellows and domain experts rather than relying only on a direct functional supervisor. In the corpus's six-tier individual-contributor model, committees convene bi-annually, and Principal Engineer candidates are evaluated against standardized impact rubrics covering external technical leadership and cross-organizational architectural impact. The committee evaluates evidence; it does not make a title the evidence.
- What should remain separate in the HRIS when a person changes roles?
- The HRIS should keep the Job Profile, job family, level, display title, pay grade, job-description object, capability record, and evidence record as separate objects. The profile describes the organisational position; the evidence record describes what a person demonstrates. Versioning the family and level definitions preserves the meaning used at the time of a decision and prevents a later relabelling from rewriting mobility history.
- Why do flat organisations need lateral paths more than tidy promotion charts?
- Flat organisations lose the intermediate rungs that make vertical promotion charts work. The corpus describes restructurings that remove 30 to 50 percent of middle-management positions and expand spans of control from 1:5 to 1:15 or higher. A lattice of projects, rotations, and adjacent capability moves gives development somewhere to go when the next managerial or specialist title does not exist.
- Can a small employer promise the same ladder as a large enterprise?
- Usually not. The corpus describes formal dual ladders and deep internal labour markets as scale-dependent: an enterprise with fewer than 100 employees has only low-single-digit senior leadership or technical-fellow openings over a 5-year horizon. A small employer can still define capability expectations and developmental assignments, but it should not represent a rare vacancy as a predictable sequence of title moves.
- How does a mobility model learn title-history bias?
- A mobility model learns title-history bias when historical promotion routes are used as labels for capability requirements. If most successful moves into a role previously came from one family or predecessor title, the model can treat that local route as a universal dependency. Monitoring should compare recommendations and exclusions against destination-capability evidence, source family, title history, level definition, and project evidence so that a familiar path does not become an invisible eligibility rule.