Job Families vs Functions vs Levels Explained

Key points: 

• Job families group roles by shared skills and purpose, not by department. They give HR teams a common language for comparing roles, benchmarking pay, and running equity analysis across the whole organisation.
• The terminology hierarchy runs from broad to specific: job family group → job family → job function → job level. Not every organisation needs all four layers.
• Real-world implementations range from 3 to 40+ families. The CIPD describes six to eight levels per family as typical.
• Job families are the structural foundation for EU Pay Transparency Directive compliance. Enforcement in June 2026 requires reporting on categories of workers performing work of equal value – exactly what a well-built framework produces.

Organisations that grow through hiring and acquisition have a habit of accumulating hundreds of inconsistent job titles. The same work gets called different things across teams, identical titles cover fundamentally different roles, and without any shared framework, pay is decided whether the person’s brave enough to negotiate rather than what the role is actually worth.

It's a mess – and it makes life genuinely difficult for HR teams trying to benchmark salaries, plan career paths, or run any kind of equity analysis.

Job families fix this. They group related roles into a structured taxonomy based on shared skills, purpose, and career trajectory – giving you a common language for comparing roles, setting pay, and spotting gaps.

This guide breaks down how job families, job functions, and job levels relate to each other, what real frameworks look like in practice, and why they matter for compensation and pay equity.

{{ ai }}

What is a job family?

A job family is a grouping of roles within an organisation that share a common purpose, core skills, and career trajectory.

All software engineering roles, from junior developer to principal engineer, for example, belong to one family. All HR roles, from Recruiter to People Director, belong to another. The grouping is based on the nature of the work – not the org chart.

That distinction matters more than it might seem at first glance.

Job families are not departments. A skills-based framework puts data analysts from Finance, Marketing, and Operations in the same family, even though they report to different department heads. Even function-based frameworks group roles by what people do, not who they report to.

There are two main design approaches:

• Function-based design groups roles by organisational unit – Finance, HR, and Engineering. The IES notes this is the more common starting point because it maps onto structures companies already have in place.
• Skills-based design groups roles by shared capability – Data and Analytics, Project Management, regardless of which department the role sits in. The IES found that many organisations end up with a hybrid: functional labels for the families themselves, but skills-based criteria for progression within each one.

Why do organisations adopt job families?

Without a shared structure, HR can't answer basic questions. Is a "Senior Analyst" in Finance the same level as one in Marketing? Should they be paid the same? Job families create the common language that makes role comparison, pay benchmarking, and equity analysis possible across the whole organisation.

One financial services company documented by the Institute for Employment Studies (IES) put it bluntly: their existing pay system "pigeon-holed people from all walks of life in the one system." They needed to reflect the wide variety of occupations and functions across the business, but bolting a market relationship onto a performance-driven pay structure just didn't work. IES research found that one County Council hit the same wall – trying to benchmark 1,500 individual jobs against the external market, one by one, was simply not feasible.

Modern benchmarking tools like Figures make that comparison much faster – but even with the best tooling, you still need a structure to group roles into comparable categories.

Here's a quick overview of how the process works: 

1. Collect existing job data.
2. Identify patterns across roles.
3. Group related roles into families.
4. Define levels within each family.
5. Validate the structure against market data.

This article covers the terminology hierarchy, real-world examples, and the compensation and pay equity connection. Step-by-step framework creation is covered separately in the job levelling guide.

How job families, job functions, and job levels fit together

One of the biggest sources of confusion in HR projects is the terminology. Job family, job function, job level, job family group, job category – different organisations use these terms inconsistently, and it stalls progress before any real work gets done.

Here's how the hierarchy actually works. Think of it as progressively finer groupings, from broadest to most specific:

To see how this nests in practice: "Data and Analytics" sits alongside "Software Engineering" under the same "Technology" group. It has its own functions – Data Engineering, Business Intelligence – and its own level progression from junior to principal. The tiers nest inside each other rather than competing with each other.

Some organisations also use sub-families – an intermediate layer between the family and the function. A Human Resources family, for example, might contain sub-families like Talent Acquisition, Compensation & Benefits, and Employee Relations, each with their own roles and levels underneath.

Boston University publishes one of the most detailed examples available. IT alone contains sub-families for Applications, Architecture, Technical Engineering, and Technical Support. Across 20 families and over 125 sub-families, the family, sub-family, and career level combine to determine every job assignment.

🤔 Wondering about "job category"? It's typically interchangeable with "job family group" – the broadest tier in the hierarchy. If you've seen both terms used in policy documents or software platforms, they almost always mean the same thing.

Now, not every organisation needs all four layers. Smaller companies often collapse job family and job function into a single tier and operate with just family and level. The IES found that one public sector body operated with just three families, while a financial services company ran as many as 40. The right number depends on how precisely you need to align each group with its external pay market.

Job family examples in practice

So what do job families actually look like when real organisations put them into action? The names will feel familiar – but the structure underneath is what matters.

Here are some of the most common corporate job families, with example roles in each:

• HR: Recruiter, People Partner, L&D Specialist.
• IT/Technology: Systems Administrator, Software Engineer, Security Analyst.
• Finance: Financial Analyst, Payroll Manager, FP&A Lead.
• Marketing: Content Manager, Brand Strategist.
• Sales: Account Executive, Sales Engineer.
• Legal: Corporate Counsel, Compliance Officer.
• Supply Chain: Procurement Analyst, Logistics Coordinator.
• R&D: Research Scientist, Product Developer.

The number of families varies hugely. Nationwide Building Society used a five-level model where families narrow with seniority – four at level one, down to one at level five – an approach the IES found cut the ad hoc payments that had built up over the years. 

Other organisations go much further; the IES documented as many as 40 families in financial services. The CIPD describes job family structures as typically having six to eight levels per family, with separate salary structures for each, which is what allows market-rate pay for sought-after roles without distorting the wider scale.

The tradeoff is real: fewer families simplify management but make market alignment cruder. On the other hand, more families give you precision, but multiply the admin.

That said, some of the most instructive examples come from outside the private sector – largely because public institutions tend to publish their frameworks in full.

• The UK Civil Service ODP Framework organises operational delivery roles into job families and role clusters, with grade-level responsibilities mapped from Administrative Assistant through to Senior Civil Service. 
• Loughborough University takes a simpler approach: just six broad families – Administrative Services, Research Teaching Enterprise, Management and Specialist, Operational Services, Specialist Supporting Academic, and Technical Services – each mapped to specific grade ranges. 

💡 Don't let your job families sit in a static spreadsheet. With Figures, you can map your HRIS roles directly to these families, so your market benchmarking and pay equity audits update automatically as your team grows.

Become compliance-ready with Figures!

Book a demo

The benefits of using job families

A well-built job family framework does more than tidy up your org chart and make you look like the coolest cat in HR. 

It also helps with: 

• Career progression visibility: Families define the skills and experience separating each level, giving employees a clear map for both vertical and lateral moves. No more guessing what "the next step" looks like.
• Workforce planning: You can spot skill gaps and succession needs by family, rather than scrambling role by role.
• Streamlined hiring: Job profiling becomes faster when you're matching candidates against family-level criteria instead of writing every description from scratch.
• Compensation consistency: Shared pay structures within families mean salary decisions have an objective basis – not just whoever negotiated hardest at the offer stage.
• Simplified role management: New roles can be matched to existing family-level profiles instead of scoring every individual position through a full evaluation exercise.

That's the upside. But it's worth being honest about the risks, too.

If your market benchmarks reflect historical undervaluation – and in many occupations, they do – baking them into family-specific pay ranges can formalise the very inequities you're trying to fix. The IES is blunt about this: differences between families need to be objectively justifiable, and simply matching roles to family-level descriptions isn't enough to defend an equal pay claim. Rigorous job evaluation needs to sit underneath.

This is also where the EU Pay Transparency Directive (Directive 2023/970, enforcement June 2026) comes in. The Directive requires organisations to report pay gaps across "categories of workers performing the same work or work of equal value." A well-structured job family framework produces exactly those categories. Without one, completing the required analysis becomes very difficult.

For readers exploring job architecture and its compliance implications, see the guide to job architecture and pay transparency.

Putting your job family framework to work

You've built the framework. Now what?

“This is where most organisations hit a wall. Job families on their own are an organising principle. Without market data and equity analysis layered on top, they remain a taxonomy exercise – useful, but incomplete.” – Virgile Raingeard, CEO at Figures.

Figures picks up where the framework leaves off. You set your roles, levels, and job families inside the platform, then benchmark each family and level against 3.5M+ Mercer data points across European markets.

From there, Figures generates salary bands per family and runs pay equity analysis to separate explainable gaps from unjustified ones. 

For context: 82% of companies joining the platform have pay gaps exceeding the 5% threshold set by the EU Directive.

Don't have a framework yet? Figures publishes two free levelling frameworks – Simple and Advanced – in the job levelling guide. They're a solid starting point, whether you're building from scratch or formalising something that's been living in a spreadsheet.

Ready to connect your framework to market data? Book a free demo.

Common questions about job families

How does a role profile differ from a job description?

• A role profile describes the skills and accountabilities expected at a given level within a family – it applies to anyone at that level, regardless of team. 
• A job description is written for a specific post held by a specific person and tends to drift over time as responsibilities shift. 

How do job families support a skills-based workforce?

Families provide the taxonomy that groups roles by capability requirement rather than department. When skill needs shift – and the World Economic Forum estimates that 39% of workers' core skills will change by 2030 – updating at the family level propagates across all roles in that grouping. That's far more practical than rewriting hundreds of individual job descriptions one at a time.

How many job families does a typical organisation need?

There's no single right answer. The IES documented implementations ranging from 3 to more than 40. Fewer families simplify management but make market alignment cruder. More families allow precision, but multiply the admin burden. 

Can job families reduce employee mobility?

They can, yes – and it's worth flagging. The IES found that by making criteria explicit, job families can create clearer demarcation lines between groups. An employee moving from a higher-paid family to a lower-paid one faces a pay complexity that most organisations haven't designed for. The fix is to build cross-family movement pathways into the framework from the start, rather than treating them as an afterthought.