Job Family

Up to about twenty people, judging everyone individually works. Salaries follow whatever was negotiated at offer time, and the founder knows who is doing well and can act on it. No written standard is needed because one person is watching all of it.

Past forty people with six or seven distinct roles, that stops. A designer three years into their career and an engineer three years into theirs end up in the same room asking why one is paid less than the other, and there is no good answer available. The two jobs are different enough that a single yardstick doesn't apply, and saying that different yardsticks are used invites the obvious follow-up: where are they written down? Raise one side and the same question comes back from the other.

Job families solve this by narrowing what gets compared to what. Instead of ranking everyone on one list, people whose work has the same shape are grouped together and the standard is written inside each group. Engineers are described against engineers, designers against designers, and people in different groups are never lined up against each other to begin with.

There is one test for drawing the boundary: if the same sentence can describe growth for two roles, they belong in the same group.

A job level is a grade based on scope and responsibility, and each grade is written out as a sentence about what someone at that grade accomplishes. Those sentences differ by role, which is the reason job families exist at all. Moving an engineer up a level means the technical problems they can solve alone got bigger. Moving a salesperson up the same level means the revenue they own alone got bigger. Merge the two into one sentence and it fits neither.

In practice the setup runs in three steps.

1. Group the roles in the company by the shape of the work. Most companies land somewhere between six and ten groups — engineering, design, product, sales, marketing, operations. Slice too finely and you get groups of two or three people, which is too little evidence to write a standard against.
2. Write a separate level table for each group. Five to seven grades, each one describing what a person at that grade does in that particular job. Separate tables, matching number of grades.
3. Keep the pay band identical across groups at the same grade. A pay band is the salary range attached to each level. If a level 4 designer's range differs from a level 4 engineer's, people stop reading the written descriptions and read the money instead as a statement about which job the company values.

Step three is the one that breaks most often. When the market price for engineers climbs fast, the pressure is to lift that group's ranges alone — and a gap opened that way stays in place with nothing in the documentation explaining it.

A job family does nothing by itself. It shows up as the thing that sets the scope for other systems, in four places.

1. Hiring. The job description states the family and the level together. Because the requirements in the posting come from that family's level table, what candidates are screened against and what they're evaluated against after joining stay aligned.
2. Evaluation. Job families decide who gets compared to whom in a performance review. The comparison set is people in the same family at the same grade; people from other families never enter the same ranking.
3. Compensation. Ranges get managed by grade rather than by group, and market salary data gets read one family at a time, since a benchmark for designers says nothing useful about what a salesperson at the same grade should earn.
4. Movement. When someone requests internal mobility, the family tells you whether they are crossing groups or moving within one. A support person moving into product is crossing, which usually means either starting a grade lower or holding the grade with an explicit ramp-up period.

Small companies use this classification informally long before writing it down. "Let's set designer pay by comparing designers to each other" is already a job family at work. The point where it gets written down is usually around fifty people, or the point where the company starts hiring a third person into the same role.

"Different job family, so the same level table doesn't apply. You need to read the design one."

The comparison isn't valid, so go judge it against a different document.

"Her family says marketing but half the work is data analysis. The classification needs another look."

Someone's actual work has drifted away from the description of the group they sit in.

"If we're running different bands per family, let's write down why they're different."

Any gap in money needs a reason recorded somewhere.

The first thing Grace built when Pagedeck passed forty-five people was this classification. The first draft had twelve groups. Frontend split from backend, content marketing split from performance marketing — and the result was five groups with exactly one person in them. A group of one has nobody to be measured against, so the level table changes nothing and the decision goes back to the founder's judgment — the exact situation the classification was supposed to replace.

Mia pushed back and the draft came down to six: engineering, design, product, sales and customer success together, marketing, and operations. In exchange they added a field for the specific role inside each group. Theo is recorded as level 4 in the engineering family, specific role backend.

The most common error is treating job families as the org chart. Group names and team names overlap often enough to make this easy. But an org chart shows who reports to whom, while a job family divides people by which standard is used to judge growth and pay. It is normal for one team to contain people from several families; a product squad of six might hold three engineers, a designer, a product manager and a data analyst, sitting in four different families. Conflate the two and every reorg drags the level tables and salary ranges along with it, which leaves a company whose evaluation criteria change every six months.

The other error is reading different families as grounds for different treatment. Different work seems like it should mean different money. The operating principle is the opposite: the family is the line that decides who gets compared, and at the same grade the range stays the same across families. Break that and people start working out which group pays better rather than how to get better at the job they have.