Job Codes: How to Build a Job Code Structure That Scales

Job Codes: How to Build a Job Code Structure That Scales

Ask your HRIS for a headcount by job and you will learn a lot about your job codes. If the report comes back with 1,400 rows for a 900-person company, three flavors of "Sr. Analyst," and 62 codes with exactly one incumbent, you do not have a job catalog. You have a list of everything anyone ever typed into a requisition.

That matters beyond tidiness. Job codes are the join key for almost every compensation decision you make. Survey matching, pay range assignment, pay equity grouping, EEO-1 reporting, promotion tracking, budget modeling — all of it keys off the code, not the title on the business card. When the codes are wrong, every downstream number is quietly wrong too.

This guide covers what belongs in a job code, how to decide between a smart code and a sequential one, and the governance rules that keep a clean catalog clean.

TL;DR

• A job code identifies a job — a distinct bundle of duties and required capabilities. It is not a title, and it is not a position number.
• Encode only the attributes you will actually filter or report on. Three to four is usually right; five is the ceiling.
• Smart codes (ENG-P3) read well to humans. Sequential codes (100472) survive reorganizations. Pick one deliberately and stop mixing them.
• Store job family, level, FLSA status, pay grade, SOC code, and EEO-1 category as fields on the code — not as characters inside it.
• A healthy catalog runs roughly 1 job code per 4 to 8 employees. If you are near 1:1, you are coding positions, not jobs.

What a job code actually is

A job code is the unique identifier for a job: a set of duties, responsibilities and required capabilities that is meaningfully different from every other set in your organization. Two people doing substantively the same work at the same level share a code, even if one of them is in Denver and one is in Dublin, and even if their business cards differ.

Three things get confused with each other constantly, so it is worth nailing them down:

The practical test: if you eliminate the role, you retire a position. If you eliminate the kind of work entirely, you retire a job code. Confusing the two is how catalogs balloon — someone creates a new code for every requisition because the recruiting workflow needs one, and nobody ever retires anything.

You can let working titles flex for market or customer-facing reasons while the code stays fixed. That flexibility is the whole point of separating them. Just write down the rule, or you will end up with the title drift problem covered in job titling conventions.

What a bloated catalog costs you

The damage shows up in four places, and it is measurable.

Survey matching breaks. Sixty-two single-incumbent codes are 62 jobs nobody can benchmark. A code that exists for one person usually carries a bespoke title and no real description, which is exactly what defeats salary survey job matching.

Pay equity analysis loses statistical power. Regression needs groups large enough to test. Split a real job of 40 people into six near-identical codes and every group is too small to say anything.

Range assignment drifts. Every extra code is another chance to attach the wrong pay grade. Codes that mean the same thing but sit one grade apart create internal equity problems nobody finds until two employees compare offer letters.

Reporting cost compounds. Every dimension you want to slice needs a mapping table, and every junk code adds an exception to it.

A useful benchmark: most organizations settle at roughly one job code per four to eight employees after a real cleanup. A 900-person company with a mature catalog typically has 120 to 220 active codes, not 1,400.

The attributes worth encoding

Every job code should carry a small set of structured fields. Note the word fields — these live in columns next to the code, not baked into the characters of the code itself. That distinction saves you a migration later.

Required:

• Job family — the functional grouping, e.g. Engineering, Finance, Clinical Operations. See job families for how to draw those boundaries.
• Career track — management, individual contributor, technical/professional, support. This is the field that keeps a Senior Engineer and an Engineering Manager from colliding.
• Level — the rung within the track (P1–P5, M1–M4, and so on).
• Pay grade — the range the job maps to. Derived from evaluation, not typed in by hand.
• FLSA status — exempt or non-exempt, for U.S. codes.

Strongly recommended:

• SOC code — the federal occupation classification. The 2018 Standard Occupational Classification system has 23 major groups, 98 minor groups, 459 broad occupations and 867 detailed occupations, and every worker maps to exactly one detailed occupation. Storing it makes survey and government reporting nearly free.
• EEO-1 category — one of the ten categories the EEOC requires on the EEO-1 Component 1 report, from Executive/Senior Level Officials and Managers down through Service Workers.
• Evaluation point total — if you run a point-factor system, the score that produced the grade.

Stop there. If you cannot name the report or the system rule that consumes a field, do not add it.

Cleaning up a catalog usually means re-scoring a few hundred jobs against consistent criteria. That is exactly the work PointFactors is built to do — score every job against weighted compensable factors and get point totals you can defend line by line.

Smart codes vs sequential codes

This is the one real design decision, and teams waste months relitigating it.

A smart code embeds meaning in the characters: `ENG-P3` is an Engineering, professional track, level 3 job. A sequential code is meaningless on its own: `100472`, with everything else stored in fields.

Smart codes are more pleasant in a spreadsheet. The problem arrives the first time you move Data Engineering from Product to Technology. You either recode hundreds of employees and break every historical report, or you leave `PRD-` codes sitting in Technology and the code now lies. Within two years nobody trusts the prefix, and you are reading the fields anyway.

If you are on a modern HRIS and expect any structural change in the next three years, use sequential codes and let reporting assemble the readable label. If you must use smart codes, encode only what will genuinely never change — usually career track and level, not family or geography.

Whatever you choose, the non-negotiable rule is: no attribute lives in both the code and a field. Pick one home for each.

Building the structure in five steps

1. Pull the current state and count. Export every active code with incumbent counts, titles, pay grades and hire dates. Sort by headcount ascending. The single-incumbent tail is your cleanup list, and it is usually 30 to 50 percent of the catalog.

2. Group by work, not by title. Bucket codes into candidate jobs based on duties and required capabilities. "Marketing Analyst," "Analyst, Marketing" and "Growth Analyst II" at the same scope are one job. Differences in tools or product area are almost never differences in job.

3. Score the surviving jobs, then grade them. Job evaluation, not performance evaluation: you rate the job as designed against factors like skill, effort, responsibility and working conditions, independent of who holds it. Use the point-factor method for benchmark and disputed jobs, slot the rest per job slotting, then convert scores to grades as in job evaluation points to pay grades.

4. Build the crosswalk before you migrate. One row per retired code, mapped to its replacement, with an effective date. This file keeps historical reporting, promotion history and pay equity trending intact. Skipping it is the most expensive shortcut in the project.

5. Retire, don't delete. Set old codes inactive. Deleted codes orphan records in payroll, benefits and every warehouse table you have.

Plan on eight to twelve weeks for a few hundred codes, with the grouping step taking the longest because it needs manager input.

Governance that actually holds

A cleanup without governance decays at roughly the rate it was created. Four rules do most of the work:

• One owner. Compensation owns the catalog. Recruiting, HRBPs and finance request codes; they do not create them.
• A written creation test. A new code requires new duties at a materially different level of responsibility — not a new title, a new manager, a new location, or a counteroffer. Write this down and point to it when you say no.
• Batch releases. Approve new codes on a fixed cadence, monthly or quarterly. Ad hoc creation is how you got 1,400 codes.
• An annual audit. Every year, list codes with zero incumbents for 12 months and codes with one incumbent, and justify or retire each one.

One more forward-looking note: the SOC Policy Committee is currently reviewing the 2018 SOC for a possible revision in 2028, with change recommendations still to go to OMB and the new version intended for use in reference year 2028. If you store SOC as a field rather than burning it into the code, that update is a mapping exercise instead of a re-coding project.

Mistakes that keep showing up

• Coding positions as jobs. The 1:1 code-to-employee ratio. Nearly always caused by requisition workflow, not by real job diversity.
• Geography in the code. `ENG-P3-NYC` looks helpful until you open an office. Location belongs on the position or the pay zone, not the job.
• Level inflation by code. Creating `Senior Staff Principal Analyst` as a code to solve a retention problem. That is a pay problem; fix it in the range.
• Letting titles create codes. If a working title needs to change for market reasons, change the title field. The code stays.
• No effective dating. Without dates, you cannot tell a reorganization from a data error six months later.

FAQ

How many job codes should we have? Roughly one per four to eight employees once mature. Under 1:4 usually means you are coding positions; over 1:15 may mean your codes are too broad to benchmark or grade accurately.

Should job codes be numeric or alphanumeric? Either works. The real question is smart versus sequential. If you expect structural change, use sequential codes and keep the meaning in fields.

Can two job codes share the same pay grade? Yes, and most do. Many distinct jobs land in the same grade; that is what grades are for. The reverse — one code mapped to two grades — is a data error.

Do job codes need to match SOC codes? No. Your codes reflect your organization; SOC reflects a federal taxonomy. Map each job code to one SOC code as a field. Many of your codes will share a SOC code.

Who should own the job catalog? Compensation, with an intake process for HRBPs and recruiting. Splitting ownership between HR and finance reliably produces two catalogs.

How do we handle job codes after an acquisition? Map the acquired codes to yours through the crosswalk file, and re-score any acquired job whose duties do not clearly match an existing one. Do not adopt two catalogs "temporarily" — temporary lasts years.

Get your catalog on a defensible footing

A clean job catalog is not an HRIS hygiene project. It is what makes every pay range, survey match and equity analysis you run mean something. The hard part is not the coding convention — it is scoring a few hundred jobs consistently enough that the grades hold up when someone challenges them.

That is what PointFactors does. Score every job against weighted compensable factors, get point totals and grades you can explain to a skeptical executive, and export a catalog your HRIS can take straight in. Book a demo or see pricing.

Justin Hampton is founder and CEO of PointFactors.