A job architecture cannot be the aggregate of a client portfolio.
This is a conviction I have drawn from several job architecture projects, at different scales, national and international.
Every company has its own history, its own culture, its own business lines, its own progression logics. And yet, we sometimes see grid proposals based on what has been built elsewhere. The methodology is ambitious, the delivery polished, but the structure says nothing specific about the company it is meant to represent.
This, in my view, is where many projects lose their value.
Rather than building a dream architecture that the organisation will then have to catch up with, I prefer to start from the organisation as it is, and bring it step by step towards what it wants to become.
One caveat: in some companies, a preexisting grid is mandatory (collective agreements, joint committees, regulated sectors). The principle still applies, but within the room left to the company: positioning of functions, internal career ladders, progression criteria within the imposed levels.
An organisation has its own culture, and that culture comes before the tools. A tool that ignores it runs up against it. A job architecture is no exception.
This is why it must be built from the company, by the company, and with the company.
From the company
We start from what really exists, not from a theoretical model. The real titles, the real reporting lines, the levels actually in practice. It is longer, more political, more uncomfortable. It is also what makes the structure credible to managers and defensible to employees.
By the company
Methodological trade-offs are company decisions, not external standards. How many career ladders, how many progression levels, where to open and close levels, where to draw boundaries between populations, how to group functions, how to name categories: these are choices that belong to the organisation.
There are many job evaluation methods, and each sheds light on a different aspect. A point-factor analytical approach breaks each function down into measurable criteria, skills, responsibilities, impact, and assigns a score. A classification approach places functions into predefined levels. A ranking approach orders them in relation to each other. While I am more familiar with the first two, I am convinced that none is wrong in itself, as long as it is explainable and ensures internal consistency. But all are tools serving a company decision, not recipes that mechanically produce the right grid.
This is the nuance that becomes decisive today. EU Directive 2023/970 on pay transparency, in its Article 4, requires that differences in level and remuneration be justifiable on objective, gender-neutral criteria, specific to the organisation. This last point changes everything. A grid taken from another context, or a method applied without being adapted to the company, can produce a technically clean result and still remain indefensible, because it says nothing specific about the organisation it is meant to represent. The gap exists, it is quantified, but the company cannot account for it case by case. And from now on, it is up to the company to account for it: a job architecture that is not rooted in the real organisation leaves the company without an answer the day a decision is questioned.
With the company
Managers, HR Business Partners and employee representatives must be able to follow, challenge, and validate the reasoning. A job architecture validated by the Comp & Ben function alone, or worse pulled from a client portfolio, will not survive the first promotion cycle.
Yes, this approach demands more work. More interviews, more back-and-forths, more trade-offs to own. But it is precisely this work that turns a grid into a management tool, and a project into lasting governance.
The essentials
A job architecture must reflect the company and its choices. It is built from the real organisation, by the company that owns its own trade-offs, and with it: managers, HR BPs and employee representatives must be able to challenge, validate and stand by the reasoning.
Only then does it remain explainable, and its choices traceable the day a decision is questioned.
So what is the starting point? This is a topic I will address in another article of this series, [[revising-functions-where-to-start]].
The HDH (HR Decision Hub) platform helps each company clarify its choices itself, by building and revising its own architecture, and keeping decisions traceable end to end.