Our previous post covered what job architecture is and why it matters (organisational structure, job families, levels, capability frameworks, career pathways, job evaluation and remuneration frameworks working together as scaffolding). It closed with a set of questions to gauge whether your foundations need work: consistent levels, defined accountabilities, visible growth paths, consistent remuneration decisions.
If you answered “no” to a few of those, the next question is usually: where do we actually start? The answer isn’t a blank page. It’s an audit.
You already have a job architecture, it’s just undocumented and inconsistent
On the podcast, Kassy pushed back on the idea that most organisations are starting from zero:
“I might actually challenge that, lots of organisations do have it, they just don't know they have it.”
Her examples are deliberately unglamorous. A delegation of authority schedule is a job architecture: it already says that people at this level can approve expenditure up to $50k and people at that level can’t. It just happens to have been written by Finance, so it captures authority and stops there. IT permission groups are the same artefact from a different author. Someone in ICT has already drawn a line around who can see which SharePoint folders and who can approve access to them.
Once you start looking, the list keeps growing: approval workflows configured in your finance system, who is named as an approver on a purchase order, which roles carry delegated safety or compliance responsibilities under legislation, who holds a company credit card and to what limit. Every one of those is a decision someone has already made about which group of people can do which category of thing. That is job architecture, just executed piecemeal, by different authors, for different purposes, and never reconciled.
So the gap usually isn’t structural. It’s the connective layer. Nobody has asked whether those separate groupings agree with each other, and nobody has translated them from permissions into people. That is where HR adds the next step: defining what capability, experience and accountability someone needs in order to sit at that level in the first place, then testing whether the delegation schedule, the access groups and the pay bands all draw the line in the same place. When they don’t (and they usually don’t), you’ve made your first real finding before you’ve designed anything.
“We're defining people into groups, who can do and access what? HR adds the next value of defining those groups in terms of skills and attributes… so the groupings already exist in your organisation somewhere. It's doing that extra step of what does it mean to be at that level, not just what invoice can they sign off on or what file can they see.”
And that’s only the part that’s written down. The rest is informal but no less real: titles, unspoken seniority signals or career conversations managers have had a hundred times and never recorded. Surfacing that layer, testing whether it’s actually consistent, and formalising the parts that hold up is the work, not inventing a structure from scratch.
Trying to design a “clean” structure in isolation, disconnected from how the business actually operates today, is the most common reason job architecture projects stall or get shelved: nobody in the business recognises themselves in it.
Building from what you have: a practical sequence
None of this has to be done for the whole organisation at once — and in a large organisation, attempting that is usually how the project dies. Pick one slice you can actually finish: a single function, a single level, or the population where the inconsistency is already causing you pain. Run the sequence below on that slice, prove it works, then repeat it. Six weeks on one job family beats six months on a spreadsheet nobody ever finishes.
- Audit before you design. Map each title in scope against what the person actually does — scope, decision rights, who they influence — not what the title implies. Inconsistency shows up fast: two “Managers” with very different accountability, or a “Senior” title that was really a retention lever.
- Group by the work as it is, not an ideal org chart. Job families should mirror how the business genuinely runs today. If two teams already work alike, they belong together — whatever they’re currently called.
- Calibrate levels against your own seniority signals. You already know who’s more senior than who — test that instinct against scope, complexity and decision rights, not tenure. Where instinct and criteria disagree, you’ve found something worth a closer look.
- Build profiles from what’s already written. Old job ads, position descriptions and review criteria beat a blank template. Rewrite them around scope and impact so one profile flexes across teams.
- Pressure-test against real people. Map a sample onto the draft structure and look hard at anyone who doesn’t fit. Either the structure missed how the work really happens — so change the structure — or you’ve hit an inconsistency you set out to correct, and you hold the structure and deal with the role.
- Put the slice to work. Write the next job ad off the profile, hold the next pay conversation against the level, and point system access and delegations at the level rather than the person. Adoption is the test, not sign-off — at this scale you don’t need a review cadence, you need people using it and telling you where it doesn’t hold.
Then take the next slice. Each round is faster than the last, because the levels, the family definitions and the profile format already exist — you’re applying a structure rather than inventing one. It also builds your case: a slice that’s demonstrably working is a far stronger argument for wider investment than a proposal for one.
What this looks like in practice
Kassy shared an example from a previous role that captures how far a simple structure built from what a business already has can go:
“We just had six levels in the organisation and built out a little matrix of what each of those six levels could do… what those six levels could do in terms of client interaction, financial expenditure, risk assessments and investigations and approvals.”
It was built for a construction company, so it had to work on a job site, not just on paper:
“If someone needed to stop work because a hazard was found on site… everyone on site knew that you needed a level three to be able to make the stop work call, so that even if there wasn't one directly on site, they knew exactly who to call because it was written into all of their contracts, what level you were in the job architecture, it was written into all of our policies, what level could make what calls... It was constantly used and spoken about every day. And therefore it was the most effective I've ever seen. And it wasn't fancy at all. It didn't require a consultant necessarily to come in and map it to the Hay/Mercer framework.”
The risk in building from what exists
Building from your current state isn’t the same as legitimising everything about it. Some of what exists today is inconsistency you’ll want to correct, not preserve — title inflation, pay decisions made role-by-role rather than against a framework, career paths that only exist informally for people a manager happens to champion. The audit step exists specifically to separate what’s a genuine signal of how work is organised from what’s just accumulated noise.Where this leads
Once the structure is mapped and pressure-tested, it becomes the input for the harder conversations the first post flagged: pay transparency, job evaluation, remuneration frameworks, and clean workforce data for HR technology and AI. None of those is solvable without this step being done first.
The payoff isn’t the document. It’s what stops landing on the executive team’s desk once the structure exists:
“We're making the decision-making so much easier for our HR teams or for our executives because it's already there, it's already written down”