Job architecture without a consulting project

Job architecture sounds like a project with a steering committee. At under a thousand people it is a spreadsheet, a few hard conversations and about six weeks.

You need it before you can do pay bands, career paths, internal mobility or pay transparency compliance properly. Everything else waits on this.

Start with families, not levels

Group work by the kind of contribution, not the department. Engineering, product, design, commercial, operations, corporate functions. Six to ten families is normal. Departments change every reorg; families do not.

Define levels by scope, not by years

Four to six levels for individual contributors, three to five for management. Describe each by the size of problem someone owns, the amount of ambiguity they absorb, and who they influence. Never by years of experience, which is a proxy for nothing and creates age discrimination exposure in several jurisdictions.

Map people before you publish

Take the whole population and place them. This is where the architecture meets reality. You will find three or four people who do not fit, two titles that mean different things in different offices, and one team where everyone is somehow senior.

Resolve those before you announce anything. A framework published with obvious anomalies in it will be judged on the anomalies.

Separate title from level

Titles are market facing and emotional. Levels are internal and structural. Keeping them separate lets you give a sensible external title without distorting your pay bands, and lets you fix title inflation later without demoting anyone.

Publish the ladder, hold the mapping

Show everyone the levels and what each requires. Individual placements stay between a person and their manager. This is the balance that gets you the benefit of transparency without a week of public comparison.

Then leave it alone for two years. Architectures that get revised constantly teach people that levels are negotiable, which is the opposite of the point.