Job architecture / title rationalization
Job Family Mapping
Job family mapping organizes every role in the company into families and sub-families of similar work, each with its own level structure, turning years of title inflation into one coherent architecture.
It is the skeleton that leveling, pay ranges, career paths, and curricula all hang from.
- Problem
- Job architecture / title rationalization
- Altitude
- Enterprise
- Effort to run
- Heavy
- Evidence base
- Established
Theory & origin
Job architecture practice was codified by the big rewards consultancies, Mercer, Korn Ferry, Willis Towers Watson, once organizations discovered that uncontrolled titles make everything downstream impossible. You cannot benchmark pay, design career paths, or plan workforce supply when 700 titles describe only 180 actual roles. A family groups work of a similar nature (engineering, finance, sales). Sub-families sharpen that further (software engineering versus data engineering). Levels within each family describe increasing scope and mastery on one consistent scale. The real design tension is granularity, meaning how finely you split things up: too few families and leveling gets crude, too many and the architecture just recreates the title chaos it was meant to replace. The output is deliberately role-based, and it becomes the input to job profiling, which describes each role the architecture names.
Key components
The parts of the model and what each one means, in plain terms.
- Title inventory
- Every live title with its headcount attached. The honest picture of how much drift has happened. Expect multiples of the true role count.
- Families
- Single-digit groupings by the nature of the work: engineering, operations, commercial, corporate. The stable top layer of the whole architecture.
- Sub-families
- The working layer where benchmarking and careers actually live: software engineering, data engineering, and QA, all within engineering.
- Levels
- One scale across every family (scope, autonomy, mastery), so an L4 means the same thing in finance as it does in engineering.
- Mapping & governance
- Every role mapped, the rules published, and a gatekeeper for new titles. The architecture only survives if creating a new title actually costs something.
Explore the model
How a consultant runs it
- 01 Inventory the real titles first. The 700-title spreadsheet is the wake-up-call slide that funds the rest of the work.
- 02 Define families by the nature of the work, not by department. A data engineer sitting in marketing still belongs to engineering, not marketing.
- 03 Keep the family count in the single digits, and sub-families under about 50. Splitting things too finely is the enemy of long-term maintenance.
- 04 Level on one consistent scale across every family (scope, autonomy, mastery), so cross-family moves and pay comparisons actually work.
- 05 Map every incumbent to a family, sub-family and level, publish the mapping rules, and stand up governance before the first exception request shows up.
When to use
- 01 Title chaos, where benchmarking, leveling, or pay-equity work is blocked because titles no longer describe actual roles
- 02 Before job evaluation, career pathing, or academy design. All three consume the architecture as an input.
- 03 Post-merger, to reconcile two incompatible title and level systems into one
When not to use
- 01 Companies small enough that everyone already knows every role by name. Below roughly 150 people, the architecture overhead outweighs the value.
- 02 As a covert re-leveling or pay-cut exercise. The architecture will get blamed for decisions that were really hidden inside it.
- 03 Without the capacity to govern it afterward. An unguarded architecture re-inflates within two promotion cycles.
Worked example
A 3,200-person insurer cannot run a pay-equity analysis: 700 live titles, no levels, and "Senior" meaning three different things depending on which department you ask. The mapping lands on 9 families, 42 sub-families, and 7 levels, with every incumbent mapped in manager-validated workshops.
The inventory finds 61 titles describing the same 14 actual roles, and 40 people leveled above the actual scope of their work. Benchmarking becomes possible for the first time. The pay-equity fix is priced at Rp 32 billion, and the new title gate cuts title creation by 90%. Job profiling then picks up the 180 named roles as its worklist.
Common pitfalls
- 01 Letting departments define their own families, which just reborn the silo logic the architecture was supposed to cut across
- 02 Too many sub-families. It feels precise, and it guarantees the structure goes stale within a year.
- 03 Mapping people generously instead of roles honestly, which just bakes today's inflation into the new architecture
- 04 Launching with no title gatekeeper, so the 700-title problem regrows on top of the new skeleton
Sample deliverable
One real engagement, start to finish. Watch the numbers travel from raw input, onto the chart, into the finished artifact.
Input
- Engineering titles210
- Operations titles180
- Commercial titles140
- Corporate titles95
Process
Titles are inventoried per area and collapsed into families, sub-families and leveled roles
Architecture build: 700 titles, multifinance group
- 700 titlesdown to 9 families, 42 sub-families
- Duplicates61 titles for just 14 roles
- Handoff180 role profiles left to write