Job Families: How to Define and Use Them

Job Families: How to Define and Use Them

Most job family projects fail the same way. Someone exports the HRIS job list, sorts it by department, renames each department a "family," and calls it architecture. Six months later a data engineer in Marketing sits in a different family than a data engineer in Finance, the two are paid $22,000 apart, and nobody can explain why. The families described the org chart, not the work.

A job family is a grouping of jobs that share the same kind of work and the same core skill set, regardless of who they report to. Done well, families are the layer that makes everything above them cheap: leveling, pay ranges, career paths, market matching, and pay-gap reporting all inherit their structure from the family design. Done badly, every one of those downstream jobs gets harder. Here's how to build families that hold up.

TL;DR

• A job family groups jobs by type of work and core skills — not by department, manager, or location.
• Most organizations need far fewer families than they think. Under 1,000 employees, 8–15 families is usually right; sub-families handle the nuance.
• Families are horizontal. Levels are vertical. Keep them as separate dimensions or your matrix collapses.
• Test every family against one question: would you expect these jobs to be scored on the same compensable factors, and to compete in the same talent market?
• Families organize jobs. They do not tell you what a job is worth — that comes from job evaluation and market data.

What a job family actually is

A job family is a set of jobs that involve substantially similar work, draw on the same body of knowledge, and progress along a recognizable path. A Software Engineer I, a Senior Software Engineer, and a Principal Engineer belong to one family. So do a Payroll Specialist and a Senior Payroll Analyst. A Software Engineer and a Payroll Analyst do not, even if they sit on the same floor and report to the same VP.

Three tests separate a real family from a relabeled department:

1. Shared work content. The jobs solve the same class of problem with the same tools and methods.
1. Shared skill base. Someone in the family could plausibly move to another job in that family with development, not retraining.
1. Shared market. You would benchmark these jobs against the same survey families and compete for them against the same employers.

Notice what's missing: reporting line, cost center, and geography. Those change constantly. Work content changes slowly. Build the structure on the slow-moving thing.

The national statistical agencies model this well. The U.S. Bureau of Labor Statistics 2018 Standard Occupational Classification sorts every job in the American economy into 867 detailed occupations, which roll up into 459 broad occupations, 98 minor groups, and just 23 major groups. An entire economy compresses to 23 top-level buckets. If your 600-person company has 40 job families, you have not built a taxonomy — you have built a list.

Family, sub-family, job, level: keep the layers straight

Four terms get used interchangeably and shouldn't be.

Family and sub-family are horizontal — they describe type. Level is vertical — it describes magnitude. When teams merge the two ("Senior Engineering" as a family), the matrix stops working, because you can no longer compare a Level 3 in Engineering to a Level 3 in Finance. That comparison is the entire point of a job architecture.

Sub-families are where you put the nuance that tempts people to create extra families. Engineering as a family with Software, Data, Platform, Security, and QA as sub-families is far more durable than five separate engineering families. You get the granularity for career paths and market matching while keeping one governance model and one set of leveling criteria.

How many families do you need?

Fewer than your first draft. A working range:

Two failure modes bracket the range. Too many families and each one holds three jobs, benchmarking gets thin, and every reorg triggers a rebuild. Too few and you end up with a "Corporate" family containing a paralegal, a tax accountant, and an executive assistant — three completely different talent markets sharing one structure.

A practical rule: if a family holds fewer than about five distinct jobs and isn't strategically critical, it should probably be a sub-family of something larger. If a family spans two clearly different labor markets, split it.

A six-step process that works

1. Inventory the real jobs, not the titles

Start from the HRIS export, then collapse it. Most organizations carry two to three times more titles than jobs. "Customer Success Manager," "CSM," and "Client Success Manager II" are frequently one job wearing three name tags. Deduplicate on work content, using job descriptions and a handful of manager conversations — not on the title string. If your descriptions are stale, fix that first; job analysis is the input to everything that follows.

2. Draft families from the work, bottom-up

Sort the deduplicated job list into piles by what the work is. Do this before looking at the org chart, and ideally before looking at pay. Two or three people should sort independently and then reconcile; the disagreements are exactly where your definitions are weak.

3. Write a definition and boundary for each family

Every family needs a two-to-three sentence definition and an explicit boundary statement covering the jobs it excludes. The boundary is the part people skip and the part that saves you later.

Data & Analytics. Jobs that acquire, model, and analyze data to produce decision-ready insight and data products. Includes analytics engineering, business intelligence, data science, and data platform work. Excludes application software engineering (Engineering family), financial planning and analysis (Finance family), and market research (Marketing family).

Write these before you assign a single employee. The definition is what a manager will argue with in month four, and a clean boundary statement ends the argument in two minutes.

4. Add sub-families only where the market or path differs

The test is not "are these jobs different?" — every job is different. The test is: do they benchmark to different market data, or follow a different career path? If yes, sub-family. If no, leave it alone. Splitting Product Design from UX Research is usually justified on both counts. Splitting Inside Sales into "Inside Sales — West" is not.

5. Level the jobs inside each family

Families answer what kind; levels answer how much. Apply one consistent set of leveling criteria across all families, then place each job. A job leveling matrix makes the criteria explicit — typically scope, complexity, autonomy, influence, and knowledge — so that a Level 4 in Finance genuinely equals a Level 4 in Engineering.

This is where a point-factor approach earns its keep. Sorting jobs into families is a judgment call, and judgment calls invite politics. Scoring each job against weighted compensable factors produces a number, and numbers survive the "my team is special" conversation in a way that adjectives never do. When two jobs in different families land at similar point totals, they belong at the same level — and you can show the arithmetic.

Getting a consistent leveling result across ten families by hand takes weeks. See how PointFactors scores jobs against weighted factors so your levels line up on evidence instead of argument.

6. Connect families to career paths and pay

Only now do you attach money. Levels map to grades; grades map to ranges. Families do not each get their own pay structure — that reintroduces the silos you just dismantled. Instead, run one salary structure and use market premiums or separate range sets where the external data genuinely demands it, usually a small number of hot-skill sub-families.

Career paths come nearly free once the grid exists. Vertical moves go up a family; lateral moves cross at the same level. Publishing "here are the four jobs at your level in three adjacent families" is often the single most-used output of the whole project.

The mistakes that cost the most

Building families from the org chart. Reorgs happen yearly; work content doesn't. If a reorg forces you to rebuild your families, you built departments.

Letting titles drive families. Title inflation is real, and inconsistent across functions. Group on work; fix titles afterward using a deliberate job title hierarchy.

Grouping by current pay. This is the quiet one. If you group jobs because they're paid similarly, you have encoded every historical inequity into the permanent structure and then dressed it as methodology. Group on work content, evaluate, then look at pay — and treat gaps between evaluated value and actual pay as findings, not errors.

One giant "Operations" family. If a family's definition needs the word "various," split it.

Creating a family for one person. This almost always means someone senior asked to be special. Route it to a sub-family or a market premium instead.

Never revisiting them. Families should be stable, not frozen. Review annually; expect to add or split roughly one family a year in a growing company, and to change definitions far less often than you change job descriptions.

Where families intersect with compliance

Job families are not a compliance artifact on their own, but two regimes lean on how you group jobs, and the groupings serve different purposes.

EEO-1 reporting. U.S. employers filing EEO-1 Component 1 report headcount across the EEOC's fixed set of ten job categories, defined in the EEO Job Classification Guide. These are a federal reporting taxonomy, not your architecture. Map each job to an EEO category as an attribute; do not reshape your families to match.

EU pay transparency. Directive (EU) 2023/970 requires in-scope employers to report gender pay gaps by categories of workers — and a category must be built from jobs doing equal work or work of equal value, assessed on objective, gender-neutral criteria including skill, effort, responsibility, and working conditions. That is a job-evaluation standard, not a functional-grouping standard.

The practical implication: your job families are not automatically your categories of workers. A functional family spanning six levels covers wildly different values of work. The reportable category is closer to family-plus-level, or grade, and only holds up if the leveling behind it is criteria-based. If you are in scope for the EU rules, design families and levels knowing the grade cells are what regulators will read.

FAQ

What is the difference between a job family and a job function? In most frameworks they're used interchangeably, but where organizations distinguish them, "function" is the broader business area (Go-to-Market) and "family" is the work grouping inside it (Sales, Sales Engineering, Customer Success). Pick one convention, define it in writing, and apply it everywhere.

Can one job belong to two job families? No. Assign every job exactly one family, one sub-family, and one level. Dual membership breaks headcount reporting, pay analytics, and pay-gap calculations. If a job genuinely straddles two families, it's usually two jobs, or the family boundaries are drawn wrong.

How are job families different from job levels? Families are horizontal and describe the type of work. Levels are vertical and describe scope and complexity. Together they form the grid: family on one axis, level on the other, with a grade in each cell.

Do job families determine pay? Not directly. Families organize jobs; job evaluation determines relative internal value; market data sets the external anchor. Families make both of those cheaper to run, because you evaluate and benchmark a family at a time instead of a job at a time.

How do job families work for remote and hybrid workforces? Exactly the same. Family and level describe the work, not the location. Geography enters through pay zones applied on top of the structure — see geographic pay differentials — which is precisely why you keep location out of the family definition.

How often should we update job families? Review annually alongside your structure refresh. Job descriptions change often; family definitions should change rarely. If you're rewriting definitions more than once a year, the original grouping logic was too narrow.

Where do managers fit — their own family or the family they manage? The family they manage, on a management track at the appropriate level. A Director of Engineering belongs in Engineering, not in a separate "Leadership" family. Career-track distinctions (individual contributor vs. manager) are a third dimension, not a family. See career ladder vs. career path for how the tracks interact.

What if our HRIS already has job families configured? Treat the vendor default as a starting point, not a decision. Most HRIS defaults mirror the org chart or a generic industry list. Validate every family against the three tests — shared work, shared skills, shared market — before you inherit it into your architecture.

Build the families once, on evidence

A job family framework is worth building exactly once, properly. Group by work content, keep families few and sub-families plentiful, hold levels as a separate dimension, and score the jobs rather than debating them. Do that and the structure survives reorgs, absorbs new roles without drama, and gives you defensible answers when an employee, an auditor, or a regulator asks why two jobs sit where they do.

Ready to build a job architecture your leadership team will actually sign off on? PointFactors evaluates every job against weighted compensable factors and produces families, levels, and grades backed by scores you can show anyone. Book a demo and see your own jobs mapped in a single session.

Justin Hampton is founder and CEO of PointFactors.