This deck answers: what are positions, titles, and jobs, and how do they fit together? Most confusion about job architecture comes from a handful of everyday words that people use loosely. This deck pins them down: the chain from person to position to job to architecture, why titles are labels rather than jobs, why every job needs a code, what a job description does and does not do, the hierarchy from function down to position, how an org chart differs from a job architecture, and why the architecture is a system rather than a file. It ends with a sorting activity and its model answers, three quick questions, and a recap.

This deck covers the building blocks. It is written for someone with no background in HR, compensation, or organization design, and it follows adult learning principles: why before what, one realistic example throughout, practice with answers, a short quiz, and a one-page recap. The example is Brightside Bakery, a made-up company of about 350 people with a bakery plant, twenty shops, a delivery team, and a head office. It grew fast without a plan for its jobs, so it has far more titles than real jobs and no shared way to compare them. The words on this page are defined again where they first appear.

This chain is the most important idea in job architecture, so it is worth learning by heart. A person is the individual employee. A position is one seat or assignment in the organization, usually tied to a budget or headcount plan, and it can be filled or open. A job is a standard body of work used across the company: a purpose, main duties, requirements, and a size that many positions can share. The job architecture is the framework that classifies jobs into families, subfamilies, tracks, and levels. At Brightside, Maya is one of 21 drivers. She occupies seat 1047 at the North depot, one of 24 driver positions, three of which are open. All 24 positions map to one job, Delivery Driver, and that job has one place in the architecture: the Logistics family, Delivery subfamily, Support track, level S2. A title is different again. It is the label attached to a position or a person, and the 24 driver positions carry three different titles today. Because the architecture works at the job level, it places Delivery Driver once, and every position and person linked to it inherits that placement. This is also why the architecture does not judge people. Two drivers in the same job sit at the same level whether one is brilliant and one is brand new. Their pay can still differ for other reasons.

A title is a label, and labels drift. At Brightside, the 24 driver positions carry three titles, Delivery Driver, Driver, and Route Driver, but the work is the same: load the van, drive the route, deliver, and collect returns. So all three titles map to one standard job. The reverse also happens. The title Supervisor is used in the plant and in the shops, but the work is different. In the plant, a Supervisor leads a shift of twelve bakers and is accountable for their output, their schedules, and their development, so that position maps to the Production Supervisor job on the Management track. In the shops, the people called Supervisor are experienced associates who open and close the shop and help newer staff, with no team to lead, so those positions map to Senior Shop Associate on the Support track. The rule is to map by the work, not the words. A standard job should hold positions whose work, accountability, scope, and requirements are materially the same. Messy titles come from many places: local titles, old titles nobody retired, duplicates, creative titles such as Office Guru, and titles handed out as a reward rather than for the work.

Once the architecture places a job, it gives the job an official title. A good title does two things: it says what the work is, and it signals roughly how big the job is. In Senior Accountant, Accountant names the work and Senior signals the level, because the company uses its level words the same way everywhere. Many companies also allow a working or business title, the name someone uses on a business card or profile. That is fine as long as every working title maps to one official job. Be careful about reading a level from a title alone. Titles are labels, and outside a well-governed system they drift. Two people called Director can run very different sizes of work, one leading a department of sixty and another advising on a single program. A Social Media Manager may manage no people at all, which makes it an individual contributor job despite the word Manager. The architecture classifies from the work first, and the title follows.

A job code is a short, unique ID for each standard job. People read titles, but systems such as the HR system, payroll, the applicant tracking system, and salary survey submissions work best with codes. Codes stay stable when a title's wording changes, and they keep two different jobs apart even if someone gives them similar titles. Every position mapped to a job carries that job's code, while each position also keeps its own position ID. Many companies build meaning into the code, as in this illustrative example: FIN for the Finance function, ACC for the Accounting family, and P3 for the Professional track at level 3. Others use plain numbers. Either works if the rules are written down and applied the same way everywhere. A practical tip: decide the code format before you start mapping jobs, because recoding hundreds of jobs later is tedious and error prone.

A job description explains a job in words, so anyone can understand what it is for and what it takes. Most good descriptions have six parts. The header carries the title and code. The placement shows the job's family, track, and level, which links the description to the architecture. The purpose is one sentence on why the job exists. Key duties list the main responsibilities, written as outcomes rather than every task. Requirements cover knowledge, experience, and any licenses or certifications the job truly needs, which matters for fairness because inflated requirements screen people out. Scope describes who the job reports to, who reports to it, and what it is accountable for, such as a budget or a location. Descriptions describe the job, never the current person in it. One more distinction matters: a description is not the job. The description documents the job, and the architecture classifies it. A poor or outdated description does not mean the job itself is invalid. It means the document needs updating so it reflects the work people actually do.

Every position in a company can be traced up through the same layers, from broadest to most specific. The function is a broad organizational capability, such as Finance or Operations. The job family is a major grouping of related work inside it, such as Accounting or Production. The subfamily is a more specific discipline inside a family, such as Accounts Payable or Baking. Subfamilies are optional and are used only when a discipline is paid, hired, or grown differently enough to need its own group. The job is the standard body of work, such as Accounts Payable Specialist or Baker. The position is one employee's assignment, such as the Accounts Payable Specialist at head office, or the Baker on the night shift at line 2. Track and level are not extra layers. They are attributes of the job: they say what kind of career path the job sits on and how big it is. The Accounts Payable Specialist job is Professional P2, and the Baker job is Support S3. Every position mapped to a job inherits its family, track, and level.

People often assume the org chart is the job architecture. It is not. The org chart answers one question: who reports to whom. The job architecture answers a different question: what kind of work is this, and where does it fit? At Brightside, twelve drivers report to the North depot's Fleet Supervisor and nine report to the South depot's. The org chart shows two teams. The architecture shows one job, Delivery Driver, because the work is the same in both depots. Reporting line alone also does not decide how big a job is. The Executive Assistant to the CEO reports to the most senior person in the company, but the work is still a support job, sized by what the job itself does. The two views connect. Reporting lines are useful evidence about scope, and organization design decisions change jobs. But a reorganization should not rewrite the architecture unless the work itself changes.

It is tempting to think of job architecture as a spreadsheet of jobs. The spreadsheet matters, but on its own it goes stale within months. A working job architecture is a system with six parts. The framework is the structure itself: the families and subfamilies, the tracks, and the levels with written criteria. The job catalog is the list of standard jobs, each with a code, an official title, a description, and its place in the framework. The rules say how to title, code, and place a job, and when a new job is justified. The data is the link between the catalog and real people: every position in the HR system mapped to a job. Governance names who owns the architecture, who approves changes, and when it is reviewed. The processes are the everyday uses, such as pay, hiring, promotions, and workforce planning, that rely on the architecture and keep testing it. Remove any one part and the rest weakens. A perfect catalog with no governance drifts. Good governance with no data mapping cannot answer real questions.

This activity checks whether the layers are clear. For each of the eight items, decide whether it is a function, a family, a job, or a position. A few quick tests help. A function is a broad area of the business that holds several families. A family is a group of related jobs. A job is a standard body of work that many positions can share. A position is one specific seat or assignment, filled or open. Write your answers down, then check them against the model answers on the next page.

Model answers. Operations and People are functions, because each is a broad area of the business holding several families. Baking and Recruiting are families: Baking sits inside Operations and Recruiting sits inside People. Some companies call Recruiting Talent Acquisition, and some call People Human Resources. The names vary, but the layers do not. Shop Associate and Delivery Driver are jobs, because each is a standard body of work that many positions share. The Elm Street weekend shift and the open North depot seat are positions, because each is one specific seat, and an open seat is still a position. Both map to a job: Shop Associate and Delivery Driver.

Three questions on the building blocks. Question 1 tests the difference between positions, titles, and jobs: 24 positions under three titles are still one job when the work is the same. Question 2 tests what a code is for. Question 3 tests the chain from person to architecture.

The recap keeps three ideas. A person occupies a position, which maps to a job, which sits in the architecture. Titles are labels: many titles can map to one job, and one title can hide two different jobs, so jobs are mapped by the work. And the layers run from function to family to subfamily to job to position, with track and level describing the job. Quiz answers: 1 is C, one job, because positions and titles map to a job when the work is the same. 2 is B, a code identifies the job in every system. 3 is B, a person occupies a position, which maps to a job.

Job Architecture 101: The Building Blocks. Copyright 2026 HRDigitalPlayground | Job Architecture. Published September 2026. Brightside Bakery is a fictional company and all examples are illustrative. The material is general education, not legal, tax, or financial advice.