Why we very often start at the wrong end
When an organisation decides to revise its functions, it has three main projects ahead of it: the job architecture, the job descriptions and the evaluations. And very often, it starts with the job descriptions.
This is logical, in a way. The description seems the most tangible of the three. You know what it looks like, you have written one before, you see the result immediately.
Job titles are often forgotten, treated as a detail. Evaluations are frequently considered a separate project, while the architecture is seen as the result of the whole. The description, however, is concrete, you can get started on it right away.
The problem is that what is easiest to start is not what should be started first. And a revision led in the wrong order is paid for, later, in rework.
Revision, not revolution: starting from what exists
A principle, before entering the sequence. A revision never starts from a blank page. Job titles already exist, a structure is in place, adverts have been written, and often evaluations were done in previous years. None of this should be thrown out.
The objective is not to rebuild everything, it is to revise: taking what exists, clarifying it, bringing it back into coherence. Evaluations already carried out, in particular, are an asset. They required work, they carry knowledge, and part of them remains valid.
A revision of functions is a serious project, sometimes urgent, but never a vital emergency. It is necessary to build a realistic timeline that includes review and validation periods. You work over several months, you know this in advance, and unnecessary stress must be set aside. Besides, the fact that teams are in place invites you not to dramatise: you are revising a system that, on the whole, works, even if it needs to be brought back into coherence.
This nuance, revision and not revolution, changes the way to approach the project. You look for the right order to evolve what is already there.
The prerequisite: job titles
The first step is none of the three. It is the prerequisite, the one almost always skipped: the job titles.
As long as titles are not clarified, you do not really see the organisation. Two people doing the same job carry different titles; a single title covers unrelated realities. On this basis, the work of mapping functions becomes complex, and above all uncertain: you have no guarantee of having included everyone, nor that the structure will really reflect all the jobs in the company.
Titles are the raw material. They are how you spot who does what. Clarifying a title is not changing the function, it is bringing a word back into coherence without touching the qualification of the employee, meaning their missions, their level of responsibility and their hierarchical rank. This is the subject of "Job titles: one word, several meanings, several uses".
Titles in disorder, and the inventory of jobs is skewed from the start.
First step: the job architecture
Once the titles are clear, you can draw the job architecture.
The architecture work consists of seeing what makes sense to group into families of jobs, according to the nomenclature adopted. This is a first sort. Then comes rationalisation: deciding what makes sense to assemble or, on the contrary, to keep isolated, in the light of the reality of the external market, of the business and of its objectives.
This step is only possible if the prerequisite has been done. How many companies have one title per employee, or almost? How can one understand the different jobs, and the career ladders, through this? Clarified titles, and the architecture is already cleared of many pitfalls.
And this is where the cost of inversion appears. If you have started by drafting the job descriptions, and then rationalise the career ladders and the architecture, you discover that functions merge, get redivided, or disappear. Any description written for a function that no longer exists is lost work. You produced detail before setting the structure that governs it.
What matters here is the order: first the titles, then the architecture, and the descriptions only once this frame is set.
Second step: the reassessment as a check
The evaluation remains. And it plays a dual role, which is what makes it particular in the sequence.
On the one hand, existing evaluations are part of what you start from. You take them up again, you do not throw them out.
On the other hand, once the architecture is drawn, you reassess. And this reassessment is not only an update: it serves as a check. You verify that the logic holds from end to end, that there is no distortion in the sequence, that functions are positioned consistently in the new architecture. The reassessment closes the project by confirming that the whole edifice is coherent.
How to conduct a rigorous evaluation is the subject of another article in this series, "Job evaluation is not only a technical act". Here, what matters is its place: it comes last, because it needs the architecture to be set in order to play its role as a check.
Sustaining this coherence over time is a challenge in itself, which I address in The life of levels.
The essentials
Revising your functions is not tackling every project at the same time.
It is following an order: starting from what exists, clarifying the titles, drawing the architecture, then reassessing to check the coherence of the whole. Each step stabilises the ground for the next. Skipping a step does not save time, on the contrary, it costs time, because you work on ground that is still moving.
The HDH (HR Decision Hub) platform helps organisations in this journey: conducting a revision step by step, without producing work that will have to be redone.