This deck answers one question: what problem does job architecture solve? It starts with the problems people feel when a company has no shared structure for its jobs, gives a one-sentence definition, introduces a building picture that makes the parts easy to remember, shows who uses the structure and for what, and explains why so many companies are working on this now. It ends with a self-check on your own company, three quick questions, and a recap.

This deck covers why job architecture exists. 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.

Brightside Bakery is the made-up company used as the example in this deck. It has about 350 people: a bakery plant that makes the products, twenty shops that sell them, a delivery team, and a small head office. It grew quickly, and every area invented its own job titles and pay practices along the way. The result is common in real companies of this size: far more titles than real jobs, many titles held by one person, and no written description of what makes one job more senior than another. Brightside now needs to post pay ranges in job ads, show people how to grow, and check that similar work is paid fairly. Each of those needs a job architecture underneath it. The numbers on this page are illustrative, chosen to be typical rather than to describe any real company.

Before any definitions, it helps to feel the problem. At Brightside, each part of the business created its own titles and made its own pay and promotion calls as it grew. Nothing was wrong with any single decision, but together they left no shared answer to basic questions. An employee sees a colleague doing the same work under a different title. A manager wants to promote someone but has no defined next step to promote them to. HR cannot tell which of 190 titles are really the same job. Leaders cannot say whether pay is fair, because there is no clean way to compare like with like. The costs are real: slower hiring, pay gaps nobody can explain, good people leaving for employers who can show them a next step, and long debates over every promotion. Job architecture is the shared structure that turns these debates into lookups.

Job architecture is how a company organizes all of its jobs, by the kind of work and the size of the job. The kind of work gives you groups of related jobs, called job families. The size of the job gives you steps, called levels. Put the two together and every job has one defined place on a map, the way a street and a floor number give a room one clear address. Several jobs can share the same neighborhood, but each job has exactly one address. Once jobs sit on the map, you can see the paths between them: moving up within a family, or across to a similar-sized job in another family. Everything else in job architecture, from titles to pay ranges to career paths, hangs off this map. Notice what is not on it: people. Job architecture organizes jobs. Each person sits in a position, and each position is mapped to a job on the map.

A building is a helpful picture for job architecture because it has both kinds of structure at once. Think of each function, such as Finance, as its own building. The wings of the building are job families: Accounting in one wing, Planning in another, Tax in a third. The floors are levels: the higher the floor, the bigger the job. Each room is a job, one standard body of work that sits in one wing on one floor. Several people can work in the same room, each in their own position. The nameplate on the door is the job title, the label people use. Labels can vary, which is why the room, not the label, is what gets organized. The stairs outside are career paths, the ways people move up a wing or across to another wing on the same floor. The picture has limits. Real companies have many buildings, not every wing uses every floor, and some rooms are shared. But if you can find a room in this building, you already understand the core of job architecture.

Job architecture is not only an HR tool. Employees use it to understand what their job is, what the next step looks like, and how their pay is set. Managers use it to explain promotions, to check that their team is leveled consistently with other teams, and to describe what good looks like at each step. HR and total rewards teams use it to decide which jobs are really the same, to match jobs to salary surveys, to set pay ranges, to write job postings, and to keep titles consistent. Leaders and finance teams use it to test pay fairness, spot too many layers of management, plan the skills the company will need, and budget headcount. When a company says it has a job architecture, it means all four groups can get these answers from one shared source.

It is easy to expect too much from job architecture, so this page sets its limits. On its own, job architecture does not rate anyone's performance, and it does not judge whether a person is good at their job. It does not guarantee equal pay, because pay decisions still have to be made and checked. It does not set any one person's salary, because pay within a range depends on other factors and on the company's pay policy. It does not replace organization design, workforce planning, a skills framework, or market pricing, and it does not write business strategy. What it does is create a shared structure: a catalog of jobs, grouped and sized the same way everywhere. Performance reviews, pay decisions, organization design, workforce plans, and skills work can all use that structure, which makes their answers more consistent. Think of it as the common language those processes speak, not the processes themselves.

Four pressures explain why job architecture has moved up the agenda. First, pay transparency: as of September 2026, more than a dozen US states plus the District of Columbia require pay ranges in job postings, and more states are adding similar rules. A posted range has to come from somewhere. The laws do not require a job architecture, but a defined job at a defined level with a pay range attached is a practical, consistent source for it. Second, pay equity: the EU Pay Transparency Directive, which member states were due to adopt into national law by June 2026, expects employers to have pay structures that allow work of equal value to be compared using objective, gender-neutral criteria. A documented job architecture does not satisfy the law on its own, but it gives employers useful evidence and infrastructure for that comparison. Third, careers: people increasingly leave when they cannot see where they could grow, and clear levels and paths make the next step visible. Fourth, changing work: before a company can redesign jobs around automation and AI, it needs an accurate picture of the jobs it has. Check current rules with counsel before acting, because pay transparency laws change often. Sources, last verified September 26, 2026: Colorado Equal Pay for Equal Work Act, California Labor Code section 432.3, New York Labor Law section 194-b, Washington RCW 49.58.110, and Directive (EU) 2023/970 of the European Parliament and of the Council, Article 4.

Adults learn fastest when new ideas connect to their own experience, so this page asks you to look at your own company before going further. Answer each question with yes, not sure, or no. There are no wrong answers. Most companies of every size have a mix, because job architecture is often built in pieces: one team has clean titles, another has a pay structure, nobody has written level descriptions. If you answered mostly yes, you already have a foundation to test and tune. A mix is the most common result, and it shows where to focus first. Mostly no means the company would gain the most from a job architecture. Each question points to a part of the structure: a single job list, consistent titles, visible level descriptions, pay ranges tied to levels, and a named owner.

Three questions to pull the deck back out of memory. Answer before turning the page. Retrieving an idea, even imperfectly, makes it stick far better than rereading it. Question 1 checks the core definition: job architecture organizes jobs, by kind and size, not people or reporting lines. Question 2 checks the two placing questions. Question 3 checks the limits of job architecture: on its own it creates a shared structure, and other processes such as pay and performance make their decisions using it.

The recap keeps three ideas. Job architecture organizes jobs, not people. Two questions place every job: what kind of work it is and how big it is. And job architecture is a shared structure that other processes use, not the answer to every people question. Quiz answers: 1 is B, because job architecture groups and sizes jobs, while the org chart shows reporting lines and performance belongs to people. 2 is B, the two placing questions. 3 is B, because salary decisions and performance ratings are separate processes that use the structure rather than being made by it.

Job Architecture 101: Why Job Architecture Exists. 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.