Job Families Explained: How to Group Roles for a Career Framework

The problem with role lists that outgrow themselves

Picture this: your company has forty people. You have a "Software Engineer," a "Senior Software Engineer," a "Sales Development Rep," a "Senior SDR," an "Account Executive," a "Marketing Manager," and a "Content Strategist" — all listed on a shared spreadsheet someone started two years ago. When a new HR manager inherits this list and tries to build a review cycle, the first question is always the same: how do I evaluate these roles in a way that's fair and consistent across all of them?

The short answer is: you can't — not until you group them. Individual titles are not a structure. Job families are.

This article explains what job families are, how to define them, how they differ from related terms like job function and job function group, and how to use them as the organizing unit of a career framework that actually holds up during promotion conversations, review cycles, and headcount planning.

---

What a job family is

A job family is a group of roles that share a common area of professional expertise and a common progression path — roles that require the same underlying type of knowledge and skill to do the work, even if the specific titles or seniority levels differ.

Software engineers belong to a job family. Account executives belong to a different one. A UX designer belongs to yet another. What binds the roles inside a job family is not their reporting line or their department — it is the nature of the work itself.

Within a single job family you will typically find:

• A set of career levels (Junior → Mid → Senior → Staff/Principal, for example) that describe increasing scope, autonomy, and impact
• One or more tracks — most commonly an Individual Contributor (IC) track and a Manager track — so a senior engineer who does not want to manage people has a recognized path upward that does not require becoming an Engineering Manager
• A shared set of competency statements — the specific behaviors, skills, and outcomes you evaluate people against at each level

The job family is the unit that makes consistent evaluation possible. When you score an engineer against the competencies for "Software Engineer — Senior IC," you are comparing that person to a defined standard for their family and level, not against a moving target shaped by who their manager happens to be.

---

What a job family is not

A job family is not the same as a department. Departments are org-chart units that reflect how a company organizes its management reporting structure. A single department may contain two or three job families, and a single job family may eventually span departments.

Consider a typical growth-stage company's Revenue team: it might include Account Executives, Sales Development Reps, and Solutions Engineers. Each of those is a distinct job family — the skills, career levels, and evaluation criteria are meaningfully different — even though all three sit under the same VP of Revenue.

A job family is also not a job title. Titles are the labels you put on business cards and LinkedIn profiles. The same title can mean different things at different companies. The job family is the underlying structure that gives titles their meaning.

Finally, a job family is not the same as a job function or job function group, though these terms are related and are worth distinguishing.

---

Job family, job function, and job function group — the hierarchy

If you have come across the term job architecture — the broader system that organizes every role in a company — you will find it typically uses three tiers:

Tier	Term	Example
Broadest	Job function group	Technology
Middle	Job function	Engineering
Narrowest	Job family	Software Engineering

Some organizations use "job family" and "job function" interchangeably, especially smaller ones where the distinction is not practically meaningful yet. That is fine. What matters is that you pick a vocabulary and use it consistently across your framework. Inconsistency — using "function" in one part of a framework and "family" in another to mean the same thing — is what creates confusion during evaluation.

For most companies in the 30–200-employee range, two tiers are enough: a broad grouping (function) and the specific job family. You can add the third tier later as the org grows.

For a deeper look at how job families fit into the full job architecture picture, see our guide on career frameworks vs. job architecture.

---

How to define job families for your company

The practical question is not "what is a job family?" — it is "how do I draw the lines?" Here is a working method.

Step 1: List every distinct role type you have today, plus the ones you plan to hire in the next 12–18 months.

Do not list titles. List role types. "Software Engineer" and "Senior Software Engineer" are the same role type at different levels — one entry. "Data Engineer" is a judgment call: is the work meaningfully different enough from "Software Engineer" to warrant its own family, or will you evaluate them against the same competency set? Both answers are defensible; pick the one that reflects how the work actually differs.

Step 2: Ask the grouping question. For any two roles you are deciding whether to put in the same family, ask: Could a strong performer in Role A build, over time, the skills to advance to the highest level of Role B on the same progression path? If yes, they may belong in the same family. If the career path diverges sharply (a customer support specialist and a software engineer both need communication skills, but they are not on the same progression), they belong in separate families.

Step 3: Check your competency overlap. If you were to write the behavioral competency statements for each role, would most of them be shared, with level-based differences in scope and complexity? High overlap → same family. Low overlap → separate families. This is the practical test.

Step 4: Name each family simply and specifically. "Engineering" is a function; "Software Engineering" is a family; "Frontend Engineering" may be a sub-family or a track within Software Engineering, depending on how differentiated the work is. Name it at the level of specificity that matches how you actually evaluate the people in it.

---

A practical example: five job families for a 60-person SaaS company

Here is what a set of job families might look like for a software company at the 60–80-employee stage — before the org is large enough to need sub-families, but past the point where a single all-hands ladder makes sense.

Job Family	Tracks Available	Levels	Example Titles
Software Engineering	IC · Manager	5	Eng I, Eng II, Senior, Staff, Principal / Eng Manager, Sr Eng Manager
Product Management	IC · Manager	4	Associate PM, PM, Senior PM, Director of Product
Design	IC · Manager	4	Junior Designer, Designer, Senior Designer, Design Lead
Sales	IC · Manager	4	SDR, Account Executive, Senior AE, Enterprise AE / Sales Manager
People & HR	IC · Manager	3	HR Coordinator, HR Manager, Director of People

A few things to notice:

• Tracks are set at the family level. Every family in this example offers both an IC and a Manager track, because even a 60-person company needs to give its senior designers and senior AEs a path upward that does not require moving into management.
• Level counts vary by family. A three-level People & HR family is appropriate at 60 people. That same family might expand to four or five levels at 200 people. The career framework is a living document.
• Titles are illustrative, not the structure. The structure is the level. The title is the label you pin to it.

For more detail on how to set level counts and level criteria, see career levels: how many does your company actually need?

For a walkthrough of building the full ladder inside a family, see how to build a career ladder.

---

Where job families live inside a career framework

A career framework is the full system: job families, career levels within each family, IC and Manager tracks, competency statements at each level, and the evaluation process that runs against those competencies on a defined schedule.

Job families are the organizing unit of that system. Get them right — correctly scoped, consistently named, with clear grouping logic — and the rest of the framework has a solid foundation to build on. Get them wrong (too broad, too narrow, or inconsistently named), and you will feel it the first time you try to run a review cycle and cannot explain to an employee why they are being scored on a particular set of competencies.

The most common early mistake is building one giant "Engineering" family that tries to cover software engineers, data engineers, QA engineers, and DevOps engineers under a single set of competency statements. The competency statements become so generic they lose their evaluative value, and the resulting scores feel arbitrary to the people being reviewed. A separate family — or at minimum, a separate track within the family with its own competency language — for each meaningfully distinct engineering discipline is almost always worth the upfront effort. See our engineering career ladder levels and titles guide for a worked example of how to split these.

If you are starting from scratch and want a set of pre-built frameworks to adapt, the career ladder templates hub is a useful starting point.

---

Start with the grouping, then build the framework

Job families are not complicated in concept — they are just the answer to the question "what kind of work is this, and what does getting better at it look like over time?" The complexity comes in drawing the lines in a way that holds up when you are sitting across from an employee asking why they were rated the way they were, or when you are defending a promotion decision to a skeptical executive.

Spend the time up front to group roles deliberately, name the families consistently, and decide where you will use tracks. Everything else in the career framework — the levels, the competency statements, the evaluation cycle, the skill-gap reports — builds on that foundation.

If you want a practical reference as you work through the grouping exercise, our career ladder templates hub includes starting frameworks for several of the most common job families. And if you would like a short, practical guide to career framework fundamentals delivered to your inbox — no filler, one topic per send — sign up for the Career Ladder Builder newsletter below.