Job Architecture

How does job architecture differ from an organizational chart?

An organizational chart records reporting relationships: who a person reports to and who reports to them. Job architecture records the nature and scope of the work: what family the role sits in and what level of complexity it represents. The two are independent, and confusing them causes a specific and common error, which is treating the number of direct reports as a proxy for level. A principal individual contributor with no reports can sit at a higher level than a manager of a small team, and only an architecture that describes scope rather than headcount can express that. Organizations without one tend to promote people into management purely to increase their level, which is how capable specialists are converted into reluctant managers.

What is the difference between a job family and a job title?

A job family is a grouping of related work used internally for structure, comparison, and range setting; it rarely appears on a business card. A title is the label a specific person carries, seen by candidates, customers, and the market. One family typically spans many titles across its levels. Problems arise when titles are treated as the structure, because titles respond to external pressure, are used as non-monetary rewards, and vary in meaning between industries. Keeping the family and level as the internal source of truth, and the title as a controlled external label mapped to it, preserves the ability to compare roles even when title conventions have to flex for market reasons.

How should job architecture be maintained over time?

Assign a single owner, usually within the people or compensation function, with authority to approve new titles and to decline ones that do not map to a level. Review the level descriptors on a defined cycle against a sample of current roles, since drift shows up first as descriptors that no longer describe what people at that level actually do. Record every exception with its reason, because the exception log is the most reliable early indicator that a family needs restructuring: when several exceptions cluster in the same place, the framework is wrong there rather than the requests being unreasonable. Left ungoverned, exceptions accumulate silently until the framework is no longer usable for comparison.

What are the components of a job architecture?

Three parts do most of the work. Job families group roles that share a type of work, such as software engineering, finance, or customer support. Levels describe increasing scope and complexity within a family, from entry through to the most senior individual contributor or leader. Level descriptors, sometimes called level guides, are the written statements of what distinguishes one level from the next, expressed in terms of scope, autonomy, ambiguity, and impact rather than in years of experience.

A fourth part is the title convention that maps a family and a level to an external-facing name. This is where most frameworks leak, because commercial pressure produces titles that do not correspond to any level, and once a few exist the framework stops being a reliable basis for comparison. Deciding in advance which titles are permitted, and what happens when a hiring manager wants an exception, is more important than the elegance of the level descriptors.

Why does an organization need one?

The trigger is usually the point at which nobody can answer whether two roles in different teams are equivalent. Without a shared framework, each function evolves its own vocabulary, and a senior title in one part of the organization describes work that another part would call entry level. That makes internal moves difficult to evaluate, promotion decisions inconsistent, and pay comparisons meaningless, because there is nothing stable to compare against.

The recruiting consequence is direct. A requisition that cannot be mapped to a level cannot be reliably matched to a pay range, so ranges get set case by case, usually by reference to whatever the last similar hire was paid. Over a few years that produces a pay structure nobody designed and nobody can defend, and the organization discovers it during a pay equity review rather than in advance.

How is a job architecture built?

The usual sequence starts with an inventory of what actually exists: every current role, its real responsibilities, and its current title, gathered from managers rather than from historical job descriptions, which are frequently out of date. Roles then group into families by the nature of the work, and levels are drafted from the real distribution of scope observed across those roles rather than from an idealised ladder.

Mapping people into the new structure is the difficult phase, because it makes previously implicit judgements explicit. Some people will map to a level below their current title, which has to be handled as a titling correction with pay protected rather than as a demotion, or the project loses trust immediately. Deciding that policy before mapping begins, and communicating it before anyone sees their own outcome, is what separates projects that land from projects that stall.

What does it change in day to day recruiting?

An intake conversation becomes shorter and more precise, because the discussion is about which level the work sits at rather than about a title someone has in mind. Once the level is agreed, the pay range, the approval path, and the expected scope all follow from the framework instead of being negotiated per requisition. Recruiters spend less time reconciling a hiring manager's title preference with what finance approved.

It also makes internal candidates comparable to external ones. When an internal applicant's current level and the target level are both defined, the question becomes whether the person meets the target descriptor, which is answerable. Without a framework the same question collapses into whether the hiring manager feels they are ready, which is where inconsistency and bias enter most easily.

Where do job architectures fail?

The most common failure is proliferation. Every exception granted creates a precedent, and a framework with a level for every situation has stopped being a framework. Organizations that hold a small number of levels with genuinely distinct descriptors keep the structure usable; those that add half-levels to resolve individual disputes end up back where they started with more paperwork.

The second failure is abandonment through neglect. A framework built once and never revisited drifts out of alignment with how the work is actually done, particularly in functions where the nature of the job changes quickly. The maintenance cost is real but small compared with rebuilding: a periodic review of the descriptors against current roles, and a single owner responsible for approving new titles, is usually sufficient.

How does job architecture relate to pay?

The framework defines the structure; pay ranges are attached to it. Keeping them separate matters, because the two need to change at different rates. Level descriptors should be stable over years, since they describe the nature of work. Ranges should be reviewed regularly against market movement without requiring the architecture itself to be reopened each time.

That separation is also what makes pay equity analysis possible. Comparing pay meaningfully requires a defensible statement of which roles are comparable, and job architecture is that statement. Without it, any analysis begins by improvising a comparison basis, and the conclusions inherit the weakness of that improvisation. Where such analysis has legal implications in a given jurisdiction, its design belongs with counsel.