Why most organisations mistake the last document for the whole architecture — and what it quietly costs them.
There is a failure mode in organisational design so common that most organisations have stopped noticing it. A leadership team decides the structure isn't working. A redesign is commissioned. The org chart is redrawn. Roles are renamed. A communication goes out. And twelve months later, the organisation is performing almost exactly as it did before — because the chart changed and the underlying logic did not.
The reason is not politics, though politics gets the blame. The reason is directional. The redesign started from the wrong place.
Best practice in job design follows a clear direction. You start from what explains the organisation — its strategy, its mandate, the chain of activities through which it creates value — and you derive everything else from there. The operating model tells you what the organisation does. The process tells you how the work actually flows. The structure tells you how to organise accountability for that work. The jobs tell you who does what within that structure. The job descriptions document all of the above.
That sequence — strategy or mandate, then operating model, then process, then structure, then jobs, then descriptions — is the direction. From the source of strategic logic outward.
Most organisations run it in reverse. They have job descriptions, so they treat the descriptions as the architecture. They have a chart, so they treat the chart as the structure. They have grades, so they treat the grades as the job design. None of these things are what they are being treated as. They are artefacts — the residue of decisions made at some point, for reasons that may no longer apply — and redesigning from them is navigating by where you once were.
The starting point in this sequence is not always the same. It depends on the organisation.
In strategy-driven companies, you start with the strategy — the choices the organisation has made about where it competes, how, and with what capabilities. The job architecture serves those choices. Change the strategy and the architecture should eventually follow, deliberately.
In mandate-driven institutions — government bodies, regulatory agencies, specialist institutes — you start with the mandate. Not a mission statement. The specific obligations the institution was created to fulfil. Everything the institution does, every role it creates, must be traceable to that mandate. We worked with one such institution that had no existing org chart and no job descriptions whatsoever. Rather than treating that as a problem, we treated it as an opportunity to build from first principles — which is, in fact, the only honest way to build. We started with three mandated functions: training an industry's workforce, producing and distributing improved crop materials, and independently assessing estate performance for a regulator. The architecture followed from those three things entirely.
There is one mistake that derails job architecture work more reliably than any other: treating process and structure as the same thing.
A process is a sequence of activities that produces an output. A structure is how you organise people and accountability to execute processes. They are related. They are not interchangeable.
The confusion looks like this: someone maps eighteen processes the organisation must run, then creates eighteen structural units — one per process. It feels logical. It produces an org chart that is impossible to lead, full of units too narrow to hire for and too small to manage effectively.
In the institution we worked with, two of the three mandated functions involved teams visiting the same farms and factories. On paper, they looked like the same work. One team managed those assets. The other assessed them on behalf of an independent regulator. The moment you put them in the same unit, both functions break — the people doing the managing cannot credibly do the assessing, because their accountability points in opposite directions. Separating them was not a structural preference. It was a structural necessity derived from what each function was actually there to do.
That decision did not come from reading job descriptions. There were none. It came from understanding the work before touching the chart.
When job architecture runs in the right direction, three things become possible that are not possible otherwise.
The structure can be explained. Every unit, every reporting line, every grouping of functions has a reason that was present at the moment of design — not invented afterwards to defend a decision already made.
The jobs become honest. A role designed from the work outward describes what a person actually does to create actual value. A role designed from a description inward describes what someone put on a form when they needed to hire.
And critically — the structure holds. When strategy shifts, the architecture can respond deliberately, because the organisation knows what each part of it is doing and why. When organisations do not know this, they respond to every shift reactively, which produces the restructuring that quietly reverts, which produces the next restructuring.
The job description is a useful document. Written at the end of a process done correctly, it is precise, honest and genuinely useful to everyone who reads it.
The mistake is treating it as the beginning of that process rather than its output.
Start from what explains the organisation. Derive everything else from there.
The description comes last. When it does, it actually means something.
Join 2,000+ HR professionals and leaders receiving our monthly digest of practical people management insights.
✓ You're subscribed! Look out for our next issue.