Job Architecture - The Invisible Infrastructure Running Your Organisation
Consider the moment when a management meeting surfaces a question that should, by rights, have a clear answer: why is one person at Senior level and another is not? The People Director, the person in the room most expected to know, gives a response that is truthful but imprecise. Experience. Capability. A general sense of being further along. Asked to say what specific criteria were used, whether those criteria are applied consistently across functions, or how the pay ranges attached to each level were determined, she finds herself on less certain ground. Not because she has not done her job. But because the system that should give her those answers was never designed; it accumulated.
This is the situation facing most People functions at companies between 150 and 500 people. The organisation has titles and levels, maybe even dozens of them, but it does not have a job architecture. It has job nomenclature.
The distinction matters considerably more than it first appears.
The architecture that grew by accident
Job nomenclature is the system of titles an organisation uses to label roles: Senior, Principal, Director, Head of. Job architecture is something more rigorous: a structured framework that defines the criteria by which roles are assigned to levels and functions, establishes the relationships between those levels across the organisation, and provides the basis on which compensation can be set, compared, and defended. Most organisations have the former and believe they have the latter.
The absence of job architecture is not, in most companies, the result of a decision. It is the consequence of growth. A company that starts with ten people and a flat structure reaches 150 having added titles as retention demanded, levels as reporting relationships required, and pay ranges as offers were made and accepted. By the time it has 400 people, it carries the sediment of hundreds of individual decisions that were never intended to constitute a system but that function as one nonetheless: an architecture built without a blueprint, one that cannot be read, defended, or deliberately changed.
The problem is not that accidental architectures exist. Some version of this is almost inevitable in any company that has grown quickly. The problem is that an accidental architecture cannot be inspected or maintained. When a manager asks why one person is at a Senior level and another is not, the honest answer is often circumstance: who interviewed them, what title they held before, what the market was doing that month. When a candidate asks how the role will grow over time, the progression criteria are unclear because they were never written down. When a regulator asks why two roles performing apparently comparable work are paid differently, the organisation discovers it does not have a principled, documented answer — only a history.
What a real architecture consists of
A proper job architecture is composed of three interlocking elements.
Job families and functions group roles by the nature of the work they perform, independent of level. Engineering, Finance, Marketing, People: these are functions. Within Engineering, Software Development and Infrastructure might be distinct families. The grouping matters because it establishes which roles are comparable at the same level and which, by virtue of their different nature, are not directly so. A well-designed function taxonomy is the first act of structural clarity in any job architecture: it says, here is how we understand the different kinds of work this organisation does.
Job levels define progression within and across those families, applying consistent criteria across the organisation, so that "Senior" means something coherent whether the role is in Engineering or Finance, even if the specific expression of that seniority differs by domain. The hallmark of a weak levelling framework is that every function has effectively designed its own version of seniority, making titles nominally shared but practically incomparable.
Level and job expectations provide the underlying methodology: the intellectual rigour that transforms a title into a principled position. The most widely used professional approach is the Hay Group Point Factor system, now administered by Korn Ferry following the firms' 2015 merger, and used by roughly half of the world's largest organisations.1 It evaluates roles across three dimensions: the know-how required to perform the work, the degree of problem-solving it demands, and the nature and scope of accountability it carries. The EU Pay Transparency Directive, meanwhile, specifies four criteria for assessing work of equal value: skills, effort, responsibility, and working conditions. Any employer subject to the Directive must now be able to apply these criteria coherently across their entire role population.2
The specific framework matters less than the principle it embodies: that the relative value of different kinds of work can be made comparable through objective, documented criteria, rather than through market rates, organisational convention, or the outcome of individual negotiations.
The chart of accounts
Every finance function operates with a chart of accounts: a structured taxonomy that determines how every financial transaction in the organisation is categorised, making comparison, aggregation, and reporting consistent rather than improvised. Nobody questions whether a 300-person company needs one. The alternative, which is tracking financial activity without a common classification system, is obviously unworkable at scale, and the consequences are well understood: inconsistent reporting, inability to audit, regulatory exposure.
Job architecture is the organisational equivalent. Without it, decisions about roles, levels, and compensation are made without a common classification system. Each decision may be individually reasonable; none of them can be compared, audited, or defended as a whole. With it, every hire, every promotion, every compensation decision is made within a structure that makes the basis of each decision visible and consistent across the organisation.
The difference between a 50-person company and a 400-person company is not only scale. At 400 people, the absence of a common classification system for work begins to generate real consequences: compensation drift, title inflation, structural inconsistency, and the inability to answer questions that employees, candidates, and regulators are now, in many markets, legally entitled to ask.
Infrastructure is most visible when it is absent. A blocked drain, a power outage, a road that cannot take the weight of traffic: these failures concentrate the mind in ways that functioning infrastructure never does. Most People Directors at companies between 150 and 500 people are, without necessarily naming it, living with the organisational equivalent. The questions that cannot be answered cleanly, the individual cases that require adjudication rather than reference, the persistent sense that decisions are being made without a stable foundation — these are symptoms of missing infrastructure. The infrastructure has a name. It can be built.
1 The Hay Group Point Factor method was developed by Edward N. Hay and Dale Purves in the 1940s and 1950s. It evaluates roles across three primary factors — know-how, problem-solving, and accountability — each further divided into sub-factors scored on a graduated scale. Korn Ferry acquired Hay Group in 2015 and continues to administer the methodology. The claim that it is used by roughly half of the world's largest organisations is frequently cited by Korn Ferry and is consistent with independent HR market analyses. ↩
2 Directive (EU) 2023/970 of the European Parliament and of the Council of 10 May 2023, Article 4, paragraph 2: job evaluation and classification systems used for the purpose of determining pay must be based on the same criteria for men and women and must exclude any criteria which are based on sex. The Directive identifies skills, effort, responsibility, and working conditions as the relevant evaluation dimensions. ↩
