This deck answers: what are the steps to build a job architecture? It lays out seven steps from goals to launch, the people involved and what each does, how position records become a job catalog, the data you actually need, how one job is mapped from start to finish, how calibration keeps levels fair across teams, how the same method scales from a few hundred positions to tens of thousands, where AI helps and where people decide, and the mistakes that sink most builds. It ends with a mapping activity, three quick questions, and a recap.

This deck covers how to build one. 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.

A job architecture build follows seven steps. First, set the goals: decide what the architecture is for, such as posting pay ranges, showing careers, or checking pay fairness, because the goals shape every later choice. Second, gather position data: one record for every position or employee seat, with its title, department, location, manager, and any description. Third, design the frame: choose the functions, families, tracks, and levels. Fourth, map the jobs: give each job a family, a level, a title, and a code. Fifth, calibrate: compare placements across teams so each level means the same thing everywhere. Sixth, connect pay: link levels to grades and pay ranges using market data. Seventh, launch and maintain: explain the result to managers and employees, then keep it current. The time it takes depends on size, data quality, and how many decisions need debate, but the order of the steps does not change.

A build needs several groups, each with a clear role. A senior sponsor, often the CEO, CHRO, or CFO, sets the goals, breaks ties, and backs the result publicly. A project owner, usually in HR or total rewards, runs the work day to day and keeps decisions consistent. Managers describe the work in their teams and review placements, but they do not decide their own team's levels alone, because everyone rates their own team generously. Finance checks the cost of any pay changes and plans the budget. Employees can share what their jobs actually involve through short questionnaires or interviews, which improves accuracy and builds trust. Legal or compliance reviews titles, overtime status, and pay posting rules. Many companies also use an outside advisor or a tool for method and speed, but the decisions stay with the company.

A build does not start from a list of titles with headcounts, because titles are unreliable. It starts from employee or position records: one row for every seat in the organization. Each record carries the title, the department or org unit, the location, the manager, any job description, and other useful data. At Brightside that is about 350 position records carrying about 190 titles. Those records are then standardized and clustered: records whose work is materially the same, in accountability, scope, and requirements, are grouped together. Each group becomes one standardized job. Multiple positions map to one job, multiple titles can map to one job, and sometimes one title splits into two jobs because the work differs. Each standardized job is then placed on the framework, with a family, subfamily, track, and level. The approved result is the job catalog. At Brightside, about 190 titles become about 60 standard jobs. The numbers are illustrative.

Many companies delay a build because their data is messy. That is rarely necessary. Start with what you have. The minimum is small: an employee or position ID, the current title, the manager, the department or function, the location, and the incumbent count. Helpful data makes the work faster and more accurate: job descriptions, the reporting structure, current grade, current pay, overtime or exemption status, cost center, business unit, and employee type. Pay data is most useful later, when pay is connected, and names and performance ratings stay out of the design discussion so it stays about jobs. Enrichment data adds outside context: external job postings, skills data, market data, and task information. Perfect data is not a prerequisite. In fact, architecture work often exposes where the source data needs cleanup. It helps to separate two kinds of problems. A data quality issue is a naming or recording problem: Sr Analyst, Analyst Senior, and Analyst III may simply be the same thing written three ways, so you clean it up. An architecture decision is a judgment about the work: two Analyst II roles doing materially different work may need to become two jobs, so someone has to decide.

Mapping means placing each position into a standard job, and the same five moves work every time. The example is Brightside's Office Guru, a title held by one position at head office. First, read the work: the job answers the phones, orders supplies, books meetings, and prepares new hire paperwork, and nobody reports to it. Second, choose the family: most of the time goes on office support, so the job belongs in Administration. Third, choose the track: the job follows set processes, needs no degree, and manages no one, so it is Support. Fourth, choose the level: the job handles exceptions, such as a supplier problem, and trains new hires on office tools, which matches the S3 description, and comparing it with other S3 jobs confirms the fit. Fifth, set the title and code with the company's rules: Office Coordinator, code ADM-OFF-S3. The person keeps doing the same work, now with a clear title, level, and range.

Mapping is done job by job, often by different people, so placements drift. One team places generously and another strictly. Calibration fixes this. In a calibration session, leaders and HR look at jobs placed at the same level across different families, side by side, and ask whether they are really the same size. In the example, four jobs sit at P3. Two look alike, but the Senior Marketing Specialist looks noticeably bigger and the Senior Quality Specialist looks smaller, so the group checks whether each belongs at P3, or whether a description overstates or understates the work. Good calibration compares jobs with benchmark jobs everyone understands, uses the written level descriptions rather than opinions, discusses the job and not the person in it, and records each decision and its reason in the decision log. Most companies calibrate at the end of mapping and again whenever many new jobs are added.

Brightside is small on purpose, so every step is easy to see. An enterprise with 20,000 positions uses the same method, but nobody debates 20,000 records one at a time. The work runs in patterns. Start with the 20,000 position records and their 4,300 raw titles. Standardize the obvious duplicates, such as spelling and abbreviation variants. Cluster similar work using titles, descriptions, and org data. Map the clusters against the existing framework. Let AI or rules propose a classification for each record. Process the high-confidence matches together, with sampling to check them. Route the exceptions and low-confidence records to experts who know the work. Calibrate the patterns, looking across families and levels rather than record by record. Then approve the enterprise catalog. The operating principle is: automate the obvious, review the ambiguous, calibrate the patterns. Or, as a sequence: standardize, propose, review exceptions, calibrate, approve. The numbers are illustrative.

AI and rules-based tools are good at the repetitive parts of a build. They can identify duplicate titles, cluster similar job descriptions, suggest families, suggest matches to standard jobs, surface likely levels, flag outliers, and explain the reasoning behind each suggestion so a reviewer can check it. Human judgment stays essential in specific situations: when the work is ambiguous, when a classification affects a material outcome such as pay, level, or overtime status, when adjacent levels are hard to tell apart, when organizational context changes how the work should be read, and when an exception appears that the rules did not foresee. The same method works at any size. Brightside's 350 positions fit comfortably in a few workshops. A large enterprise uses the same steps with more automation and a stronger exception process.

Five mistakes sink most builds. Leveling people instead of jobs, which rewards or punishes individuals and makes levels meaningless. Level the job as it should be done. Copying the org chart into families, which breaks at the next reorganization. Group by the work. Starting from titles, which carries every old inconsistency into the new structure. Start from what each job actually does. Creating too many levels, a new step for every small difference, which makes the structure hard to explain and maintain. Use only as many levels as there are real differences in the work. And skipping the story: launching without briefing managers and explaining the change, so rumors fill the gap. Brief managers first and explain what changes for each person.

This activity practices the five mapping moves on the position Brightside's customer team calls Happiness Hero. The job answers customer emails and calls, handles refunds within set rules, passes complaints it cannot solve to a supervisor, and logs feedback. Nobody reports to it, and it is learned on the job. Decide the family, track, level, and title before turning the page to the model answers.

Model answers. Family: the work is serving customers, so Customer Service. Track: set rules, no degree needed, and no team to lead, so Support. Level: the job handles standard requests on its own but passes exceptions up, which matches S2 rather than S3, where handling exceptions and training others is expected. Title and code: Customer Service Representative, with a code such as CSV-CSR-S2 under the company's rules.

Three questions on the build. Question 1 checks the first step. Question 2 checks the meaning of calibration. Question 3 checks that a build starts from position records, not a list of titles.

The recap keeps three ideas. A build follows seven steps in order, from goals to launch, starting from position records rather than a title list. Mapping uses the same five moves every time: work, family, track, level, title. And at any size, the principle is to automate the obvious, review the ambiguous, and calibrate the patterns. Quiz answers: 1 is B, set the goals first. 2 is A, calibration compares placements across teams. 3 is B, start from position records, because titles alone are unreliable.

Job Architecture 101: How to Build One. 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.