This deck answers: how do we keep a job architecture working after launch? Without care, titles multiply again and levels drift within a year or two. The deck explains why architectures decay, who should own the structure, how a single front door for new jobs works, how events trigger reviews between check-ups, how to tell a job change from a person change, a simple rhythm of reviews, how to explain changes to employees and managers, how to lead people through the change, and how to tell whether the structure is healthy. It ends with a personal action plan, three quick questions, and a recap.

This deck covers keeping it alive. 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 starts decaying the day it launches unless someone looks after it. New titles get created for new hires, often to make an offer more attractive. Pay problems get solved by moving jobs up a level. Reorganizations shift work between jobs without anyone updating the descriptions. And when nobody clearly owns the structure, every one of these small changes goes unchecked. The chart shows the pattern at Brightside, which cut 190 titles to 60 at launch. Without care, titles could climb back toward 150 within three years. With an owner, a single front door for new jobs, and a steady review rhythm, the count stays close to 60 while the company still adds real new jobs as it grows. The figures are illustrative.

Governance sounds heavy, but for most companies it comes down to three things. An owner, usually in total rewards or HR, who looks after the structure day to day, answers questions, and says no when a request breaks the rules. A small review group, often someone from HR, someone from finance, and one or two business leaders, who meet regularly to decide anything the owner cannot, such as a new family or a level change that affects many people. And a handful of written rules: who can request a new job, who approves a new job or a level change, where every decision and its reason is logged, and how exceptions are handled, including when they expire. The decision log matters more than it seems. When the same question comes back a year later, the log shows what was decided and why, so the company does not re-argue it.

A single front door for new and changed jobs is the most effective habit in governance. Every request follows the same six steps. A manager submits the request with a draft description and the reason for it. The owner checks whether an existing job already covers the work, which is the answer surprisingly often. If a new job is needed, it is mapped to a family, track, and level with the usual method. The owner or the review group approves it. The new job is priced, given its grade, range, title, and code, and added to every system. Finally, the decision and its reason go in the log. At Brightside, a shop asked for a new Cake Decorator title. The check showed that the Baker job at S3 already covers decorating as part of the role, so no new job was created. The manager used the Baker job and the description was updated to mention decorating. Brightside aims to decide simple requests within about two weeks. That is an illustrative target, not a rule. What matters is that the process is fast enough that managers do not work around it.

Regular reviews catch slow drift, but some events should trigger a review as soon as they happen. A job may need review when its responsibilities materially change, when AI or automation changes its major tasks, when its reporting scope changes, when teams merge, when the company makes an acquisition, when new capabilities appear that the architecture has no place for, when a persistent market anomaly shows up, such as a job the company keeps losing people from, when employees repeatedly challenge how their job is mapped, when managers keep creating unnecessary titles, when a new regulation affects how a job must be classified, or when business strategy changes. The model is simple. Monitor for triggers. When one appears, assess the job against its description and level criteria. Decide change or no change, and both are valid outcomes. If there is a change, approve it through the usual front door. Update every system that holds the job. And communicate the result to the people affected, including when the answer is no change.

When someone asks for a review, the first question is what actually changed. A job change means the work itself has changed for anyone in the job. At Brightside, centralizing ordering removed ordering from the Shop Manager job and created a Supply Planning team, so the Shop Manager job is re-assessed, and the new planning jobs are added. When AI took over route planning, the Dispatcher job's tasks changed, so the job was re-assessed. In both cases the result applies to everyone in the job. A person change means one person has grown, performed very well, or taken on a temporary project, while the job stays the same. Maria is an outstanding Accountant. A Baker covers for the Head Baker for a month. These are handled through people tools: development, recognition, pay within the range, a temporary assignment allowance, or a move to a bigger job when one exists. Mixing the two up is how levels drift. Re-leveling a job to reward one person changes the job for everyone and weakens the structure.

A simple rhythm keeps the architecture current. Every request is handled as it comes, through the front door, and triggering events are handled as they happen. Brightside aims for about two weeks on simple requests, an illustrative target. Every quarter, the owner reviews the new titles and exceptions created since the last review and checks for patterns, such as one team asking for many exceptions. Every year, the company refreshes market data and pay ranges, runs a pay equity check, and reviews the level descriptions and job descriptions that have gone stale. Every few years, or after a big change such as an acquisition or a new operating model, the company steps back and checks whether the families and levels still fit the business. Putting these dates in the calendar, with named owners, is what turns good intentions into a habit.

When a job architecture launches, or when a job changes, people ask the same four questions, usually in this order. First, is my pay changing? Answer it plainly and first, because nothing else will be heard until this is settled. In most cases pay does not change because of a new title or level, and where a range change affects someone, say so directly. Second, what is my new title and level, and why? Explain it with the level description, not with jargon. Third, what does my next step look like? Show the career path and what the next level requires. Fourth, who can I ask? Name a person, not an inbox. A few practices make this go well: brief managers before anyone else, give each manager a one-page script and a short FAQ, have managers talk to their people one to one before any broad announcement, and keep a channel open for questions after launch.

Launching a job architecture is a people change, and it goes best in three stages. Before launch, a senior sponsor explains why the company is doing this, managers are briefed and trained with scripts and FAQs, employee profiles are checked for errors, and the pay impact is known and funded. At launch, managers hold one-to-one conversations first, then the company shares a clear announcement and makes each person's job profile available. After launch, the company collects questions and fixes errors quickly, uses the new structure in the very next pay review and promotion cycle so people see it working, and checks understanding with a short survey a few months later. Reinforcement is the step most often skipped. If the next promotion ignores the new level descriptions, people conclude the structure does not matter.

Six simple signs show whether a job architecture is healthy. Nearly all positions should be mapped to a job in the catalog, because an unmapped position is work the architecture cannot see. Nearly all job descriptions should still match the work. Age is a useful signal, but the real test is whether the documented job still reflects the work being performed. The number of exception requests each quarter should be steady or falling, and a spike points to rules that no longer fit. The time to approve a new job should stay short and predictable, because slow approvals push managers to work around the process. Brightside aims for about two weeks, an illustrative target. Unexplained pay gaps found in the equity check should shrink year over year. And the share of employees who can say what their level means, measured in a short survey, shows whether the structure is understood. The targets here are illustrative starting points.

This page turns the deck into action. First, find your company's job list or job catalog, or ask HR whether one exists. If there is none, that is the most useful thing you can learn this week. Second, place your own job: its family, its track, and its level, using the level descriptions if they exist, or your best judgment if they do not. Third, pick one question from this deck that your company cannot answer yet, such as who approves new titles, and share it with one person who can do something about it. Small, concrete steps are how structures get built and kept alive.

Three questions on keeping it alive. Question 1 checks what stops titles from multiplying. Question 2 checks the difference between a job change and a person change. Question 3 checks who hears about a change first.

The recap keeps three ideas. Decay is the default, so a job architecture needs an owner, a small review group, and written rules. Every new or changed job goes through one front door, with a regular rhythm plus event-driven reviews when the work changes, and a job change is kept separate from a person change. And changes land well when managers hear first, pay is addressed first, and every person sees their next step. Quiz answers: 1 is B, an owner and one front door. 2 is B, a major change in tasks is a job change. 3 is B, managers first.

Job Architecture 101: Keeping It Alive. 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.