A spreadsheet with 600 employees and 480 job titles gives you plenty of rows and very little structure. "Senior Analyst" appears nine times, with a different meaning each time. One Senior Analyst manages a team of four and owns a P&L line. Another has six months of experience and a generous title carried over from her last job. Now you have to run pay equity across it. The analysis has no sound starting point.
This is what happens when a company grows by adding titles while leaving the structure undefined. Most pay problems, including pay equity gaps, band violations, and "why does she make more than him" tickets, begin as architecture problems. A missing architecture hides the cause. The pay may need attention, but first you have to know which jobs belong together.
Job architecture is the framework underneath compensation. It groups jobs and levels them so every role has a defined place. Nobody throws a party when you finish the job catalog. Still, the catalog lets you price jobs consistently, run pay equity, and explain a pay decision without inventing the rationale during the conversation.
Give every job two coordinates
A job architecture has two moving parts: job families and career levels.
A job family is a group of related jobs that share a common discipline. Finance is a family. Engineering is a family. Sales is a family. Within Engineering, you might have sub-families such as Frontend, Backend, and Infrastructure. Each job family clusters jobs that draw on the same body of knowledge, which lets you compare similar work. It answers, "What kind of work is this?"
Career levels, usually shortened to levels, form a ladder of increasing scope and impact that runs across every family. How many rungs you need depends on the company. A small organization may run on a handful, from entry-level work up to its most senior roles. A larger one carries more, because it has more distinct steps of scope to separate. The top of the ladder is senior leadership, not a super-senior version of one job. Each level has a written definition covering what the job owns, the complexity of its problems, the autonomy it requires, and the impact it carries. The level answers, "How far along is this job in this kind of work?"
Those two dimensions cross. Every job sits at the intersection of a family and a level, such as "Backend Engineer, Level 4." That intersection tells you more than the title can. Once you define it, you can make a workable pay decision. Without it, you still have 480 titles and a prayer.
Keep the two career tracks parallel
Most architectures past a certain size split their levels into two tracks: individual contributor (IC) and manager/leadership. An IC does the work directly. A manager gets the work done through others.
The tracks need to run in parallel. A Level 5 IC and a Level 5 manager should sit at roughly the same pay grade. A Level 7 IC should sit above a Level 5 manager. If managing employees is the only route to more money, you will lose some of your best engineers, researchers, and designers. Some employees want to remain ICs, and the pay structure needs to give them room to grow.
This is the belief that trips up leaders more than any other part of parallel tracks. Many assume a manager should out-earn any individual contributor, for the simple reason that the manager manages. The idea that a principal engineer might earn more than the director she reports to strikes them as backwards. It isn't. Pay follows the scope, complexity, and impact of the work, not the number of direct reports. A deep technical expert can carry more business value than a manager a level or two up, and the structure has to leave room for that. Expect to explain this more than once.
One company capped IC pay one band below manager pay because its leaders believed managers had more responsibility. Its top data scientist left three months later for a competitor with a real dual track.
Another company let manager pay drift far above IC pay through years of counteroffers and "retention" raises. Its senior engineers kept angling for team-lead roles they didn't want. Employees follow the pay structure you give them. Parallel tracks let technical experts grow without turning management into a toll booth.
Level the job against four criteria
Leveling decides which rung a job sits on. Use four criteria: scope, complexity, impact, and autonomy.
Scope describes how wide the job reaches. Does it cover one project, one team, one function, or the whole company?
Complexity describes the problems the job must solve. Are they well defined, with established playbooks, or ambiguous problems that nobody has solved before?
Impact describes what the job must move. That could be a metric, a team's output, or a business result.
Autonomy describes the direction the job requires. The range runs from close supervision, through general guidance, to "here's the goal, go figure it out."
Weigh those four criteria, compare the job with your written level definitions, and place it. Base the level on the work, even when the title, tenure, or manager's enthusiasm points somewhere else.
Someone can spend ten years in a role and remain at Level 3 because the role's scope hasn't grown. Someone else can reach Level 5 after two years because the job owns problems of that size. The level follows the work, not the clock.
Titles deserve the same skepticism. A title is easy to hand out, and organizations do it constantly to solve a pay problem: they invent a "Senior" version of a role so they can pay someone more, even though the scope, complexity, impact, and autonomy never changed. That inflates the title without changing the job. Leveling against the four criteria is the firmer footing, because it anchors pay to the real work instead of letting a title stand in for the decision.
Follow the gradient through one family
Take three rungs from a Data Science family.
Data Scientist, Level 3 (Professional). Scope: owns a model or analysis end to end within an established project. Complexity: receives defined problems and chooses methods from a known toolkit. Impact: contributes to a team deliverable. Autonomy: works with regular check-ins from a senior peer or manager. Distinguishing marker: executes well on problems that someone has already framed.
Data Scientist, Level 4 (Senior). Scope: owns a problem area, such as the entire churn-prediction surface, with individual tasks inside it. Complexity: frames the problem, chooses between competing approaches, and handles trade-offs. Impact: drives a measurable business metric, such as retention or conversion. Autonomy: sets the approach while the manager reviews the outcomes. Distinguishing marker: defines the problem before solving it.
Data Scientist, Level 5 (Staff). Scope: sets direction across multiple projects or the whole family's technical roadmap. Complexity: handles ambiguous, cross-functional problems with Engineering, Product, and Legal. Impact: changes how the whole function operates. Autonomy: receives a strategic goal, designs the plan, and rallies others around it. Distinguishing marker: raises the level of everyone nearby.
Read the three levels from top to bottom. Scope widens from a project, to a problem area, to a function. Complexity moves from defined, to framed, to ambiguous. Impact climbs from a deliverable, to a metric, to an operating model. Autonomy grows from check-ins, to outcome review, to self-direction.
That gradient is leveling. The names help only so much. "Staff" outranks "Senior" here, which catches most people off guard, and another company might label the same three rungs Associate, Senior, and Principal, or number them I, II, and III. Read the criteria, not the title.
Connect the architecture to pay
Once every job has a family and level, build a salary structure. A salary structure is a set of ranges, usually organized into grades, with a minimum, midpoint, and maximum for each grade. Map levels to grades and price each grade against market data for the jobs in it. The mapping may be one-to-one, or two levels may share a grade.
Now every job has a home. A Level 4 Data Scientist might map to Grade 7, with a midpoint of $145,000 and a range of $123,000 to $167,000. When you hire someone, you know the lane.
When an employee earns a promotion from Level 4 to Level 5, move them to the grade mapped to Level 5. That may be the same grade because some structures place two levels in one grade. Either way, you have a defined starting point for the pay decision.
When someone's pay reaches 115% of the range midpoint, the structure gives you a reason to ask why. The employee may present a retention risk at the band maximum. The job may be misleveled. The band may be stale. Architecture supplies the question before anyone reaches for an improvised answer.
Pay equity depends on the same foundation. A pay equity analysis asks whether employees in "similarly situated" roles receive comparable pay. You need an architecture to define that group. The same family, level, and grade give you a strong starting point for a comparator group.
Actual job content still controls the test. Two jobs can share a label and require different work. Architecture lets you make the comparison, inspect the work behind it, and defend the result.
Build in the right order
Architecture comes before pricing. Pricing comes before pay equity. Pay equity comes before raise decisions, market adjustments, and the transparency conversations that everyone suddenly wants to have in June.
Skip ahead and the errors pile up. Run pay equity on a title list and two employees with the same title but different scopes may appear to have a pay gap. One may run a team of twelve while the other works at a narrower scope. Without job definitions, the analysis leaves the source of the gap unresolved. It could reflect discrimination or the difference between the two jobs.
Build salary bands before leveling the work and the ranges will miss the jobs. Half the company may land over band and half under it. Fixing the bands then requires fixing the levels, and fixing the levels requires families in which to place the jobs.
Architecture sits underneath all of it. Build it first, build it once, and build it carefully. Compensation has more glamorous projects, but few that do as much work.
Start with the jobs
If you are new to compensation, or you run HR for a small company that has outgrown its first org chart, start with a list of jobs. Cluster them into a handful of families. Write a one-paragraph definition for each level. Assign each job, meaning each position defined by its required work, to a family and level based on that work.
Then map each employee to the job the employee performs.
Your first version will have rough edges. It will still be vastly better than titles alone. The next time someone asks why one employee makes more than another, you can point to the work, the level, and the range. That beats a shrug.