Job families explained - the building blocks of job architecture

What is a job family?

A job family is a grouping of roles that share a common function, discipline, or area of expertise within an organisation. Think of it as the broadest useful category you can place a role into based on what the work is, not where it sits on an org chart.

Examples are straightforward. A "Technology" job family groups software engineers, data analysts, QA testers, and IT support. A "Commercial" family covers sales, business development, and account management. A "People" family includes HR generalists, talent acquisition, learning and development, and compensation specialists.

The concept is not new. Established frameworks from Korn Ferry, Mercer IPE, and the EU guidelines on gender-neutral job evaluation (EIGE/EC, 2026) all treat job families as the first structural layer of a job architecture. The EIGE/EC toolkit describes job evaluation as "a systematic process for determining the relative value of jobs, based on objective criteria such as skills, responsibility, effort and working conditions" - and organising roles into families is the practical first step before any of that evaluation can happen.

What is the difference between a job family and a department?

This is where most companies trip up. A department is an administrative grouping - who reports to whom, who shares a budget. A job family is a functional grouping - what kind of work the roles involve.

A "Product" department might contain product managers, designers, and engineers. But those are three different job families (Product Management, Design, Technology) that happen to sit together organisationally. If you treat the department as the family, you end up comparing roles that have fundamentally different skill requirements, which makes levelling, grading, and pay benchmarking unreliable.

As Josephine Groom, CEO of Compensation IQ, explained in the Job Architecture Masterclass: "You start by defining your functional areas, departments, and teams into job families, sub-families, and specialisations if you need them." The emphasis is on functional areas - the nature of the work - not the reporting lines.

What are sub-families and specialisations?

A job family alone is often too broad. That is where sub-families come in.

A sub-family is a narrower grouping within a family. If "Technology" is the family, sub-families might include "Software Engineering", "Data and Analytics", "Infrastructure", and "IT Support". Each sub-family contains roles that share core competencies and a career progression path, even though the specific work differs.

Some organisations add a third layer: specialisations. These are the most granular division - for example, within "Software Engineering", you might have "Backend", "Frontend", and "Mobile" specialisations. Not every company needs this layer. For most mid-market organisations, families and sub-families are sufficient.

Why do job families matter for pay, progression, and pay transparency?

Job families are not just an organisational tidying-up exercise. They are the structural foundation for three things that every company with more than 100 employees needs.

How does Job Architecture support salary benchmarking?

You cannot set a meaningful salary range for a role unless you can compare it with similar roles - and job families are what make that comparison possible.

Consider a "Data Analyst". If you try to find salary benchmarks for that job title with no added context, your results will be all over the place. That is because a data analyst in marketing, a data analyst in finance, a data analyst in operations, and a data analyst in a product team are doing fundamentally different work. They report to different people, use different tools, solve different problems, and carry different levels of responsibility. A finance data analyst building regulatory models has almost nothing in common with a marketing data analyst running campaign attribution reports - yet the job title is identical.

This is exactly why a good job architecture is critical. Your data analysts need to be placed in the correct sub-family - the one that reflects the nature of their work, not just the job title on their contract. A data analyst in finance sits in the Finance family, sub-family "Financial Analysis". A data analyst in marketing sits in the Marketing family, sub-family "Marketing Operations" or "Marketing Analytics". Once each role is in the right sub-family, you can benchmark that specific role against market data for the same type of work - and your pay bands will actually reflect what people do, not just what their title says.

How do job families support career progression?

Job families define not just what roles exist, but how they connect. A well-designed family structure shows employees exactly where they can go: up within their sub-family (junior data analyst to senior data analyst to lead), across to a related sub-family (from marketing analytics into demand generation), or into a management track.

Without that structure, the most common question in any growing company - "What is next for me?" - has no credible answer. An employee looking at their career has no visibility of what roles exist at the next level, what skills they would need to move across, or how their current role compares to similar roles elsewhere in the organisation. Job families make progression visible, structured, and explainable - instead of ad hoc and dependent on who you know.

For a company of 100 to 300 employees, this matters commercially too. Retention improves when people can see a future. Promotion decisions are more defensible. And managers can have honest, evidence-based conversations about what the next step looks like and how to get there.

Why do job families matter for EU pay transparency?

The EU Pay Transparency Directive (2023/970) requires employers to group roles into "categories of workers" performing "equal work" or "work of equal value". Those categories need to be based on objective, gender-neutral criteria: skills, effort, responsibility, and working conditions. Employers covered by the Directive must then report on the gender pay gap within each category.

Job families are the practical mechanism for building those categories. You group roles into families, level them, grade them using point-factor evaluation, and the grades produce the equal-value categories the Directive requires. Without families as the starting point, the entire chain breaks down.

The EIGE/EC toolkit on gender-neutral job evaluation (2026) reinforces this: it walks organisations through structuring roles, gathering job information, and evaluating them against the four criteria - all of which assumes a family-based structure is in place.

How to define your job families: a practical approach

There is no single correct set of job families. The right structure depends on your organisation. But the approach is consistent:

Start with functional areas, not departments

List the broad types of work your organisation does. Common families include Technology, Commercial/Sales, Marketing, Finance, People/HR, Operations, Legal, and Customer Success. You are looking for 6 to 12 families at most mid-market companies.

Map sub-families by distinct skill sets

Within each family, identify where roles require genuinely different competencies. A "Marketing" family might split into "Brand and Creative", "Demand Generation", "Product Marketing", and "Marketing Operations". Each sub-family should have its own career progression logic.

Normalise job titles into consistent roles

Companies accumulate job titles over time. A "Customer Happiness Ninja" and a "Client Success Manager" might be the same role. Normalising titles into clean, consistent roles within each sub-family is essential before you can level or benchmark effectively.

This is an area where technology helps. The Compensation IQ platform absorbs existing employee data and auto-suggests families, sub-families, specialisations, and normalised job titles - doing roughly 95% of the mapping work automatically.

Validate with line managers

No framework survives first contact with reality unless the people managing roles agree it reflects how work actually happens. A short validation step - "Does this grouping make sense for your team?" - prevents rework later.

What are the most common mistakes when structuring job families?

Confusing families with departments. As covered above, a department is an administrative unit. A job family is a functional one. Mixing them up produces a structure you cannot use for benchmarking or compliance.

Too many families. If you have 25 families for 200 employees, you have over-engineered. Every family should contain enough roles to make cross-role comparison meaningful.

Too few sub-families. A single "Operations" family with no sub-families lumps together warehouse operatives, logistics coordinators, and facilities managers. Their skill requirements are different, their pay markets are different, and their career paths are different. The family needs splitting.

Using families as a one-off project. Job families need an owner and a review cycle. Roles change, new functions emerge, teams restructure. A framework built once and never maintained is stale within 12 to 18 months - and our research shows nearly 60% of companies say their current job architecture does not meet their business needs today.

What comes after job families: levels, grades, and employee evaluation

Job families are the foundation, not the finished product. Once your families and sub-families are defined, the next steps in building a complete job architecture include:

Level the role. Assign each role to a level based on its scope, autonomy, and accountability. This is where career tracks (individual contributor, management, executive) come in.

Add role grading. For organisations that need finer differentiation - or that need to produce equal-value categories for EU pay transparency - point-factor grading evaluates roles against criteria like skills, effort, responsibility, and working conditions to produce a defensible score.

Evaluate the employees against the role requirements. Once you have sized the role (the "chair"), you evaluate the person sitting in it. Are they developing within the role, meeting role requirements, or exceeding them? This is the mechanism that explains - and defends - why two people in the same role and grade can be paid differently.

Each of these steps builds on the family structure. If the families are wrong, the levels are wrong, the grades are wrong, and the pay decisions built on top of them are indefensible.

How to get started with Job Architecture

If you are starting from scratch, the approach is simpler than it looks:

1. List your functional areas and group them into 6 to 12 job families.
2. Break each family into sub-families based on distinct skill sets and career paths.
3. Normalise your job titles into consistent roles within each sub-family.
4. Validate the structure with line managers.
5. Move on to levelling - which is the next step in your job architecture journey.

If you already have levels but your family structure is unclear or inconsistent, fixing the families first will improve everything downstream.

Frequently asked questions