Job Families Are Pay Architecture, Not a Skills Ontology

Panic begins with the request for a skills ontology that will also, somehow, fix internal mobility.

Fine.

Great.

An ontology.

A thing famously assembled between the compensation-calibration meeting and lunch.

Somebody opens Job_Architecture_Master_FINAL_v9_USE_THIS_ONE.xlsx.

There are family codes.

There are levels.

There are pay grades.

And there is a column called skills, containing phrases contributed over several years by conscientious people who were trying to get a system live.

Then somebody asks whether a Systems Infrastructure employee who has demonstrated software-design capability can move into a Software Engineering role.

The spreadsheet replies: no, because the skill belongs to the wrong family.

This is not an argument for throwing away job families.

It is an argument for remembering what they are.

A job family is pay architecture. A skill taxonomy is capability architecture.

They meet constantly.

They should not become the same object.

The family has a proper job

A job architecture needs a way to make similar employment decisions consistently.

A Job Profile can carry a primary key like JP_88301, a Job Family ID like JF_FIN_FPA, a family-group ID, a management level, a default pay-grade identifier and a job-description object.

That is not bureaucracy for its own sake.

It tells you which job is being priced, managed and compared.

One family commonly connects six to twelve profiles across its seniority tiers. The parent-child structure stops a profile floating through the HRIS without a family or a functional owner.

It also connects the profile to a salary structure, to regulatory attributes, and to an external survey benchmark.

Useful work.

Particularly useful when somebody asks whether two roles merit similar pay, whether a new role has an accountable owner, or whether a survey match is plausible at all.

Nobody wants compensation determined by whoever named the requisition at 1:14 a.m.

So keep the family.

Keep the level.

Keep the pay grade.

Keep the survey code.

These are institutional controls for an institution with payroll, managers and reporting lines.

They are not a complete inventory of what an employee can do.

The same work walks across the corridors

The practical reason is visible inside any technology function.

Software Engineering owns production application code and business logic. Its people spend at least 70 percent of working time designing, writing, testing and reviewing that code.

Systems Infrastructure and site reliability own runtime reliability, automation tooling and deployment platforms, sometimes against availability targets above 99.9 percent.

Data Science and Analytics work with statistical inference, models and pipelines, with most of the effort in modelling, feature engineering, exploratory analysis and mathematical validation.

Those distinctions matter.

A family has to describe its primary deliverables and evaluate them coherently.

Production features, a runtime platform and a predictive model are not interchangeable deliverables because their builders all write code before coffee.

But shared capability is not an error in the model.

A skills architecture can connect secure software development, systems thinking, data engineering, communication or risk judgement to roles in more than one family. It should state the required autonomy, complexity and scope for each relationship.

It can say that a role requires a capability.

It should not imply that the capability can only exist there.

Otherwise a person who solved the destination problem from a neighbouring family becomes a reported gap.

Nothing happened to the person.

The taxonomy did the excluding.

The architecture is load-bearing, which is the difficulty

The case for families is stronger than a tidy org chart.

Product Management, Technical Programme Management and Business Analysis partition genuinely different responsibilities.

Product direction.

Cross-functional execution.

Requirements work.

Their staffing ratios differ by roughly a factor of five, which is a sign that they are different operating models rather than decorative nouns.

Corporate Accounting has a different purpose again.

Record-keeping, reconciliations and statutory reporting, with monthly and quarterly closes landing within three to five business days after the period ends.

Financial planning and analysis models forward-looking plans.

Corporate development handles transactions.

A sensible employer does not call those distinctions optional because a skills graph exists.

Nor does a family make an employee’s evidence worthless.

It gives that evidence a job context, a level, and a compensation home.

The failure starts when the home address becomes the biography.

The outside taxonomies are not family dictionaries

This gets more obvious the moment you reach for a standard.

A public occupational classification is a broad architecture for describing work across a labour market. It is not a table of one employer’s pay bands.

A multilingual European classification relates skills to occupations as essential or optional. A technology-capability framework crosses skills with levels of responsibility, defined through autonomy, influence, complexity, business skills and knowledge. A market-facing library detects the language employers are using, on a fortnightly release cycle.

Each of those is useful telemetry.

None of them is an internal job architecture, and none is a compensation grade with a nicer API.

They are useful precisely because they answer different questions.

Pretending one is a universal replacement is how an HRIS ends up believing that a family code is a skill, a market signal is a requirement, and a display title is a labour-market truth.

Your architecture is not a dictionary, and your dictionary is not your architecture.

Store the things separately

The practical design is dull, which is reassuring.

Start with a canonical role.

An internal definition of the work, its expected outcomes, its scope, its family, its level, and its relationship to neighbouring roles.

Give it an identifier that is not the display title.

A title can stay useful local metadata.

The role is the stable reference.

Keep the family and level definitions versioned.

Store the effective definition a historical profile used, rather than overwriting it when the family changes. Attach the pay grade and the survey benchmark to the profile, where they belong.

Then maintain skills as their own records.

Attach a role to a skill through a relationship.

Required.

Relevant.

Developmental.

With an expected level of autonomy, complexity and scope.

Do not make a skill’s parent family the only place it can be recognised.

The relationship is what needs governance.

Exclusivity is usually an accidental data-model decision that nobody intended and everybody inherited.

Record the evidence separately again.

A project, an assessment or a validated work outcome can support a capability claim, without turning either the project name or the family code into the capability itself.

Then the mobility question can be asked honestly.

Does this person have evidence for the destination capability, at the required scope?

Rather than the easier and much less useful question. Was this person’s last Job Profile filed under the approved noun?

Then the model reads the family code

Job families emerged inside employers.

Occupation systems emerged inside labour markets.

Capability frameworks emerged inside professions.

Market libraries emerged from job postings.

Then organisations put all of them beside employee records and asked a model to recommend learning, identify candidates and plan moves.

The model sees the family, the level, the grade and the title, because those fields are tidy.

It sees a map from one role to a handful of skills, and reasonably infers that the map is exclusive.

That is not a model failure.

That is an exclusivity nobody designed, arriving in a very confident user interface.

So before you automate mobility, audit the job-to-skill inferences.

Test the source taxonomy edition.

Check whether a code or a title changed between versions.

Check whether a mapping is many-to-one.

Check whether a source occupation has descriptor data at all, or is a title-only entry.

And check whether the evidence came from demonstrated work, or merely from the family label.

The audit may find a real gap.

Good.

That is what learning plans are for.

It may also find that your system excluded somebody because two family codes were treated as rival continents.

Also useful to know, before the model sends the rejection.

Two architectures, one workforce

Job families make jobs legible inside an employer.

Skill taxonomies make capability legible across contexts.

A mature system needs both, along with titles, credentials and other evidence.

The durable object is demonstrated capability, at a stated autonomy, complexity and scope.

The family-and-level label is the institutional wrapper that helps you organise pay, reporting and careers.

Two architectures.

Neither one is a substitute for the other.

And if the spreadsheet says otherwise, the spreadsheet has been asked to do too much.